8: Zufallsorakel. Wir suchen: Einfache mathematische Abstraktion für Hashfunktionen

Transkript

1 Stefan Lucks 8: Zufallsorakel 139 Kryptogr. Hashfunkt. (WS 08/09) 8: Zufallsorakel Unser Problem: Exakte Eigenschaften von effizienten Hashfunktionen nur schwer erfassbar (z.b. MD5, Tiger, RipeMD, SHA-1,...) = großes Problem in Beweisen die solche Hashfunktionen verwenden Wir suchen: Einfache mathematische Abstraktion für Hashfunktionen Unsere Idee: Modell idealisierter Hashfunktionen Wie sieht eine perfekte Hashfunktion aus? 139

2 Stefan Lucks 8: Zufallsorakel 140 Kryptogr. Hashfunkt. (WS 08/09) Warum Zufallsorakel? Hashfunktionen H : {0, 1} {0, 1} n Ideal wären zufällige Funktionen Für alle Inputs X {0, 1} : Zufallswert H(X) := Y zufällig gewählt aus {0, 1} n. Wir können eine solche Funktion nicht implementieren. ( Warum?) Aber wir können sie simulieren, durch ein Zufallsorakel: Liste von Paaren (X, Y ), initial leer. Input X. Wenn kein Eintrag (X, Y ) in Liste: Wähle Y {0, 1} n zufällig. Trage (X, Y ) in Liste ein. Gib H(X) = Y aus. 140

3 Stefan Lucks 8: Zufallsorakel 141 Kryptogr. Hashfunkt. (WS 08/09) 8.1: Beispiel 8.1: Beispiel: Digitale Signaturen ( Full Domain Hash ) RSA Signatur vom Hashwert einer Nachricht Geg: Nachricht M, RSA (N, e, d) und Hashfunktion H : {0, 1} Z N M X = H(M) Y = X d mod N Y Sign(M) Verify(M, Y ) X H(M) return X d mod N X = Y e mod N X = H(M) if X = X then return true else return false 8.1: Beispiel 141

4 Stefan Lucks 8: Zufallsorakel 142 Kryptogr. Hashfunkt. (WS 08/09) 8.1: Beispiel Wie sicher ist FDH? Satz 8.1 [Bellare-Rogaway 1993] Full Domain Hash ist sicher ( existentially unforgeable ) im Zufallsorakelmodell. Beweis: ( Tafel) Erläuterung: Der Angreifer kennt den öffentlichen Schlüssel und kann sich zu beliebigen Nachrichten M i passende Signaturen Sig i erzeugen lassen. Um zu gewinnen, müsste der Angreifer dann aber selbst die Unterschrift Sig zu irgend einer von ihm gewählten Nachricht M M i finden... Ist RSA eine Einwegfunktion, und ist H ein Zufallsorakel, dann ist FDH existentially unforgeable. 8.1: Beispiel 142

5 Stefan Lucks 8: Zufallsorakel 143 Kryptogr. Hashfunkt. (WS 08/09) 8.2: Unmöglickeit 8.2: Nicht-Implementierbarkeit von Hashfunktionen Große Frage: Was passiert, wenn man ein Zufallsorakel in einem kryptographischen Schema durch eine reale Hashfunktion ersetzt? (Keine) Antwort: Das Schema bleibt hoffentlich(!!) sicher, Bemerkung: Es gibt jedoch einige wenige (bösartig gewählte) Beispiele bei welchen dies garantiert nicht der Fall ist (siehe nächste Folie). Definition: Man nennt ein Kryptosystem nicht instantiierbar, falls es im Zufallsorakelmodell beweisbar sicher, jedoch unsicher für jede Implementation ist. 8.2: Unmöglickeit 143

