Claus Schönleber

Einführung in Asymmetrische Verschlüsselung

Auszüge aus dem Buch "Verschlüsselungsverfahren für PC-Daten"
erschienen im Franzis-Verlag

(c) 1995-1997


Siehe auch Texte zur IN-CA.


Asymmetrische Verfahren, Public Key Systeme

Die Grundelemente asymmetrischer Verfahren sind enthalten in den U.S. Patenten 4,200,770 (M.Hellman, W. Diffie, R. Merkle) vom 29.4.1980 und in 4,218,582 (M. Hellman, R. Merkle) vom19.8.1980

Die exklusiven Lizenzrechte beider Patente liegen bei Public Key Partners (PKP), Sunnyvale, Californien, die ebenfalls das RSA-Patent besitzen. RSA selbst ist unter U.S. Patent 4,405,829 vom 20.9.1983 eingetragen. Das Patent läuft nach 17 Jahren aus, also im Jahre 2000.

Mit dem Aufkommen gewaltiger Mengen von Datennetzen und den daraus resultierenden neuen Kommunikationsformen kristallisierte sich ein neuer Bedarf für Verschlüsselungsverfahren heraus. Es ist notwendig geworden, schnell, sicher und vertraulich mit Partnern Informationen auszutauschen, die man vorher nicht kennt und wo es gleichzeitig unmöglich ist, vorher auf gesichertem Wege geheime Schlüssel auszutauschen. Vor allem die Wirtschaft, die nicht mehr nur mit regionalen oder nationalen Geschäftspartnern und Kunden zu tun bekam, hat immer stärker den Bedarf an Verfahren, die die gesicherte Übermittlung von geheimen Schlüsseln und das Problem der anerkennbaren Unterschrift unter Dokumenten bewältigen kann.

In einem aufsehenerregenden Papier berichteten Diffie und Hellman im Jahre 1976 von einer theoretischen Möglichkeit, alle Wünsche auf einmal zu befriedigen:

Es dauerte danach gerade mal etwas mehr als ein Jahr, als schon ein Vorschlag für eine praktische Verwirklichung veröffentlicht wurde. Das Verfahren RSA war geboren. Den eigentlichen Grundstein hatte allerdings ein schweizer Mathematiker gelegt - Leonhard Euler (1707-1783). Das Verfahren lag also schon seit über 200 Jahren in der Luft, sozusagen. Mathematisch interessierte Leser mögen den entscheidenden "Satz von Euler" ausführlich in einschlägigen Büchern über Zahlentheorie nachlesen.

Mit der theoretischen Ausarbeitung von Diffie und Hellmann und der praktischen Realisation von Rivest, Shamir und Adleman gab es plötzlich die Möglichkeit, auf die alle gewartet hatten. Zur selben Zeit wurde die Rechenleistung auch für kleine Firmen und kurz darauf auch für Privatleute durch die Einführung von PCs erschwinglich. RSA ist

Theoretische Vorarbeit

Im Gegensatz zu symmetrischen Verfahren, bei denen beide kommunizierenden Partner denselben Schlüssel besitzen, müssen bei asymmetrischen Verfahren andere Zugänge gewählt werden. Denn hier soll der Austausch von Nachrichten drei sich eigentlich widersprechenden Bedingungen unterworfen sein:

Zunächst benötigt jeder eine Gruppe von Schlüsseln, die individuell sind, also von der Person abhängen. Dabei muß ein Schlüssel öffentlich bekannt sein. Man könnte das in gewisser Weise mit einer Telefonnummer vergleichen. Ein weiterer Teil der Schlüssel muß selbstverständlich geheim sein. Man benutzt also ein Schlüsselpaar, von dem ein Teil öffentlich, der andere geheim und nur dem Besitzer bekannt ist.

Der öffentliche Teil wird E (encrypt, verschlüsseln) genannt, der private Teil wird mit D (decrypt, entschlüsseln) bezeichnet.

Dabei muß unter allen Umständen die Regel eingehalten werden, daß D aus E nicht (oder in der Praxis nur äußerst aufwendig) berechenbar ist. Das ist eine selbstverständliche Forderung, denn wenn das nicht gilt, ist das ganze Verfahren sinnlos.

