Diskussion:SHA-3

Reorganisation der SHA Seiten

Nun existiert ein Artikel Secure Hash Algorithm, der alles über SHA-1 und SHA-2 zusammenfasst und dieser hier über SHA-3. Ich denke entweder sollte die Information dieser Seite auf die allgemeine SHA Seite verschoben werden, oder (wenn der Informationsgehalt hier noch deutlich ansteigt) sollten die Seiten vollständig reorganisiert werden (nach dem Beispiel der englischsprachigen Wikipedia en:Secure Hash Algorithm ) und SHA-2 somit seine eigene Seite bekommen. --Exploide (Diskussion) 19:19, 7. Sep. 2013 (CEST)

auf dieser seite hier geht es hauptsaechlich um die NIST hash function competition, man koennte ueberlegen, die seite entsprechend umzubennen und SHA-3 auf Keccak weiterzuleiten. im uebrigen waere ich auch dafuer, SHA-2 auf eine eigene seite auszulagern, aber die diskussion sollte unter Diskussion:Secure Hash Algorithm#SHA-2 auslagern? stattfinden. --Mario d 21:05, 3. Okt. 2012 (CEST)

bin auch eher für das Auslagern von SHA-2. Spätestens wenn auch bei 2 und 3 Pseudocode dazu kommt würde es auf einer gemeinsamen Seite extrem unübersichtlich. Aber SHA-3 auf Keccak verlinken? Nicht eher andersrum? AES verlinkt ja auch nicht zu Rijndael. Bleibt abzuwarten welche Bezeichnung sich durchsetzt. Wenn bald alle Tools sha3sum oder so heißen wird wahrscheinlich niemand mehr von Keccak sprechen. --Exploide (Diskussion) 19:19, 7. Sep. 2013 (CEST)

Wenn ich das richtig sehe, sind sich SHA-1 und SHA-2 aber algorithmisch sehr ähnlich. Keccak und SHA-3 zusammenzufassen wäre aber sehr sinnvoll, da sich wohl eher SHA-3 als Bezeichnung durchsetzen dürfte wohl eher von Keccak nach SHA-3. --Sepp (Diskussion) 07:55, 4. Okt. 2012 (CEST)

dann schlage ich vor, zuerst diese seite auf "NIST hash function competition" zu verschieben (das kann man ja vielleicht noch ausbauen), dann wuerde ich einfach den inhalt von Keccak hierher kopieren (bisher bin ich dort der einzige autor) und aus Keccak eine weiterleitung machen. --Mario d 13:43, 4. Okt. 2012 (CEST)

Klingt für mich sehr vernünftig. --rayx Diskussion 14:39, 4. Okt. 2012 (CEST)

Gut. Allerdings wäre zu überlegen ob die Thematik der von dir genannten "NIST hash function competition" nicht auch in einen Hintergrund oder Geschichte Abschnitt des Artikels einfließen kann. Wenn wir es so machen wie du vorgeschlagen hast wäre andersrum zu überlegen ob dann da nicht auch der Standardisierungsprozess von SHA-1 und SHA-2 beschrieben. Schließlich gab es da ähnliche Ausschreibungen oder irre ich mich? --Exploide (Diskussion) 19:19, 7. Sep. 2013 (CEST)

da irrst du dich, SHA-0 bis SHA-2 waren eigenentwicklungen der NSA; es gab einen aehnlichen wettbewerb fuer AES, aber der hat hiermit nichts zu tun. ob abschnitt oder eigener artikel wuerde ich an der laenge festmachen. beim gegenwaertigen stand waere ein abschnitt ok, falls das aber jemals die ausmasse von en:NIST hash function competition erreichen sollte, waere das fuer einen artikel zu viel. man kann zu dem thema durchaus einiges schreiben, es gab da ja auch einiges an oeffentlichem interesse, daher wuerde ich zu einem eigenen artikel tendieren. meine meinung ist aber nicht gefestigt, ich lasse mich auch gerne vom gegenteil ueberzeugen. --Mario d 17:42, 4. Okt. 2012 (CEST)

