Dipl.-Inform. Carsten Eilers

Erst mal ist an Keccak aus Sicherheitssicht nichts auszusetzen. Ebensowenig wie an den aktuellen SHA-2-Algorithmen, wie beispielsweise Bruce Schneier klargestellt hat. Und das ist auch schon der größte Kritikpunk: Wofür brauchen wir einen Nachfolger für einen Algorithmus, der auf absehbare Zeit noch sicher genug ist?

Aus diesem Grund hatte Bruce Schneier auch einige Tage vor der Veröffentlichung des Gewinners vorgeschlagen, auf einen Abschluss des Wettbewerbs zu verzichten. Keiner der Final-Kandidaten für SHA-3 bietet wirklich Vorteile gegenüber SHA-2. Jedenfalls keine, die einen Wechsel nötig erscheinen lassen.

Und entsprechend ist die Wahl des NIST jetzt auch ausgefallen: Keccak wurde ausgewählt wegen seines eleganten Designs, seiner großen Sicherheitsmarge, seiner guten allgemeinen Leistung, seiner ausgezeichneter Effizienz in der Hardware-Implementierungen und seiner Flexibilität. ("NIST chose KECCAK over the four other excellent finalists for its elegant design, large security margin, good general performance, excellent efficiency in hardware implementations, and for its flexibility.", PDF)

Ein weiterer Vorteil von Keccak: Sowohl Design als auch Implementierung ähneln in keiner Weise seinem Vorgänger SHA-2. Was bedeutet, dass die gegen einen Algorithmus entwickelten Angriffe nicht einfach auf den anderen übertragen werden können. Das NIST geht davon aus, dass SHA-2 noch einige Zeit sicher ist. Aber sollte ein erfolgreicher Angriff entwickelt werden, wird der mit ziemlicher Sicherheit keine Gefahr für SHA-3/Keccak darstellen, so dass eine sichere Alternative zur Verfügung steht. Und für was man SHA-3 ansonsten noch nutzen könnte, kann man sich ja in den nächsten Jahren überlegen.

Vorsicht vor neuen Implementierungen!

Die SHA-3-Kandidaten wurden alle sehr genau untersucht, die Algorithmen enthalten also mit an Sicherheit grenzender Wahrscheinlichkeit keine Schwachstellen. Das gilt aber nicht für die nun benötigten Implementierungen. Solange keine zwingende Notwendigkeit besteht (SHA-2 also sicher ist), sollte man sich beim Einsatz von SHA-3 zurückhalten und abwarten, ob die ggf. genutzte Implementierung sicher ist. Es wäre doch ziemlich ärgerlich, Opfer eines Angriffs auf einen Implementierungsfehler in SHA-3 zu werden, obwohl man problemlos die bewährte Implementierung von SHA-2 hätte verwenden können, oder?

SHA-1: Die Einschläge kommen näher

SHA-2 und sein Vorgänger SHA-1 stammen von den schon länger als unsicher eingestuften Algorithmen MD4 und MD5 ab. Die Veröffentlichung einer Schwachstelle in SHA-1 war der Auslöser für die Suche nach einem SHA-2-Nachfolger. Nach der Ankündigung von SHA-3 wurden nun von Jesse Walker Berechnungen veröffentlicht, wie lange es noch dauert, bis Kollisionsangriffe auf SHA-1 praktikabel werden. Bruce Schneier hat die auf einer geschlossenen Mailingliste veröffentlichte Berechnung in seinem Blog vorgestellt. Ein "organized crime syndicate" dürfte einen Angriff 2018 finanzieren können, ein Universitäres Forschungsprojekt 2012. Es wird also Zeit, auf den Einsatz von SHA-1 zu verzichten und SHA-2 (oder evtl. auch SHA-3) zu verwenden.

Etwas Verschwörungstheorie gefällig?