Desweiteren muß gelten, daß E und D zueinander invers sind. Das bedeutet, daß D genau das Umgekehrte bewirkt wie E. Auf Anhieb klingt das fast unmöglich, denn im alltäglichen Umgang mit Zahlen kennt man zwar zueinander inverse Zahlen (z.B. 5 und -5 bezüglich der Addition), aber in solchen Fällen kann man den einen aus dem anderen Teil leicht berechnen.

Um zu funktionieren, müssen anfangs alle öffentlichen Schlüssel an einem allgemein zugänglichen Ort aufbewahrt werden. Wir werden später sehen, daß dieser Punkt in der Praxis noch Schwierigkeiten mit sich bringt, denn die öffentlichen Schlüssel sind zwar öffentlich, aber sie dürfen nicht von Unbefugten manipulierbar sein.

Verschlüsseln

Möchte Alice eine Nachricht M verschlüsselt an Bob schicken, so muß sie zunächst den öffentlichen Schlüssel von Bob EBob nachschlagen. Danach verschlüsselt sie die Nachricht M mit Hilfe von Bobs öffentlichem Schlüssel, als Resultat erhält sie C:

 

C = EBob (M)

 

Die verschlüsselte Nachricht C schickt sie nun über einen unsicheren Kanal an Bob.

Bob empfängt die Nachricht C und entschlüsselt sie nun, indem er seinen geheimen Schlüssel DBob anwendet. Er erhält damit die entschlüsselte Nachricht M:

 

M = DBob (C)

 

Alice kann beruhigt einen unsicheren Kanal benutzen, denn keiner außer Bob kann die Nachricht entschlüsseln. Nur Bob kennt seinen geheimen Schlüssel und nur mit diesem läßt sich die Nachricht entschlüsseln. Dies ist eine weitere wichtige Forderung an das System: Mit dem öffentlichen Schlüssel E und der übermittelten Nachricht C dürfen Unbefugte keine Information über die übermittelte Nachricht oder den geheimen Schlüssel D gewinnen!

Unterschreiben

Beim Unterschreiben geht es um andere Dinge. Das Dokument muß nicht unbedingt geheim sein. Man kann es zusätzlich verschlüsseln, aber hier kommt es darauf an, daß der Absender oder Autor eines Schriftstückes eindeutig bestimmt werden kann.

Will Alice also eine von ihr unterschriebene Nachricht an Bob senden, so "unterschreibt" sie die Nachricht M mit ihrem eigenen, geheimen Schlüssel DAlice:

 

S = DAlice (M)

 

Dann schickt sie die Nachricht S an Bob. Bob seinerseits muß nun kontrollieren, ob Alice der Absender war. Er schlägt also im öffentlich zugänglichen Schlüsselverzeichnis den öffentlichen Schlüssel von Alice, EAlice, nach und ermittelt so wieder die Nachricht M:

 

M = EAlice (S)

 

Zwar sieht diese Gleichung aus wie die für das Verschlüsseln, mit dem Unterschied, daß E und D vertauscht sind. Aber man beachte, daß diesmal nicht nur Bob, sondern jeder, dem die Nachricht in die Hände fällt, überprüfen kann, ob Alice die Nachricht unterschrieben hat. Das ist in diesem Falle aber auch beabsichtigt. Das Überprüfen der Unterschrift darf nicht nur einer Person möglich sein.

Möchte man die unterschriebene Nachricht außerdem noch verschlüsseln, so wendet man nach dem Ermitteln von S einfach noch den Teil "Verschlüsseln" an.

Alice unterschreibt und verschlüsselt:

1. S = DAlice (M) (Alice unterschreibt M)

2. C = EBob (S) (Alice verschlüsselt das unterschriebene Dokument S)

3. Alice schickt C an Bob

Bob entschlüsselt und überprüft:

1. Bob empfängt C von Alice.

2. S = EAlice (C) (Bob entschlüsselt die verschlüsselte Botschaft C)

3. M = DBob (S) (Bob prüft die Unterschrift von Alice)