ich habs jetzt erstmal in einem artikel gelassen, wenn der zu gross wird, kann man ihn immer noch auseinanderpfriemeln. nur noch mal zur klarstellung: SHA-3 in SHA einzubauen halte ich fuer keine gute idee, weil die algorithmen ueberhaupt nichts miteinander zu tun haben. --Mario d 21:57, 4. Okt. 2012 (CEST)

Es ist ganz normal, dass die Algorithmen ihre eigenen Namen haben und nichts miteinander zu tun haben. Secure Hash Algorithm beschreibt eine Gruppe von Algorithmen, die unter dieser Bezeichnung laufen.--Lex parsimoniae (Diskussion) 22:05, 4. Okt. 2012 (CEST)

mir ist nicht ganz klar, was du mit "Gruppe von Algorithmen" meinst. SHA-1 wurde aus SHA-0 entwickelt, SHA-2 ist eine weiterentwicklung von SHA-1. SHA-3 hat aber ueberhaupt nichts mit den anderen zu tun, bis auf den namen. SHA-2 ist eine familie von algorithmen, parametrisiert durch die ausgabelaenge. SHA-0 bis SHA-2 koennte man als gruppe von algorithmen bezeichnen, die eine aehnliche struktur aufweisen. SHA ist einfach ein standard, mehr hat SHA-3 mit seinen vorgaengern nicht gemein. --Mario d 22:19, 4. Okt. 2012 (CEST)

Da sind wir wieder bei der Klassenhierarchie, die wir bei der Firewall schon diskutiert hatten. Der Wurzelknoten "Secure Hash Algorithm" umfasst aus meiner Sicht und wie es auch im Artikel steht "eine Gruppe standardisierter kryptologischer Hashfunktionen." SHA-1 bis 3 arbeiten zwar sehr unterschiedlich, gehören aber alle zu dieser Gruppe.--Lex parsimoniae (Diskussion) 22:52, 4. Okt. 2012 (CEST)

SHA-1 bis SHA-3 sind gehoeren zum SHA-standard, wie der name schon sagt. daraus folgt aber nicht, dass dieser artikel in SHA eingebaut werden muss. die diskussion findet auch sinnvoller unter Diskussion:Secure Hash Algorithm#SHA-2 auslagern? statt. --Mario d 23:37, 4. Okt. 2012 (CEST)

Redundanzbaustein

Ups, ich habe vergessen zuerst die Diskussionsseite anzuschauen und habe den Redundanzbaustein für SHA-3 und Keccak gesetzt. Sorry. --rayx Diskussion 14:35, 4. Okt. 2012 (CEST)

kritikabschnitt

ich habe den abschnitt "kritik" geloescht. formal, da er nicht ordentlich bequellt war, ein blogbeitrag ist keine quelle. aus gutem grund: der schreiber hat da wohl etwas missverstanden und ausgabelaenge mit sicherheitsniveau verwechselt. geplant waren vier ausgabelaengen von 224, 256, 384 und 512 bit, mir sicherheitslevel 112, 128, 192 und 256. die level 112 und 192 fallen jetzt wohl weg. --Mario d 19:04, 28. Sep. 2013 (CEST)

Habe den Abschnitt mal wiederhergestellt und auf den entsprechenden Heise-Artikel verlinkt. Deine Ausführungen zu den Sicherheitsstufen sind interessant, hast Du dafür eine Quelle? Ansonsten bleibt die Kritik an der Algorithmusänderung so wie an Performanz als Kriterium an sich bestehen. --Sepp (Diskussion) 17:32, 30. Sep. 2013 (CEST)

Ich habe ein paar Kleinigkeiten umformuliert, zB. dass Kelsey nichts davon gesagt hat, dass die Sicherheit herabgesetzt würde, sondern ein "einige Forscher". Er dagegen hat (letzten Abschnitt) das ganze nochmal verteidigt, der Algo sei nach wie vor sicher.

