Zusammenfassung

  • Der RFC 1321 vom April 1992 beschrieb MD5 samt C-Referenzimplementierung, Testtreiber und sieben Sollwerten. Entwickler konnten so ihren laufenden Code an denselben Ausgaben messen.
  • Der RFC 6151 von 2011 bewertete die Sicherheit neu: Für Anwendungen mit erforderlicher Kollisionsresistenz, etwa digitale Signaturen, war MD5 ungeeignet geworden. Die alten Testwerte blieben korrekte Antworten für den alten Rechenweg.

Vom gedruckten Verfahren zum eigenen Rechner

Ein MD5-Wert sieht auf dem Bildschirm wie eine rätselhafte Zeile aus Ziffern und Buchstaben aus. Der RFC 1321 erklärte die Arbeit davor. Die Nachricht wurde mit Bits bis zu einer festgelegten Grenze aufgefüllt, ihre ursprüngliche Länge angehängt und dann in 512-Bit-Blöcken mit einem Zustand aus vier 32-Bit-Wörtern verarbeitet. Wer die Byte-Reihenfolge verwechselte oder ein Füllbit verschob, erhielt für dieselbe Nachricht einen anderen Wert. Eine gemeinsame Spezifikation musste deshalb bis zum einzelnen Bit reichen.

Rivest legte den Werkzeugkasten bei. Anhang A enthielt global.h, md5.h, md5c.c und mddriver.c. Der Treiber konnte Zeichenketten, Dateien und die Standardeingabe verarbeiten. Mit -x führte er eine feste Testreihe aus. Anhang A.5 nannte die erwarteten Ausgaben für sieben Eingaben, angefangen bei der leeren Zeichenkette, a und abc. Für abc lautete die Ausgabe 900150983cd24fb0d6963f7d28e17f72. Die Lösungen standen hinten im Heft, damit ein Programmierer seine eigene Arbeit daran prüfen konnte. Ein abweichendes Ergebnis führte direkt zurück zu den Rechenschritten.

Der Quelltext stammte aus RSAREF, einem kryptographischen Werkzeug für Privacy-Enhanced Mail. Im RFC verband er gedruckte Regeln mit ausführbarem Beispiel. Ein Team konnte eine unabhängige Fassung schreiben und ihre Ausgabe mit den veröffentlichten Werten vergleichen; ein anderes konnte den Beispielcode auf eine neue Maschine bringen. Das Dokument bezeichnete die Implementierung als portabel und erwähnte sogar eine Optimierung für bestimmte Little-Endian-Rechner. Solche Details waren praktischer als eine Versicherung, alle würden sich schon irgendwie verstehen.

Auch die damalige Sicherheitsabsicht ist im Text gut zu sehen. MD5 entwickelte MD4 weiter. Nach Rivests Darstellung könnte MD4 schneller übernommen worden sein, als die verfügbare kritische Prüfung rechtfertigte. MD5 nahm etwas Geschwindigkeit zurück, um eine größere Sicherheitsreserve anzustreben. Als Einsatzgebiet nannte der RFC digitale Signaturen: Eine große Datei wird zunächst verdichtet, bevor eine Operation mit dem privaten Schlüssel folgt. Das Verfahren wurde zur öffentlichen Prüfung und möglichen Standardisierung freigegeben; der RFC selbst trug die Kategorie Informational. Mit dem Rechenrezept reiste also eine Erwartung über die Schwierigkeit von Kollisionen.

Die sieben Testausgaben beantworteten die handwerkliche Frage: Rechnet dieses Programm MD5 so, wie der Text es vorgibt? Für eine Sicherheitsanwendung kam eine zweite Frage hinzu: Welche Nachrichtenpaare kann ein Angreifer gezielt erzeugen? Die Antwort darauf entsteht aus Kryptanalyse, nicht aus der Zahl erfolgreich bestandener Beispielaufgaben. Man kann jede Übung im Anhang richtig lösen und später erfahren, dass die zugrunde liegende Sicherheitsannahme revidiert werden musste.

Im März 2011 veröffentlichte die IETF den RFC 6151. Nach publizierten Angriffen gegen MD5 erklärte er das Verfahren für Anwendungen mit erforderlicher Kollisionsresistenz, besonders digitale Signaturen, für ungeeignet. Andere Verwendungen, darunter HMAC-MD5 oder Prüfsummen zur Erkennung zufälliger Fehler, behandelte er gesondert; neue Protokollentwürfe sollten HMAC-MD5 meiden. Die Rechnung für abc blieb identisch. Geändert hatte sich, welche Sicherheitszusage man an diese Rechnung hängen durfte.

So entsteht ein aufschlussreiches Dokumentenpaar. Der RFC von 1992 machte unabhängige Implementierung ungewöhnlich leicht überprüfbar: Regel, Beispielcode und beobachtbare Ausgaben standen beisammen. Der Text von 2011 ordnete den daraus gewonnenen Hash neu ein, nachdem sich die Angreifermöglichkeiten deutlicher gezeigt hatten. Ein korrektes MD5-Programm blieb korrekt. Für eine digitale Signatur brauchte man inzwischen eine andere Grundlage. Die Musterlösung blieb stehen; die Prüfungsfrage wechselte.