Wie geht das Überprüfen der Unterschrift vor sich? Es ist einfacher als man denkt und trotzdem ist es nicht selbstverständlich.

Der Vorgang des Unterschreiben verschlüsselt in gewissem Sinne das Dokument M, es wird eine unlesbare Folge von Zeichen. Allerdings kann jeder Empfänger, unbefugt oder nicht, das Dokument wieder "entschlüsseln", denn jeder kann sich ja den öffentlichen Schlüssel von Alice besorgen, der dafür notwendig ist.

Wenn das geschieht, hat man wieder den Klartext, und das bemerkt man daran, daß etwas Sinnvolles zum Vorschein kommt, also ein lesbarer Text, eine Zahlenkolonne, die dem Empfänger etwas sagt oder auch eine Grafik, eine Tonaufzeichnung, etc. Nun ist da natürlich der Begriff des "Sinnvollen" recht problematisch. Der Autor eines solchen Verfahrens muß darauf achten, daß es nicht möglich oder unwahrscheinlich ist, daß zwei verschiedene Nachrichten nicht dieselbe "Unterschrift" S ergeben, oder, daß man nicht aus einer unterschriebenen Nachricht S mit zwei verschiedenen (öffentlichen) Schlüsseln zwei verschiedene, gleichermaßen sinnvolle Text erhalten kann oder gar denselben. Diese Probleme sind ganz realistischer Natur sie sind nur schwer lösbar.

Kombinationen von Verfahren, Schlüsselaustausch

Obwohl eine der Forderungen an asymmetrische Verfahren ist, daß sie in der normalen Anwendung leicht zu berechnen sein sollen, stellt es sich im Vergleich zu den symmetrischen Verfahren heraus, daß eine asymmetrische Anwendung wesentlich langsamer ist als eine symmetrische.

Da aber auch in der EDV der Grundsatz "Zeit ist Geld" gilt, sucht man natürlich nach Methoden, die die Vorteile beider Verfahrensgruppen in sich vereinigen. Die Antwort ist dabei ganz einfach: Man verschlüsselt die eigentliche Nachricht mit Hilfe eines schnellen symmetrischen Verfahrens (z.B. Triple-DES oder IDEA); hier steckt ja der Löwenanteil an Daten. Und wie bekommt der Empfänger den verwendeten symmetrischen Sitzungsschlüssel? Nun, der wird mit den beschriebenen asymmetrischen Verfahren verschlüsselt und an den Empfänger geschickt. Der muß zunächst den empfangenen Sitzungsschlüssel entschlüsseln, dann kann er diesen verwenden, um die eigentliche Nachricht zu dechiffrieren.

Dies ist nur eine Methode, Schlüssel sicher auszutauschen. Von den Verfahren, die es heute gibt, soll eines kurz angesprochen werden, das Verfahren "Diffie-Hellmann-Key-Exchange" (Schlüsselaustausch, 1976).

Alice und Bob einigen sich anfangs auf eine Zahl p, die Primzahl sein muß und nicht zu klein sein sollte. Desweiteren auf eine Zahl g, die kleiner sein muß als p (g < p). Wenn Alice an Bob einen Sitzungsschlüssel über einen unsicheren Kanal senden möchte, dann wird nach folgendem Muster vorgegangen:

1. Alice wählt eine natürliche Zahl x.

2. Alice berechnet a = gx mod p

3. Bob wählt ebenfalls eine natürliche Zahl y.

4. Bob berechnet b = gy mod p.

Die Zahl gxy ist der gemeinsame Schlüssel.

5. Beide tauschen nur Ihre Ergebnisse aus; Alice sendet also an Bob die Zahl a, Bob sendet an Alice die Zahl b.

6. Alice kennt x und b, Bob kennt y und a. Alice berechnet bx, Bob berechnet ay.

Nun kennen Alice und Bob beide den gemeinsamen Sitzungsschlüssel. Eve, die Laucherin, kennt nur a, b und g. Sie muß, um den Schlüssel zu berechnen, einen diskreten Logarithmus ausrechnen. Das aber wird als mindestens ebenso schwierig eingeschätzt wie eine Primfaktorenzerlegung (siehe nächster Abschnitt), und damit ist eine Berechnung praktisch nicht möglich.