Aber ob das ganze fundierte Kritik ist (für die es einen eigenen Abschnitt braucht), halte ich mangels Fakten doch für etwas fraglich.--Plankton314 (Diskussion) 19:12, 30. Sep. 2013 (CEST)

Schade, denn auch heise-Autoren sind fehlbar. Beispielsweise hat Herr Fabian Scherschel das auch nicht so ganz mit den Sicherheitsstufen und Ausgabelängen verstanden. Der Teil "dass das NIST nur noch die zwei Sicherheitsstufen 128 Bit und 256 Bit" ist richtig. Der Teil "d. h. die Ausgabelängen 256 und 512 Bit, standardisieren wolle" ist definitiv falsch. Die Ausgabelängen sind immer noch 224,256,384,512 mit den dazu passenden Kollisionsresistenzen 112,128,192,256. Die Preimage-Resistenzen wären nach dem aktuellen Vorschlag allerdings in den Fällen jeweils 128,128,256,256, statt 224,256,384,512. Man muss sich mit Keccak -- genauer: Sponge-Funktionen -- schon ein bisschen beschäftigt haben, um keinen Blödsinn zu schreiben. Der Kapazitätsparameter wurde auf c=256 und c=512 beschränkt, was eine generelle obere Schranke aller Resistenzen von c/2 darstellt. Siehe auch Yes, this is Keccak! vom Keccak-Team. Ich habe den zweiten Teil gelöscht, weil er falsch ist. --Zerpi (Diskussion) 20:23, 5. Okt. 2013 (CEST)

Ob das ganze letztendlich unter Kritik läuft oder nicht. Definitiv sollten zu gegebener Zeit (wenn SHA3 endgültig freigegeben wird) die Unterschiede zwischen dem ursprünglichen Keccak und dem tatsächlichen SHA3 in einem Abschnitt herausgestellt werden. Dies ist notwendig, da es keinen separaten Artikel zu Keccak mehr gibt (und auch unnötig ist, wenn sich nur Details ändern auf die man hier verweisen kann...) --Exploide (Diskussion) 18:14, 3. Okt. 2013 (CEST)

Bzgl "Unterschiede" siehe Yes, this is Keccak! vom Keccak-Team. Kurzfassing: SHA-3 ist Keccak. Keccak ist eine Familie. SHA-3 wäre eine Teilmenge. => Es gibt keine "internen Modifikationen", wie einige behauptet haben. --Zerpi (Diskussion) 20:23, 5. Okt. 2013 (CEST)

@Sepp: als quelle kannst du so ziemlich jede einfuehrung in hashfunktionen nehmen, das steht auch genau so in den folien von Kelsey. reduziert wird nur die sicherheit gegen preimage-angriffe, naemlich auf das gleiche niveau wie die gegen kollisionsangriffe. das liegt daran, dass die urspruenglichen sicherheitsanforderungen fuer SHA-3 auf MD-Konstruktionen zugeschnitten waren, das wird jetzt angepasst. das muesste man zum verstaendnis in dem abschnitt noch erklaeren, aber dazu muesste weiter oben erstmal erklaert werden, was ein sponge ist, was die capacity ist... --Mario d 20:40, 3. Okt. 2013 (CEST)

Zitat zur Kritik von [1] '...Die NIST hat nicht *Bitlängen* auf 128 und 256 Bits reduziert, sondern für die Sicherheitsgarantien 128 und 256 Bits die Bitlängen 256 und 512 standardisiert haben wollen und die krummen Längen, die es bei SHA-2 gab, wegfallen lassen (IMHO ohne triftigen Grund, bei Keccak kann man jederzeit beliebig krumme Hash-Längen bilden ohne zusätzliche Kosten - man nimmt einfach die ersten n bits vom 512er-Hash).
256 und 512 Bits sind gut bzw. fantastisch. Insbesondere haben wir für >256 Bits Sicherheit keine standardisierten asymmetrischen Verfahren. An sich sind nur asymmetrische Verfahren üblich, deren Sicherheit bei ~128 Bits ist (RSA kriegt man kaum besser, bei ECC gibt es welche mit 512 Bit Schlüssellänge, die 256 Bit Sicherheit bieten).

