03.08.2013 Aufrufe

Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

46<br />

A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />

45<br />

A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />

c) Vernünftige Berechnungsmodelle (Tur<strong>in</strong>g-, RAM-Masch<strong>in</strong>e) s<strong>in</strong>d polynomial äquivalent, man<br />

muß sich also nicht auf e<strong>in</strong> genaues Masch<strong>in</strong>enmodell festlegen.<br />

Für die Praxis würde e<strong>in</strong> Polynom von hohem Grad als untere Schranke für Angreiferalgorithmus<br />

auf RAM-Masch<strong>in</strong>e reichen. (Und die leichten Algorithmen gehen <strong>in</strong> der Praxis meist höchstens<br />

bis l3 .)<br />

Anmerkung zu: nicht polynomial <strong>in</strong> l ≈ exponentiell <strong>in</strong> l<br />

Hier steht ke<strong>in</strong> Gleichheitszeichen, da es zwischen polynomial (lk mit festem k) <strong>und</strong> exponentiell<br />

(2l ) weitere Funktionen gibt, z.B. 2√⎺ l .<br />

4) Warum braucht man komplexitätstheoretische Annahmen? (z.B. „Faktorisierung<br />

schwer“, s. §3.4.1)<br />

Die Komplexitätstheorie kann bisher ke<strong>in</strong>e brauchbaren unteren Schranken beweisen.<br />

Für Kenner: Genauer liegt das Brechen bei vielen solchen Systemen offensichtlich <strong>in</strong>nerhalb<br />

von NP. (Im Pr<strong>in</strong>zip heißt NP gerade: Wenn man e<strong>in</strong>e Lösung geraten hat, kann man schnell<br />

testen, ob sie richtig ist. So war das z.B. <strong>in</strong> 1) mit der zu fälschenden Signatur.) Damit ist für<br />

solche Fälle klar, daß e<strong>in</strong> Beweis, daß das Brechen e<strong>in</strong>es solchen Systems exponentiell ist, P≠NP<br />

implizieren würde. Mit solch e<strong>in</strong>em Beweis ist also zunächst nicht zu rechnen, da seit vielen<br />

Jahren viele Wissenschaftler P≠NP zu beweisen oder zu widerlegen versuchen.<br />

Innerhalb von NP s<strong>in</strong>d ke<strong>in</strong>e passenden unteren Schranken bekannt, also würde es auch hier<br />

nichts nützen, wenn man sich z.B. mit e<strong>in</strong>er unteren Schranke l100 zufriedengäbe.<br />

1) Viele kryptographische Systeme s<strong>in</strong>d im Pr<strong>in</strong>zip brechbar: Wenn Schlüssel der festen<br />

Länge l verwendet werden, <strong>und</strong> genügend Information zur Verfügung steht, daß der Schlüssel im<br />

Pr<strong>in</strong>zip e<strong>in</strong>deutig ist, kann e<strong>in</strong> Angreiferalgorithmus im Pr<strong>in</strong>zip immer alle 2l Schlüssel durchprobieren<br />

<strong>und</strong> damit das System vollständig brechen. (Dies betrifft die meisten asymmetrischen<br />

Systeme, sowohl bzgl. Konzelation als auch Authentikation, weil i.allg. bei bekanntem c bzw. t<br />

nur e<strong>in</strong> d bzw. s möglich ist, <strong>und</strong> außer der Vernam-Chiffre auch symmetrische Konzelationssysteme<br />

bei Klartext-Schlüsseltext-Angriff mit genügend viel „Material“. Außerdem gilt analoges<br />

z.B. für das Fälschen der Signatur zu e<strong>in</strong>er bestimmten Nachricht: Der Angreifer weiß, daß se<strong>in</strong>e<br />

gefälschte Signatur Sig zur Nachricht x gut genug ist, wenn sie den Test test(t, x, Sig) besteht. Da<br />

es i.allg. e<strong>in</strong>e Obergrenze für die Länge von Signaturen gibt, muß er wieder nur endlich viele Sigs<br />

probieren.)<br />

Dieses erschöpfende Durchprobieren erfordert aber exponentiell viele Operationen, ist also<br />

z.B. für l > 100 nicht realistisch.<br />

Es bedeutet aber, daß das Beste im S<strong>in</strong>ne der Komplexitätstheorie, was der Entwerfer kryptographischer<br />

Systeme erhoffen kann, e<strong>in</strong> für den Angreiferalgorithmus <strong>in</strong> l exponentieller Aufwand<br />

ist.<br />

2) Nicht nur asymptotische „worst-case“-Komplexität:<br />

Komplexitätstheorie liefert hauptsächlich asymptotische Resultate.<br />

" behandelt hauptsächlich „worst-case“-Komplexität.<br />

5) Was für Annahmen macht man gern?<br />

Je kompakter <strong>und</strong> je länger (<strong>und</strong> von je mehr Leuten) untersucht, desto vertrauenswürdiger. In<br />

gewisser H<strong>in</strong>sicht werden also kryptographische Systeme, wenn sie nicht <strong>in</strong>formationstheoretisch<br />

sicher s<strong>in</strong>d, mit zunehmendem Alter entweder gebrochen oder vertrauenswürdiger. Allerd<strong>in</strong>gs<br />

muß man, schon wegen des Fortschritts der Rechnerleistungen, die Parameter l allmählich<br />