Es gibt inzwischen einige Verbesserungen an diesem Verfahren, die unter anderem das Problem betreffen, daß die Sicherheit des Verfahrens auf Annahmen beruht, die nicht bewiesen werden können.

Daneben gibt es weitere, neuere Verfahren, die das Problem in anderer Weise lösen.

Sicherheit von asymmetrischen Verfahren

Nachdem wir nun schon ein paar Grundprinzipien kennegelernt haben, stellt sich natürlich die Frage, wie werden D und E relaisiert und wie sicher sind diese Verfahren damit?

Um ein public-key-Verfahren sicher zu machen, muß die "legale" Benutzung relativ einfach und leicht durchzuführen sein. Der Besitzer beider Schlüsselteile, des öffentlichen und des geheimen, kann seine Absicht, die Nachricht zu entschlüsseln oder zu prüfen, schnell durchführen.

Dem potentiellen Angreifer stehen aber auch nicht wenige Informationen zur Verfügung, der öffentliche Schlüssel und der Geheimtext bzw. das unterschriebene Dokument.

Die "illegale" Berechnung des fehlenden Teils muß deswegen außerordentlich aufwendig sein, das heißt, sie darf zwar theoretisch möglich, aber sie muß wenigstens praktisch unmöglich sein.

Um das zu erreichen, werden sogenannte Falltürfunktionen benutzt. In der Theorie sind das mathematische Funktionen, die sich sehr einfach anwenden lassen; ihre Umkehrung jedoch läßt sich nur mit zu großem Aufwand berechnen.

Das Problem dabei ist, daß es äußerst schwierig zu beweisen ist, ob eine solche Falltürfunktion vorliegt.

Für solche Anwendungen benutzt man in der Regel zwei mathematische Operationen, die diesen Bedingungen aller Kentnis nach gehorchen:

Solche System liefern also grundsätzlich schon eine Methode mit, wie man sie knacken kann. Es ist also, im Gegensatz zu symmetrischen Verfahren, nicht die Frage, ob man das System knacken kann, sondern ob es eine wirksamere Methode als die schon bekannte gibt, wie man an die Lösung kommt.

Das Problem an der Sache ist, daß man nichts darüber weiß. Man weiß nicht, ob es nicht vielleicht doch schnellere Methoden gibt, die Umkehrung zu berechnen; man weiß nicht, ob es nicht trickreiche andere Zugänge gibt, mit dem man das Problem der Umkehrung umgehen kann.

Man gründet die Sicherheit solcher Verfahren also auf folgende Punkte:

Mit anderen Worten: man kann die Sicherheit des Verfahrens nicht beweisen, ja noch schlimmer, man macht die Sicherheit des Verfahrens von der momentanen Unfähigkeit abhängig, eine flotte Lösung zu finden.

Schlüsselmanagement

Das Problem vor allem bei asymmetrischen Verfahren ist zuverlässige Verteilung und Verwaltung der Schlüssel.

Schlüsselverwaltung (key management) besteht aus Schlüsselverteilung (key distribution), Schlüsselbenutzung und Authentikation der Schlüssel.

Es ist offensichtlich, daß die ganze Sicherheit der Schlüsselverwaltung im Endeffekt auf Vertrauen basiert. Auf Vertrauen gegenüber den Verfahren, auf Vertrauen gegenüber den Implementationen, auf Vertrauen gegenüber den benutzten Kanälen und - natürlich - auf Vertrauen gegenüber allen Beteiligten.

Wenn Alice and Bob eine geheime Nachricht mit Hilfe eines public-key Systems verschickt, so ist der einfachste Angriff, den öffentlichen Schlüssel von Bob abzufangen, bevor Alice ihn erhält. Wenn Alice Bobs öffentlichen Schlüssel nicht vorher schon kennt, muß er über irgendeinen Kanal erforscht werden. Das kann beispielsweise über das Datennetz per e-mail geschehen. Wenn nun eine bösartige Systemverwalterin Eve die Antwort, die Bobs Schlüssel enthält, vor der Weiterleitung an Alice so verändert, daß sie stattdessen Eves Schlüssel enthält, kann Alice nichts davon merken.