Bekommt man eine digitale Signatur mit einem 512-Bit-Hash, sucht man nach dem geheimen Schlüssel, weil man den viel einfacher findet als eine Hash-Kollision. Mit dem geheimen Schlüssel kann man fälschen, was man will. Da der billigste Weg zum geheimen Schlüssel ein Rechner-Einbruch ist, lohnt es sich nicht, mehr als 128 Bit Sicherheit zu nutzen.
Der andere NIST-Vorschlag war die Sicherheitsgarantie für Preimage von n bits für n bit lange Hashes auf n/2 zu kürzen, weil die Sicherheitsgarantie für Kollisionen auch nur n/2 ist. Das schlugen die Keccak-Autoren vor. Es ist Unsinn, für Preimage doppelt so viele Bits (quadratischen Aufwand) für die Sicherheit zu haben. Preimage ist auch ein Angriffsvektor, aber an sich nutzen die Leute den einfachsten Angriff. Das ist bei Hashes Kollision - durch das Geburststagsparadoxon hat man nur die Quadratwurzel des Aufwands.' Jla net.de (Diskussion) 21:05, 5. Nov. 2013 (CET)

artikelaufbau

da es um SHA-3 und Keccak einige verwirrung gab, wuerde ich vorschlagen, den abschnitt "Funktionsweise" in "Keccak" umzubenennen und fuer SHA-3 einen eigenen abschnitt anzulegen, der erklaert warum welche parameterwahlen getroffen wurden. --Mario d 08:03, 6. Okt. 2013 (CEST)

Abschnitt Kritik

Ich teile zwar die Kritik (einseitige Orientierung an Hardware-Implementierung) fände es aber besser, diese Kritik zu belegen (wer hat sie wann geäußert..?). Hat jemand einen Beleg dafür zur Hand? --Beloumi (Diskussion) 18:11, 14. Feb. 2014 (CET)

Leider habe ich auch nichts nahmhftes gefunden. Ich könnte zwar fünf oder sechs Quellen nennen aber eben alles eben nur aussagen von irgend welchen unbedeutenden Leuten, auf irgend welchen blogs und Mailinglisten. Auch da [2] wird nur angemerkt, dass das viele kritisiert haben. Gibt auch einige Benchmakrs, die bestätigen dass er in SW eher langsam ist. Aber eben niemand Namhaftes, der sagt, dass das ein Problem ist. Das einzige was ich gefunden habe ist eine Aussage, wo gemeint wurde, dass Sicherheit bei der auswahl von SHA-3 wichtiger sei als Geschwindigkeit. Das hat sich wohl auf den Kontext bezogen. Ist aber eben selbst auch keine Kritik. --Fabiwanne (Diskussion) 19:42, 14. Feb. 2014 (CET)

Die Kritik lässt sich wohl nach Wikipedia-Standards nicht belegen. Die Entscheidung für Keccak wird zwar auf Krypto-Mailinglisten, Blogs u.a. viel kritisiert, aber etwas halbwegs Offizielles wird sich vermutlich nicht finden. Andererseits ist unstrittig und belegbar, dass z.B. Skein und BLAKE (und auch SHA-2) in der Software-Performance besser abschneiden. Wie in manchen anderen Fällen finde ich hier auch: Eigentlich wäre die Kritik sehr angebracht, aber da sich keine guten Belege finden, kann sie in Wikipedia nicht gut formuliert werden. --Beloumi (Diskussion) 09:57, 15. Feb. 2014 (CET)