Ben Laurie fragt in seinem Blog, wieso SHA-3 gerade in Hardware so schnell sein soll. Auf den meisten Plattformen werden die Krypto-Funktionen in Software implementiert. Allein schon, weil auch das Übertragen der Daten zu spezieller Krypto-Hardware und zurück aufwendig ist und sich für die meisten Einsatzzwecke schlicht und einfach nicht lohnt. Hardware-Implementierungen wählt man nur für spezielle Zwecke. Zum Beispiel, um Funktionen zu brechen. Und zufällig wurde auch der AES-Algorithmus Rijndael u.a. deshalb ausgewählt, weil er sich effektiv in Hardware implementieren lässt (was auch eine der Design-Anforderungen war). Und wieder zufällig so, dass es für das Knacken von Verschlüsselungen günstig ist. Vorhandene Verbindungen zwischen der US-amerikanischen National Security Agency (NSA) und dem NIST sind in diesem Zusammenhang natürlich zusätzliche Nahrung für Verschwörungstheorien.

Es gibt aber einfachere Erklärungen für die Hardware-freundlichkeit der Algorithmen (die ja im Gegenzug nicht dazu führt, dass die Software-Implementierung fürchterlich langsam wird): Smartcards etc. profitieren von der Hardware-Implementierung, und wer weiß schon, für was SHA-3 alles eingesetzt wird? Als der SHA-3-Wettbewerb 2007 gestartet wurde, kam das erste iPhone gerade auf den Markt, der Erfolg von Smartphones war damals noch nicht einmal zu erahnen (zumindest nicht für typische Behördenmitarbeiter und "Otto Normaluser"). Heutzutage klingt es doch wie eine gute Idee, wenn man in die Geräte zumindest theoretisch Hardware-basierte Krypto-Funktionen integrieren kann, oder?

Außerdem wurden sowohl die AES- als auch SHA-3-Kandidaten veröffentlicht und ausführlich untersucht. Das klingt eigentlich nicht nach einem guten Ansatz, um eine Hintertür im Algorithmus zu verbergen, oder? Es sei denn, man möchte die Verschwörungstheorie auf die Spitze treiben: Die Wettbewerbe dienten dann nur dazu, die Kandidaten auszusieben, bei denen die in allen vorhandene Hintertür auffällt. Das Ergebnis wäre dann ein Algorithmus mit unauffindbarer Hintertür. Vielleicht sollte man sich dann ja mal nach dem gleichen System auf die Suche nach dem Perpetuum mobile machen? Oder der Quadratur des Kreises mit Lineal und Zirkel?

Genug Verschwörungstheorie, zurück zu den Fakten

Kommen wir wieder zu den Fakten. Die Algorithmen sind sicher und enthalten keine Hintertür. Mehr Gedanken würde ich mir dann über die Implementierungen machen. Denn die werden im allgemeinen nicht veröffentlicht bzw. (im Fall von Open Source Software) kaum untersucht. Wenn es irgendwo Hintertüren oder auch nur Schwachstellen gibt, dann da. Daher ja auch mein Rat, mit dem Einsatz von SHA-3 zu warten, bis die Implementierungen bewiesen haben, dass sie sicher sind.

Im Gegensatz zu AES, dessen Vorgänger DES bei seiner Veröffentlichung bereits gebrochen war und dessen Alternative 3-DES fürchterlich langsam ist, besteht bei SHA-3 kein Grund, schnell zu wechseln. Im Abwandlung des Spruchs vom weiter gerittenen toten Pferd könnte man hier sagen "Wieso wollen Sie das Pferd wechseln, wenn es noch quicklebendig ist und nicht mal Anzeichen einer Krankheit zeigt?"

Sollte SHA-2 irgendwann gebrochen werden, steht SHA-3 als Alternative bereit. Sollten dann Zweifel an den Implementierungen bestehen, kann man immer noch abwägen, was gefährlicher ist: Ein Angriff auf den Algorithmus von SHA-2 oder auf die Implementierung von SHA-3. Aber bis dahin dürfte es noch einige Zeit dauern.

Ach ja: Und dann gibt es ja noch jede Menge anderer Hash-Algorithmen, zum Beispiel die "Verlierer" des SHA-3-Wettbewerbs oder der in Europa entwickelte RIPEMD-160. SHA-3 ist ja eigentlich nur für die USA relevant, und auch dann nur, so weit man den entsprechenden Vorgaben entsprechen muss. Der Rest der Welt hat die freie Wahl!

Carsten Eilers