Verfahren der Kryptographie, Teil 17: SHA-3 steht als Alternative und Ersatz bereit
Die Hashfunktionen der SHA-2-Familie sind noch für einige Zeit sicher. Trotzdem gibt es bereits einen Nachfolger: 2007 startete das US-amerikanischen National Institute of Standards and Technology (NIST) einen Wettbewerb zur Suche nach einem neuen kryptographischen Hashalgorithmus als Nachfolger von SHA-2, genannt SHA-3. So ein Wettbewerb hatte sich bereits bei der Suche nach dem DES-Nachfolger AES bewährt, und auch bei der Suche nach SHA-3 war man erfolgreich.
2. November 2007: Das NIST startet eine neue Castingshow
Am 2. November 2007 hat das NIST die Suche nach SHA-3 offiziell gestartet, indem eine entsprechende "Federal Register Notice" (PDF) mit den Anforderungen an den neuen Algorithmus und den Regeln des Wettbewerbs veröffentlicht wurde. Die Vorbereitungen für den Wettbewerb hatten schon 2004 begonnen, eine Draft-Version der Ausschreibung war im Januar 2007 veröffentlicht worden.
Der Wettbewerb bestand aus drei Runden. Für die 1. Runde wurden bis zum 31. Oktober 2008 64 Vorschläge eingereicht. 51 davon erfüllten die Mindestanforderungen und wurden vom NIST als Kandidaten für die erste Runde ausgewählt und am 9. Dezember 2008 veröffentlicht. Damit war die 1. Runde offiziell eröffnet.
Runde 1: Aus 51 Kandidaten werden 14
Die Kandidaten der 1. Runde wurden vom 25. bis 28. Februar 2009 auf der First SHA-3 Candidate Conference vorgestellt und diskutiert. Danach wurden 14 Kandidaten für die 2. Runde ausgewählt und am 24. Juli 2009 veröffentlicht. Die ausgewählten Kandidaten wurden von ihren Entwicklern teilweise überarbeitet und die aktualisierten Vorschläge am 28. September 2009 veröffentlicht. Damit startete die 2. Runde des Wettbewerbs.
Runde 2: Aus 14 Kandidaten werden 5 Finalisten
Die 14 Kandidaten der 2. Runde wurden am 23. und 24. August auf der Second SHA-3 Candidate Conference vorgestellt und diskutiert. Die dabei gesammelten Informationen, vor und nach der Konferenz von Kryptologen eingereichte Kommentare sowie interne Reviews führten dann zur Auswahl von 5 Finalisten, die am 9. Dezember 2010 veröffentlicht wurden. Die finalen Einreichungen wurden am 31. Januar 2011 veröffentlicht.
Runde 3: Aus 5 Finalisten wird 1 Sieger
Die Kandidaten der Finalrunde wurden am 22. und 23. März 2012 auf der Third SHA-3 Candidate Conference diskutiert. Auch zu den Finalisten gab es von den Kryptologen reichlich weitere Rückmeldungen vor und nach der Konferenz. Zusammen mit internen Untersuchungen führte das zur Wahl des Siegers. Der wurde am 2. Oktober 2012 veröffentlicht (PDF): Es handelt sich um den Algorithmus Keccak, der von Guido Bertoni, Joan Daemen, Michaël Peeters und Gilles Van Assche entwickelt wurde.
Und jetzt wird daraus ein Standard
Danach begann die Standardisierung des neuen Algorithmus, die am 5. August 2015 mit der Veröffentlichung von FIPS 202, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions" (PDF), endete. Zwischendurch gab es dabei noch Ärger, weil das NIST Keccak für die Veröffentlichung als SHA-3 verändern und damit zu Gunsten der Performance seine Sicherheit schwächen wollte. Was angesichts der Enthüllungen von Edward Snowden natürlich gar nicht gut ankam. Zumal die Kritik durchaus berechtigt war, was das NIST zur Einsicht brachte, den Algorithmus doch unverändert als SHA-3 zu veröffentlichen.
Der Unterschied zwischen SHA-2 und SHA-3
Im Gegensatz zu SHA-2, dass ebenso wie die gebrochenen Funktionen MD5 und SHA-1 der Merkle-Damgård Konstruktion folgt, basiert SHA-3 auf einer sog. Sponge-Funktion (Schwamm-Funktion). Dabei werden die Eingabe erst vom "Schwamm" aufgesaugt und dann herausgequetscht.
Die Nachricht wird in r Bit lange Datenblöcke aufgeteilt, die in einen Zustandsvektor eingelesen werden. Danach wird der Zustandsvektor in mehreren Runden umgewandelt. Für einen n Bit langen Hashwert werden nach dem letzten Schritt
- n Bit des Zustandsvektors als Hash-Wert verwendet, falls n ≤ r ist
- die n Bits des Hashwerts in mehreren Schritten, zwischen denen der Zustandsvektor erneut permutiert wird, entnommen (maximal r Bit pro Schritt).
Die völlig andere Konstruktion ist ein Vorteil von SHA-3: Sollte irgendwann ein erfolgreicher Angriff auf SHA-2 entwickelt werden, lässt der sich nicht auf SHA-3 übertragen. Bis es soweit ist, kann man problemlos SHA-2 oder SHA-3 verwenden, je nachdem, welche der jeweiligen Vor- oder Nachteile für den bestimmten Einsatzzweck relevant sind. Sollte SHA-2 irgendwann unsicher werden, steht SHA-3 als Ersatz bereit.
Die Sicherheit von SHA-3
Angriffe wurden bisher nur für Implementierungen mit reduzierter Rundenzahl entwickelt. Das sich dabei bessere Ergebnisse als bei einem Brute-Force-Angriff auf die vollständige Implementierung ergeben ist wenig verwunderlich (das wäre es höchstens, wenn es nicht so wäre).
Die Bundesnetzagentur stuft im
Algorithmenkatalog
2016 vom 9.12.2015 die Hashfunktionen SHA3-256, SHA3-384 und SHA3-512
mindestens bis Ende 2022 als sicher und für die Anwendung bei
qualifizierten elektronischen Signaturen geeignet ein.
Und das Bundesamt für Sicherheit in der Informationstechnik hat in der
Technischen Richtlinie BSI TR-02102-1
"Kryptographische Verfahren: Empfehlungen und Schlüssellängen"
in der Version 2016-01 vom 15.2.2016 ebenfalls die Funktionen SHA3-256,
SHA3-384 und SHA3-512 als "kryptographisch stark" eingestuft.
Auf die Frage Wer braucht SHA-3? bin ich schon direkt nach der Veröffentlichung des Gewinners 2012 eingegangen, dem ist im Grunde nichts hinzu zu fügen. Bis auf eins: Der dort erwähnte Algorithmus RIPEMD-160 ist laut Bundesnetzagentur nicht mehr sicher. Er war bis Ende 2015 nur noch für die Prüfung qualifizierter Zertifikate geeignet.
In der nächsten Folge werden endlich die schon oft erwähnten, bisher aber nie beschriebenen Angriffe auf Hashfunktionen vorgestellt.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Verfahren der Kryptographie, Teil 18: Angriffe auf Hash-Funktionen
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Kryptographie - Ein Überblick
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 1.18 - Welche Kryptoverfahren sollte man verwenden bzw. meiden?
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 1.18 - Sicherheit von Kryptoverfahren
Vorschau anzeigen
entwickler.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.