Sagen wir so: Auch wenn das viele das ganz gerne verschweigen und ändern wollen ist geschätzt 80% der Wikipedia einfach nicht belegt. Drück mal auf Zufallsartikel und guck ob der erste Abschnitt belegt ist. Die Eigenschaft dass er in SW eher langsam ist habe ich belegt. Dass die entspechenden renomierteren Quellen Keccak deswegen nicht direkt angreifen ist mehr eine Sache der Höflichkeit. Wenn man sagt, das es durchaus sinn macht, dass das bei der Auswahl eine Rolle spielt kann eigentlich jeder lesen, was die Meinung des Autors ist. In eine wissenschaftliche Ausarbeitung passt aber einfach nicht rein "Und deswegen ist der scheiße". Das kommt dann wenn man sich's nicht verkneifen kann auf den persönlichen blog. Ich habe mir gedacht jeder der hier editiert hat's schonmal gehört und hatte gehoft, dass es sich komentarlos unter den 80% unbelegte teile einordet, die einfach trivial genug sind als dass sie jemand bestreitet und deswegen nie zur Diskussion gestellt werden. --Fabiwanne (Diskussion) 03:29, 16. Feb. 2014 (CET)

Dass sich renommierte Leute mit Kritik am NIST sehr zurückhalten, ist ein eigenständiges Problem. Ich vermute, dass darin das Problem der fehlenden Belege begründet ist. Ansonsten finde ich es nicht so trivial, ein einseitiges Augenmerk auf die Hardware-Performance zu kritisieren. Viele finden das wahrscheinlich nicht Kritik-würdig. Keccak ist ja nicht wirklich schlecht in Software, es gab meines Wissens nur zwei Kandidaten, die mit klarem Abstand besser waren. Aber eine wirkliche gute Lösung für eine Wikipedia-Formulierung gibt es wohl nicht. Von mir aus lassen wir den Abschnitt wie er ist.--Beloumi (Diskussion) 21:03, 16. Feb. 2014 (CET)

Link kaputt

Der Link zur Uni Oldenburg unter »Weblinks« scheint kaputt, vielleicht ist auch die Seite down, vgl. http://downforeveryoneorjustme.com/http://celan.informatik.uni-oldenburg.de/kryptos/info/keccak/overview/ weiß jemand eine andere "Anschauliche Erklärung des Algorithmus" die verlinkt werden kann oder will selber eine schreiben? -- 22:28, 3. Jun. 2014 (CEST) (ohne Benutzername signierter Beitrag von ManuelRött (Diskussion | Beiträge))

Wahrscheinlichkeit der Kollision

Bei einer Hashfunktion, die einen Text auf 512 bit abbildet, gibt es nur 2**512 verschiede Hashwerte. Und da es ja offensichtlich viel viel mehr Texte gibt, ist klar, dass es zu jedem Hash Millionen von Texten gibt. D.h. die Wahrscheinlichkeit von Kollisionen ist sehr hoch. Um nicht zu sagen sie ist 1. Wieso behauptet der Text, Kollisionen wären extrem unwahrscheinlich? Wenn man nur die Dokumente auf der eigenen Festplatte betrachtet, mag es schon sein, dass es da keine Kollisionen gibt. Aber seriös mathematisch betrachtet sind Kollisionen zu Tausenden da. Und das ist völlig unabhängig davon, wie der Hash-Algo funktioniert. Ob er den Text in 5 Runden verquirlt oder in 50 Bastilliarden Runden, das ändert daran nichts. Und auch wenn er zwischendrin die Bits 1000 mal nach links verschiebt und in der nächsten Runde 1000 mal nach rechts: am Ende projeziert er jeden Text auf 512 bits. Das sind gerade einmal 64 Byte. --2.246.89.215 09:57, 14. Nov. 2016 (CET)

„nur 2**512 verschiedene Hashwerte“? Hast du dir mal überlegt, wie viele das sind? -- HilberTraum (d, m) 14:38, 14. Nov. 2016 (CET)

Kollisionen sind m.W. v.a. dann ein Problem, wenn man diese geziehlt herbeiführen kann--91.20.189.33 09:12, 30. Mär. 2018 (CEST)

Das sind 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096 verschiedene Hashwerte das sind 13 Quinvigintilliarden soll es so viele Texte geben. --Jannes Althoff (Diskussion) 12:41, 2. Sep. 2019 (CEST)

SHAKE?

Das taucht in der Tabelle auf, aber der Artikel erklärt nicht, was das ist. --RokerHRO (Diskussion) 14:21, 24. Feb. 2017 (CET)