Sie wird die Nachricht irrtümlich mit Eves öffentlichem Schlüssel verschlüsseln und an Bob senden. Eve fängt nun wiederum die Nachricht ab, bevor sie zu Bob gelangt, dechiffriert sie mit ihrem geheimen Schlüssel und nimmt davon Kenntnis. Die entschlüsselte Nachricht wird nun mit Bobs Schlüssel, den Eve ja kennt, verschlüsselt und an Bob weitergeschickt. Bob kann davon nichts merken. Auch eine merkliche zeitliche Verzögerung tritt nicht ein, denn das kann alles automatisch geschehen.

Wenn es sogar gelingt, den gefälschten öffentlichen Schlüssel von Bob mit Bobs Benutzerkennung zu verknüpfen (beispielsweise in einer Schlüsseldatenbank), so kann Eve von nun an Unsinn nach Lust und Laune treiben.

Um so etwas zu verhindern muß man dafür sorgen, daß mit öffentlichen Schlüsseln kein Mißbrauch getrieben werden kann. Das ist aber leichter gesagt als getan. Die sicherste Methode ist natürlich, den öffentlichen Schlüssel direkt auszutauschen. Aber dann wäre einer der Hauptvorteile asymmetrischer Verfahren, spontane Übermittlung geheimer Nachrichten ohne vorherige Absprache, wieder neutralisiert, man könnte gleich ein symmetrisches Verfahren benutzen.

Deswegen gibt es noch ein paar andere Möglichkeiten, die fast so gut sind wie ein direkter, persönlicher Austausch der Schlüssel.

Wenn beide, Alice und Bob, einer dritten Person, Chris, wechselseitig vertrauen, so könnte der Austausch mit Chris´ Hilfe stattfinden. Chris könnte die ihm vorliegende (korrekte) Kopie von Alice Schlüssel mit seinem geheimen Schlüssel unterschreiben und sie so zertifiziert an Bob weiterreichen. Chris steht dann gerade für die Intagrität des Schlüssels von Alice. Dasselbe kann umgekehrt geschehen; Chris kann eine zertifizierte Kopie von Bobs öffentlichem Schlüssel an Alice weiterreichen. Natürlich benötigt man, um die Zertifizierung zu prüfen eine korrekte Kopie von Chris´ öffentlichem Schlüssel. Das klingt auf den ersten Blick genauso wie das erste Problem; aber Chris kann, im Gegensatz zu den beiden eigentlichen Kommunikationspartnern, leichter erreichbar sein.

Die zertifizierte Version beider Schlüssel kann auch nun in einer öffentlichen Datenbank stehen, ohne daß die Möglichkeit besteht, an dem Schlüssel etwas zu ändern (denn dazu bräuchte man Chris´ geheimen Schlüssel).

So kann eine Person, der viele Benutzer vertrauen, eine ganze Reihe von Schlüsseln zertifizieren. Man nennt solche Stellen "Certifying Authority" (CA). Der öffentliche Schlüssel dieser Einrichtung muß in seiner authentischen Form weitverbreitet sein, damit man das Zertifikat überprüfen kann.

Die Struktur solcher CAs kann durchaus variieren; von einem einzigen, zentralen Server, über eine Hierarchie von Servern bis hin zu verteilten, unabhängigen Servern, bei denen man parallel anfragen kann.

In großen, hierarchischen Strukturen (Behörden, Firmen, ...) ist eine zentraler Einrichtung durchaus angebracht. Allerdings muß man sich darüber im Klaren sein, daß der zentrale Server auch ein zentrales Ziel für Angriffe ist. Angefangen bei der baulichen Absicherung und weiteren, physikalischen Sicherungseinrichtungen (Alarmanlage, Notstromaggregat, Hardwaresicherungen, etc.) über Softwareschutzmechanismen bis hin zur Mitarbeiterüberwachung ist ein riesiger Aufwand notwendig, um den Kunden das Vertrauen zu versichern, das sie in einen solchen zentralen Instanz erwarten.

