Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

122
A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr
121
A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr
Alle Linien führen der Blocklänge entsprechend viele Alphabetzeichen
Klartextblöcke haben die Länge des Schlüssels der Blockchiffre
Addition mod 2
Liegt die Blockchiffre direkt im Transformationsweg vom Klartext über den Schlüsseltext zum
Klartext, ist keine Vorausberechnung der Blockchiffre möglich. Andernfalls kann zumindest jeweils
ein Block vorausberechnet werden.
Insgesamt ergeben sich die Einträge der unteren 3 Zeilen von Bild 3-51.
Speicher für
Zwischenergebnisblock
n-1
3.8.3 Kollisionsresistente Hashfunktion aus Blockchiffre
Klartextblock
n
Letzter
Block
Verschlüsselung
Aus Sicherheitsgründen sollte gelten:
Schlüssellänge der Blockchiffre nicht wesentlich länger als ihre Blocklänge.
Bild 3-52: Konstruktion einer kollisionsresistenten Hashfunktion aus einer deterministischen
Blockchiffre
Bild 3-52 ist in der gleichen Anordnung wie Bild 3-42 gezeichnet. Deshalb fällt auf, daß die Klartextblöcke
an einer unüblichen Stelle in die Blockchiffre eingespeist werden – nämlich als Schlüssel.
In diesem Abschnitt wird beschrieben, wie aus deterministischen Blockchiffren, deren Schlüssel nicht
(wesentlich) länger als die Blocklänge ist, kollisionsresistente Hashfunktionen konstruiert werden
können.
Wie in §3.5.1 für kollisionsresistente Permutationenpaare bereits erklärt wurde, kann das Finden
von Kollisionen allenfalls komplexitätstheoretisch schwer sein – informationstheoretisch ist es leicht,
denn ein Angreifer könnte immer alle Möglichkeiten durchprobieren. Entsprechendes gilt für kollisionsresistente
Hashfunktionen: Da sie beliebig lange Argumente auf Werte fester Länge abbilden,
gibt es beliebig viele Kollisionen, d.h. verschiedene Argumente, die auf denselben Wert abgebildet
werden. Ein Angreifer muß also nur genügend ausdauernd suchen (können), um Kollisionen zu
finden.
Das Beste, was man sich wünschen kann, wäre eine effiziente Konstruktion, die aus beliebigen
Blockchiffren kollisionsresistente Hashfunktionen gewinnt, die bewiesenermaßen so sicher wie die
verwendete Blockchiffre sind. Leider ist eine solche Konstruktion nicht bekannt – unter den zahlreichen
Vorschlägen gibt es nicht einmal solche, die zwei der drei kursiv hervorgehobenen
Eigenschaften haben. Da in §3.6.4 bereits (unter der Faktorisierungsannahme) bewiesenermaßen
sichere kollisionsresistente Hashfunktionen angegeben wurden, geht es hier vor allem um größere
Effizienz. Deshalb wird eine gemäß Bild 3-12 „wohluntersuchte“ Konstruktion angegeben, wie aus
deterministischen Blockchiffren, deren Schlüssel aus Sicherheitsgründen hier nicht (wesentlich)
länger als die Blocklänge sein dürfen [LuRa_89], sehr effizient kollisionsresistente Hashfunktionen
konstruiert werden können.
Wichtig ist – ganz egal wie die Hashfunktion konstruiert wird –, daß der Initialisierungswert
festgelegt oder die Nachricht postfixfrei90 codiert ist. Sonst gibt es folgende trivialen
Kollisionen: Bei der rundenweisen Berechnung des Hashwertes einer Nachricht entstehen mit den
Zwischenergebnisblöcken jeweils passende Initialisierungswerte für die um die bisher abgearbeiteten
Klartextblöcke verkürzte Nachricht.
Um diese mögliche Schwäche zu vermeiden und auch um beim Auffüllen der Nachricht auf ein
Vielfaches der Schlüssellänge der Blockchiffre zu wissen, wie viele Bits aufgefüllt wurden, sollte der
letzte Klartextblock die Länge der Nachricht in Bit enthalten [LaMa_92 Seite 57].
Außerdem wird für jede Hashfunktion, die Ergebnisse der Länge b liefert (also z.B. auch die
angegebene Konstruktion bei Verwendung einer Blockchiffre der Blocklänge b), durch Durchprobieren
des Nachrichtenraumes im Mittel nach etwa 2b/2 Versuchen eine Kollision gefunden. Dies
liegt am sogenannten Geburtstagsparadox: Damit mit Wahrscheinlichkeit 1/2 mindestens zwei
Menschen am gleichen Tag Geburtstag haben, werden nicht etwa 365/2, sondern nur etwa √⎺⎺⎺ 365
Menschen benötigt [DaPr_89 Seite 279-281].
Für viele Anwendungen wird bei der angegebenen Konstruktion der Einsatz von DES als Blockchiffre
also nicht ausreichen, da 232 Versuche von vielen möglichen Angreifern durchaus durchführbar
sind. Selbst eine Blocklänge von 128 Bit dürfte für die überschaubare Zukunft nicht genügen, da
demnächst auch 264 Versuche fähigen Angreifern möglich sein werden. Deshalb sollten kollisionsresistente
Hashfunktionen Ergebnisse von wenigstens 160 Bit Länge liefern.
In [DaPr_84, DaPr_89 Seite 265] wird folgende Konstruktion einer kollisionsresistenten Hashfunktion
aus einer deterministischen Blockchiffre (z.B. DES) vorgeschlagen:
Der zu hashende Klartext wird in Blöcke der Schlüssellänge der Blockchiffre unterteilt. In jeder
Runde wird einer der Klartextblöcke als Schlüssel der Blockchiffre verwendet.
Die Eingabe der Blockchiffre ist für die erste Runde ein Initialisierungswert, für die zweite und
alle folgenden Runden das Ergebnis der vorherigen Runde. (In Bild 3-52 wird der Initialisierungswert
sinnvollerweise als Zwischenergebnisblock Nummer 0 aufgefaßt.)
In jeder Runde wird nicht nur verschlüsselt, sondern auch die Eingabe der Blockchiffre modulo 2
zur Ausgabe addiert. Dies verhindert, daß ein Angreifer rückwärts rechnen kann, indem er einen
Schlüssel (sprich: Klartextblock) wählt, dann bezüglich des gewählten Schlüssels die Blockchiffre
invertiert (sprich: entschlüsselt) und so die Eingabe dieser Runde erhält. Auf diese Art könnte er,
wenn der Initialisierungswert frei wählbar ist, Kollisionen berechnen, indem er das Beschriebene mit
zwei unterschiedlichen Schlüsseln ausführt.
Das Ergebnis der letzten Runde ist die Ausgabe der Hashfunktion. (Damit dieser Hashwert von
anderen überprüft werden kann, muß ihnen auch der Initialisierungswert bekannt sein. Ist der
Initialisierungwert nicht global festgelegt, so muß er ihnen ggf. mitgeteilt werden.)
90 Kein Postfix, d.h. Endstück, einer postfixfrei abgebildeten Nachricht darf gleichzeitig postfixfreie Abbildung einer
anderen Nachricht sein.