6 Stefan Lucks 8: Zufallsorakel 144 Kryptogr. Hashfunkt. (WS 08/09) 8.2: Unmöglickeit Eigentlich gibt es keine Zufallsorakel Satz 8.2 [Canetti-Goldreich-Halevi, 1998] Sei ein (im Standard- oder Zufallsorakelmodell) sicheres Signaturschema gegeben. Es gibt ein Signaturschema welches beweisbar sicher im Zufallsorakelmodell ist, aber vollkommen unsicher für jede Implementation. Beweisskizze: Tafel 8.2: Unmöglickeit 144

7 Stefan Lucks 8: Zufallsorakel 145 Kryptogr. Hashfunkt. (WS 08/09) 8.3: Undifferenzierbarkeit 8.3: Undifferenzierbarkeit Frage: Wie muss eine Hashfunktion H aufgebaut sein, damit wir eine sichere Kompressionsfunktion C einfach in die Konstruktion einsetzen können, und die Hashfunktion ihrerseits sicher ist? Was heisst überhaupt sicher? Idee: Nimm an, C verhählt sich wie ein Zufallsorakel (mit konstanter Eingabegröße. Dann sollte H sich wie ein Zufallsorakel mit variabler Eingabegröße verhalten. Beispiel (negativ): Merkle-Damgård Beispiel (positiv): Prefix-Free Merkle-Damgård Aber: Nicht klar, ob diese Undifferenzierbarkeit wirklich das richtige Kriterium ist : Undifferenzierbarkeit 145

8 Stefan Lucks 8: Zufallsorakel 146 Kryptogr. Hashfunkt. (WS 08/09) 8.3: Undifferenzierbarkeit Definition 8.3 Eine Turingmaschine H mit Orakelzugriff auf ein ideales Primitv G wird berechenbar undifferenzierbar (engl. computationally indifferentiable) von einem idealen Primitv F genannt, falls ein Simulator S so existiert, dass für jeden Unterscheider D die Differenz vernachlässigbar ist. Pr[D H,G = 1] Pr[D F,S = 1] Bemerkungen: H ist eine Hashfunktionskonstruktion die Zugriff auf ein Zufallsorakel G (mit fixer Eingabelänge) hat. F ist ein Zufallsorakel beliebiger Eingabelänge. Aufgabe des Simulator ist, ein Orakel mit fixer Eingabelänge (fast) perfekt zu simulieren. 8.3: Undifferenzierbarkeit 146

9 Stefan Lucks 8: Zufallsorakel 147 Kryptogr. Hashfunkt. (WS 08/09) 8.3: Undifferenzierbarkeit Graphische Darstellung der Undifferenzierbarkeit Case I H G Case II F S? Distinguisher D Abbildung: Definition: H undifferenzierbar von F. 8.3: Undifferenzierbarkeit 147

10 Stefan Lucks 8: Zufallsorakel 148 Kryptogr. Hashfunkt. (WS 08/09) 8.3: Undifferenzierbarkeit Was bringt einem Undifferenzierbarkeit? Theorem 8.4 Sei ein Kryptosystem P gegeben mit Orakelzugriff auf ein ideales Primitv F. Sei C G ein Algorithmus (mit Orakelzugriff auf ein ideales Primitv G. Wenn F und C undifferenzierbar sind, dann können wir F durch C G in dem Kryptosystem P ersetzten und es wird dadurch nicht signifikant weniger sicher. (hier ohne Beweis) 8.3: Undifferenzierbarkeit 148

11 Stefan Lucks 8: Zufallsorakel 149 Kryptogr. Hashfunkt. (WS 08/09) 8.4: Bemerkungen 8.4: Bemerkungen Zufallsorakelmodell ist nützlich für erste Konstruktionen von (neuen) Kryptosystemen. Beweis im Zufallsorakelmodell keine Garantie für Sicherheit bei Implementation (aber erfahrungsgemäß starker Indikator dafür). Es sind keine effizienten Hashfunktionen bekannt die im Standardmodell sicher sind. 8.4: Bemerkungen 149