erhöhen. (Vorsicht, wenn Sachen lange geheim bleiben sollen, oder Signaturen für Jahre gültig,<br />

also auch unfälschbar, se<strong>in</strong> sollen!)<br />

E<strong>in</strong> NP-vollständiges Problem wäre natürlich besonders nett, aber man hat bisher ke<strong>in</strong>s<br />

entdeckt, das auch im S<strong>in</strong>ne von 2) hart wäre.<br />

Es ist schön zu wissen, wie sich die <strong>Sicherheit</strong> verhält, wenn der <strong>Sicherheit</strong>sparameter l (Verallgeme<strong>in</strong>erung<br />

der Schlüssellänge; praktisch nützlich) genügend groß ist. Beim praktischen E<strong>in</strong>satz<br />

kryptographischer Systeme muß man die Werte aller Parameter aber konkret festlegen. Was e<strong>in</strong>en<br />

dann <strong>in</strong>teressiert ist: Wie sicher ist das System bei konkreten Parameterwerten? Oder anders<br />

formuliert: Wo beg<strong>in</strong>nt „genügend groß“?<br />

Die „worst-case“-Komplexität ist für <strong>Sicherheit</strong> ungenügend, ebenso „average-case“-Komplexität.<br />

(Denn es soll ja nicht nur e<strong>in</strong> paar Schlüssel geben, die nicht gebrochen werden können, sondern<br />

die meisten sollen nicht gebrochen werden.)<br />

Man wünscht sich: Das Problem soll fast überall, d.h. bis auf e<strong>in</strong>en verschw<strong>in</strong>denden<br />

Bruchteil der Fälle, schwer se<strong>in</strong>. (D.h. wenn e<strong>in</strong> braver Benutzer se<strong>in</strong>en Schlüssel zufällig wählt,<br />

soll die Wahrsche<strong>in</strong>lichkeit überwältigend se<strong>in</strong>, daß er nicht gebrochen wird.)<br />

6) Was, wenn sich Annahme als falsch herausstellt?<br />

a) Andere Annahme treffen.<br />

b) Genauere Analyse, z.B. Berechnungsmodell genau fixieren (RAM- oder Tur<strong>in</strong>gmasch<strong>in</strong>e?<br />

Wie viele Bänder bei der Tur<strong>in</strong>gmasch<strong>in</strong>e? usw.) <strong>und</strong> dann untersuchen, ob Polynom von<br />

genügend hohem Grad.<br />

Ist der <strong>Sicherheit</strong>sparameter l , so verlangt man:<br />

Wenn l → ∞, dann Brechwahrsche<strong>in</strong>lichkeit → 0.<br />

Man hofft: Die Brechwahrsche<strong>in</strong>lichkeit s<strong>in</strong>kt schnell, so daß man l nicht allzu groß machen muß.<br />

7) Beweisziel: Wenn der Angreiferalgorithmus das kryptographische System brechen kann,<br />

dann kann er auch das als schwer angenommene Problem lösen.<br />

3) Wie def<strong>in</strong>iert man leicht <strong>und</strong> schwer? Im wesentlichen braucht man bei e<strong>in</strong>em<br />

kryptographischen System 2 Komplexitätsklassen: Die D<strong>in</strong>ge, die die Benutzer tun müssen,<br />

müssen leicht gehen; h<strong>in</strong>gegen muß das Brechen schwer se<strong>in</strong>. Formal faßt man dies meist durch<br />

den Unterschied zwischen polynomial <strong>und</strong> nicht polynomial, also:<br />

3.1.3.5 Überblick über im folgenden vorgestellte kryptographische<br />

Systeme<br />

Zu den durchgestrichenen Feldern <strong>in</strong> Bild 3-12: Mit den Spezifikationen aus den Bildern 3-4 bzw. 3-7<br />

gibt es solche Systeme nicht, wie <strong>in</strong> Punkt 1) oben begründet wurde. (Allerd<strong>in</strong>gs gibt es mittlerweile<br />

e<strong>in</strong> System, das fast die Eigenschaften von digitalen Signaturen hat <strong>und</strong> <strong>in</strong>formationstheoretisch<br />

sicher ist. Von der Effizienz her ist es aber derzeit wohl nicht praktikabel. Vgl. §3.9.3 <strong>und</strong><br />

[ChRo_91].)<br />

Das Feld 3 ist seit 1998 nicht mehr vollständig leer. Bis dah<strong>in</strong> war gegen aktive Angriffe ke<strong>in</strong><br />

praktikables <strong>und</strong> gegen adaptive aktive Angriffe überhaupt ke<strong>in</strong> System bekannt ist [BlFM_88,<br />

Schlüsselgenerierung, Ver-/Entschlüsseln: leicht = polynomial <strong>in</strong> l<br />

Brechen: schwer = nicht polynomial <strong>in</strong> l ≈ exponentiell <strong>in</strong> l<br />

Warum gerade diese Trennung? (Die Punkte b <strong>und</strong> c gelten ganz allgeme<strong>in</strong> für die<br />

Komplexitätstheorie.)<br />

a) Schwerer als exponentiell geht nicht, siehe 1).<br />

b) Abgeschlossen: E<strong>in</strong>setzen von Polynomen <strong>in</strong> Polynome ergibt Polynome, d.h. vernünftige<br />

Komb<strong>in</strong>ationen polynomialer Algorithmen s<strong>in</strong>d wieder polynomial (ohne daß man etwas<br />

Genaues rechnen muß).

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!