Solche zentralen key server können dann auch gleich als Zertifizierungsinstanz und Trust Center arbeiten, das heißt, sie generieren, verteilen und bewahren die Schlüssel nicht nur auf, sie zertifizieren als vertrauenswürdige Stelle gleich alle Schlüssel.

Man kann sich aber denken, daß hier massive Probleme auftreten können, wenn der Trust Center geknackt wird, von außen oder von innen. Dann sind sofort alle Schlüssel wertlos.

Eine Methode, die deswegen in freien Netzen dem zentralistischen Modell eines Trust Centers vorgezogen wird, ist das dezentrale Modell vieler kleiner unabhängiger CAs. Jeder zertifiziert nur die Schlüssel in seiner unmittelbaren, von ihm kontrollierbaren Umgebung, beispielsweise die Schlüssel der lokalen Freunde oder Geschäftspartner. Dieser eher deinstitutionalisierte Zugang ist unter der Bezeichnung "web of trust" bekannt. Dieses Modell spiegelt eher die kommunikativen und sozialen Zusammenhänge wieder und jeder kann frei wählen, wem er vertraut und wem nicht.

Wie man spätestens hier merkt, ist dieses Thema die eine, echte Schwachstelle, die das sonst so elegante System mit einem gehörigen Schuß Wermuth versieht. Eine Menge Forschungsarbeit wird zur Lösung des Problems investiert, und viel Aufwand wird getrieben, um die Hürde in der Praxis überwindbar zu machen.

Als Merkregel sollte man beachten:

Ein öffentlicher Schlüssel sollte dann und nur dann verwendet werden, wenn man sich absolut sicher ist, daß er nicht gefälscht wurde! Das geht entweder durch direkte persönliche Übergabe oder durch Zertifizierung mittels einer vertrauenswürdigen Person.



Niemals, niemals, niemals sollte man einen nicht zertifizierten Schlüssel benutzen, den man über einen unsicheren Kanal erhalten hat (e-mail, Mailbox download, ...); auch wenn man in großer Versuchung ist, genau das aus Bequemlichkeit zu tun!


Wenn man aufgefordert wird, selbst einen Schlüssel zu zertifizieren, gilt ebenfalls höchste Vorsicht! Man muß sich unbedingt und absolut davon überzeugen, daß der Schlüssel, den man zertifizieren wird, auch wirklich der Person gehört, der er zugeschrieben wird. Zertifiziert man leichtsinnigerweise einen Schlüssel, der gefälscht war, so wird man auf unabsehbare Zeit andere Nutzer im Glauben wiegen, daß der Schlüssel authentisch ist (da er ja zertifiziert ist). Man kann so riesige Bereiche der Kommunikation dadurch verseuchen, daß ein zertifizierter, aber gefälschter Schlüssel im Umlauf ist. Die Verantwortung dafür trägt selbstverständlich die Person, deren digitale Unterschrift das Zertifikat aufweist. Man kann sich selbst so eine Menge Probleme schaffen. Man sollte selbst nur die Schlüssel zertifizieren, die man direkt vom rechtmäßigen Inhaber erhalten hat. Die Verantwortung über ein Zertifikat ist weitaus größer als die, selbst einen authentischen Schlüssel zu benutzen. Ein Zertifikat wirkt stets auch auf die Privatsphäre anderer Personen.

Ein Zertifikat sagt darüberhinaus nichts über den Inhaber aus; nur darüber, daß der Schlüssel der entsprechenden Person gehört. Was die Person, der man einen Schlüssel zertifiziert hat, nun mit dem Schlüssel anfängt, das ist natürlich nicht mehr in der Verantwortung des Zertifizierers. Ein Zertifikat besiegelt die Glaubwürdigkeit des Schlüssels, nicht die des Besitzers.

Darüberhinaus ist Vertrauen nicht transitiv. Wenn Alice Bob Vertrauen schenkt und Bob dem Weihnachtsmann, dann bedeutet das nicht, daß Alice dem Weihnachtsmann Vertrauen schenken kann oder wird. Es ist deswegen von Vorteil, sich seinen Schlüssel von mehreren Personen zertifizieren zu lassen, damit man eine Auswahl von Zertifikaten anbieten kann.

Mehr praktische Hinweise finden sich z.B. in der Anleitung zum Programm PGP.

Und wenn sie bisher nie Anleitungen gelesen haben, dieses eine Mal sollte Sie das tun, um ihrer und der anderen Sicherheit Willen! Lesen Sie die Anleitung für PGP gründlich und sorgen Sie dafür, daß Sie alles verstanden haben. Wenn Sie nur einen Fehler machen, können schlimmere Dinge passieren als durch den Verlust einer Kreditkarte (und dadurch kann man schon Haus und Hof verlieren).


Literatur:

[1] Kahn: The Codebreakers; New York: Macmillan Publishing Co., 1967
[2] Duden Informatik; Mannheim, Wien, Zürich: Dudenverlag Bibliographisches Institut, 1989
[3] Schönleber: Verschlüsselungsverfahren für PC-Daten; Franzis: Poing, 1995
[4] Tanenbaum: Computer Networks; Englewood Cliffs: Prentice Hall, 1987
[5] Anschütz: Kybernetik; Würzburg: Vogel Verlag, 1970
[6] Schönleber, Keck: Internet Handbuch; Poing: Franzis'-Verlag, 1995/96.
[7] Spektrum der Wissenschaft, Januar 1989, S.6-10
[8] Spektrum der Wissenschaft, Mai 1993, S.19-24
[9] Niklaus Wirth: Algorithmen und Datenstrukturen; Stuttgart: Teubner, 1983
[10] Ron Rivest (Network Working Group): Request for Comments RFC 1321 - The MD5 Message-Digest Algorithm; MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992.
[11] Cryptography FAQ (Frequently Asked Questions); Text aus dem Usenet/Internet; newsgroups sci.crypt, news.answers.
[12] c't 9/85, p.74.
[13] Diffie, Hellmann: New directions in cryptography; IEEE Trans. Inform. Theory IT-22, 6(Nov. 1976), 644-654
[14] Rivest, Shamir, Adleman: A Method for Obtaining Digital Signatures and Public-Key Cryptosystems; Communications of the ACM, Feb. 1978, Vol. 21, No. 2, 120-126
[15] Lenstra: Factoring integers with elliptic curves; Annals of Mathematics, 126(1987), 649-673)
[16] LaMacchia, Odlyzko: Compuitation of Discrete Logarithms in Prime Fields; Designs, Codes and Cryptography, 1, 47-62(1991)
[17] Ronald Rivest; RSA-129-Challenge; Scientific American; 8/77
[18] Schneier; Applied Cryptography; John Wiley & Sons; 1994
[19] Hellmann; Die Mathematik neuer Verschlüsselungssysteme; Spektrum der Wissenschaft, 10/79
[20] Beutelspacher: Kryptologie; Braunschweig, Wiesbaden: Vieweg, 1993
[21] Charles Vanden Eynden: Elementary Number Theory; New York: Random House, 1987
[22] Müller, A.Pfitzmann, Stierand: Rechnergestützte Steganographie - Wie sie funnktioniert und warum folglich jede Reglementierung von Verschlüsselung unsinnig ist; Datenschutz und Datensicherung 18/6 (1994) 318-326
[23] B.Pfitzmann, M.Waidner, A.Pfitzmann: Rechtssicherheit trotz Anonymität in offenen digitalen Systemen; Kiel: Verlag C.Schönleber, 1. Kieler Netztage '93 - Kongreßband (1993) 55-93
[24] Molva (EUROCOM Inst.), Tsudik (IBM Zürich): Authentication Method with impersonal Token Cards; Proceedings of 1993 IEEE Symposium on Research in Security and Privacy.
[25] Wayner: Using Content-Addressable Search Engines To Encrypt and Break DES; Paper, Computer Science Departement Cornell University, Ithaca NY 14853 [D]
[26] Ruland: Informationssicherheit in Datennetzen; Bergheim: Datacom, 1993
[27] Berth: Sichere offene Datennetze; Spektrum der Wissenschaft, 5/1995, 46-55
[28] Leibrich: Verschlüsselung und Kriminalität - Eine Bedrohung


[ Home | Arbeiten ]

freitag@toppoint.de