In die Datei randseed.bin werden bei jedem Aufruf des Zufallszahlengenerators neue Daten geschrieben, unter Einbeziehung der aktuellen Uhrzeit und anderer echter Zufallsdaten. Im Zufallszahlengenerator wird der konventionelle Verschlüsselungsalgorithmus IDEA verwendet.

Die Datei randseed.bin sollte wenigstens ein kleines bißchen vor Mitlesen geschützt sein, um das Risiko klein zu halten, daß ein Angreifer die nächsten Schlüssel, die PGP generieren wird, oder die letzten Schlüssel, die PGP generiert hat, berechnet. Dieser Angreifer hätte Schwerstarbeit zu erledigen, weil PGP die Datei randseed.bin vor und nach jeder Benutzung kryptographisch "in die Mangel nimmt". Trotzdem ist es keine unangebrachte Vorsicht, darauf zu achten, daß die Datei nicht in die falschen Hände gerät.

Leser, denen diese algorithmisch abgeleiteten Zufallszahlen unheimlich sind, sollten nicht vergessen, daß sie der Sicherheit desselben konventionellen Verschlüsselungsalgorithmus vertrauen, um eine Nachricht zu verschlüsseln. Wenn der Algorithmus für die Verschlüsselung sicher genug ist, sollte er hinreichend zuverlässig sein, um Zufallszahlen zu erzeugen, die den konventionellen Schlüssel bilden. Zu beachten ist noch, daß PGP zur Erzeugung eines Paares von öffentlichem und geheimem Schlüssel, die über längere Zeit sicher sein sollen, echte Zufallszahlen verwendet, die im Wesentlichen aus den Zeitabständen von Tastatureingaben abgeleitet werden.

Die Erzeugung von Pseudozufallszahlen, also von Zahlen, die zwar "zufällig aussehen", die aber aus einem Algorithmus abgeleitet werden, ist eine schwierige Aufgabe. Wegen der "guten Zufallsqualität" wird auch bei Anwendungen, die nichts mit Verschlüsselung zu tun haben, wie Statistik oder numerische Mathematik, gerne ein Verschlüsselungsalgorithmus verwendet, um Zufallszahlen zu erzeugen. Die Probleme bei Verschlüsselung und bei der Erzeugung von Zufallszahlen sind ähnlich: In beiden Fällen geht es darum, Bitfolgen zu erzeugen, die möglichst wenig Systematik zeigen. Bei der Verschlüsselung sind diese Bitfolgen der verschlüsselte Text, bei der Erzeugung von Zufallszahlen sind die Bitfolgen eben die Zufallszahlen. Leser, denen die Verwendung der Datei randseed.bin trotz dieser Argumente unheimlich bleibt, können sie immer noch vor jedem Start von PGP einfach löschen. Allerdings müssen sie dann für die Verschlüsselung eines Klartextes jedesmal ungefähr 90 Tastendrücke für die Erzeugung einer echten Zufallszahl ausführen.

Der "Federal Data Encryption Standard" (DES) ist ein guter Algorithmus für die meisten kommerziellen Anwendungen. Allerdings vertraut die US-Regierung nicht auf DES, um ihre eigenen geheimen Daten zu schützen. Vielleicht liegt der Grund darin, daß der Schlüssel bei DES nur 56 Bit lang ist, kurz genug für einen Angriff "mit brutaler Gewalt", bei dem eine spezielle Maschine verwendet wird, die aus einer Vielzahl von DES-Verschlüsselungschips besteht, die einfach alle 256 möglichen Schlüssel "ausprobiert". Auch hatten Biham und Shamir kürzlich einigen Erfolg beim Angriff auf eine volle 16-Runden-DES-Verschlüsselung.(*) Auf der "Crypto '93 conference" legte Michael Wiener eine Studie vor, wie DES mit einer speziell entwickelten Maschine zu knacken sei. Er hat einen speziellen Chip entwickelt, der pro Sekunde 50 Millionen Schlüssel durchprobiert, bis er den richtigen findet. Diese Chips könnten für knapp elf Dollar das Stück gebaut werden, eine Maschine zum Preis von einer Million Dollar könnte sämtliche möglichen DES-Schlüssel innerhalb von sieben Stunden durchprobieren. Das ergäbe eine durchschnittliche Suchdauer von 3,5 Stunden.

Für die kryptographisch Interessierten: IDEA verwendet 64 Bit lange Blöcke für Klartext und verschlüsselten Text mit 128 Bit langen Schlüsseln. Der Algorithmus basiert auf dem Konzept der Mischung von Operationen verschiedener algebraischer Gruppen. Eine Software-Implementierung von IDEA ist wesentlich schneller als eine DES-Software-Implementierung. Ähnlich wie DES kann IDEA für Cipher Feedback (CFB, Rückführung der verschlüsselten Textes) und für Cipher Block Chaining (CBC, Verkettung von Blöcken verschlüsselten Textes) verwendet werden. PGP verwendet IDEA mit 64-Bit CFB. Hierzu siehe auch den Abschnitt IDEA sowie die Informationen der Firma Ascom Systec AG, die die Rechte an IDEA innehat hier.

Die IPES/IDEA-Verschlüsselung wurde an der ETH Zürich von James L. Massey und Xuejia Lai entwickelt und 1990 veröffentlicht. IDEA ist keine Entwicklung aus dem Bastelkeller. Seine Entwickler haben unter Kryptologen einen hervorragenden Ruf. In ihren ersten Veröffentlichungen nannten sie den Algorithmus IPES (Improved Proposed Encryption Standard, Vorschlag für einen verbesserten Verschlüsselungsstandard), später änderten sie den Namen in IDEA (International Data Encryption Algorithm, Internationaler Standard für Datenverschlüsselung). Bis heute hat IDEA kryptoanalytischen Angriffen wesentlich besser standgehalten als andere Verfahren wie FEAL, REDOC-II, LOKI, Snefru und Khafre. Es gibt erste Anhaltspunkte dafür, daß IDEA dem sehr erfolgreichen differentiellen kryptoanalytischen Angriff von Biham und Shamir wesentlich besser standhält als DES.(*) Biham und Shamir untersuchten IDEA erfolglos auf Schwachstellen. Akademische Arbeitsgruppen von Kryptoanalytikern aus Belgien, England und Deutschland suchen Angriffsmöglichkeiten bei IDEA, ebenso militärische Geheimdienste mehrerer europäischer Länder. Je mehr und je länger dieser neue Algorithmus Angriffsversuche aus den gefürchtetsten Arbeitsgruppen der kryptoanalytischen Welt auf sich zieht, desto mehr steigt das Vertrauen in ihn.

Die ausschließliche Verwendung von RSA mit langen Schlüsseln ist wegen der langen Rechenzeit für die Ver- und Entschlüsselung großer Datenmengen nicht wirklich brauchbar. Das macht absolut niemand im wirklichen Leben. Trotzdem liegt die Frage nahe, ob die Kombination einer Verschlüsselung mit öffentlichen Schlüsseln und einer zweiten, konventionell arbeitenden Verschlüsselung die Gesamtsicherheit herabsetzt, und das nur, um das Programm schneller zu machen. Schließlich ist eine Kette nur so stark wie ihr schwächstes Glied. Viele Leute, die wenig Erfahrung mit Kryptographie haben, sind der Meinung, daß RSA vom Prinzip her sicherer sei als eine konventionelle Verschlüsselung. Das stimmt nicht. RSA kann durch leicht zu knackende, "weiche" Schlüssel leicht angreifbar werden, andererseits können konventionelle Verschlüsselungen bei Wahl eines guten Algorithmus sehr sicher sein. In den meisten Fällen ist es schwierig, genau zu sagen, wie gut eine konventionelle Verschlüsselung ist, ohne sie wirklich zu knacken. Ein guter konventioneller Algorithmus könnte durchaus schwerer zu knacken sein als ein RSA-Schlüssel nach militärischem Standard. Der Reiz einer Verschlüsselung mit öffentlichen Schlüsseln besteht nicht darin, daß sie aus sich heraus sicherer als eine konventionelle Verschlüsselung ist - ihr Reiz besteht in der wesentlich bequemeren und vielseitigeren Handhabung der Schlüssel.

Leute, die beruflich mit der Erforschung von Faktorisierungsalgorithmen zu tun haben, sagen, daß ein Durchprobieren der 2128 möglichen Schlüssel für IDEA vom Rechenaufwand her der Faktorisierung eines RSA-Schlüssels mit 3100 Bit entspreche. Das ist deutlich mehr als die 1024 Bit, die die in PGP 2.6 verwendeten RSAREF-Routinen zulassen. Wenn wir annehmen, daß IDEA keine besonderen Schwachstellen enthält, ist der Schwachpunkt, an dem ein kryptoanalytischer Angriff ansetzen würde, RSA und nicht IDEA.

Außerdem kann es bei der Verwendung eines reinen RSA-Algorithmus zusätzliche Konstellationen geben, die Ansatzpunkte für einen Angriff ergeben.

Datenkomprimierung

Bei Bedarf läßt sich auch PKZIP oder ein anderes Datenkomprimierungsprogramm verwenden, um den Klartext vor der Verschlüsselung zu komprimieren. PKZIP ist ein weit verbreitetes und effizient arbeitendes Kompressionsprogramm von PKWare Inc. für MS-DOS, das als Shareware vertrieben wird. Oder man kann ZIP benutzen, ein PKZIP-kompatibles Freeware-Programm für Unix und andere Betriebssysteme, zu erhalten bei Jean-Loup Gailly. Die Verwendung von PKZIP oder ZIP hat unter bestimmten Umständen Vorteile, weil diese Programme im Gegensatz zu PGP in der Lage sind, mehrere Dateien in einer einzigen komprimierten Datei zusammenzufassen. Bei der Dekompression werden natürlich wieder die einzelnen Originaldateien erzeugt.

PGP versucht nicht, eine bereits komprimiert vorliegende Klartext-Datei erneut zu komprimieren. Die Empfängerin einer so komprimierten Datei muß sie nach der Entschlüsselung mit PKUNZIP dekomprimieren. Wenn der entschlüsselte Klartext eine PKZIP-komprimierte Datei ist, erkennt PGP dies automatisch, und weist den Empfänger darauf hin, daß es sich wahrscheinlich um eine PKZIP-Datei handelt.(*)

Peter Gutmann hat ein schönes Kompressions- und Archivierungsprogramm namens HPACK geschrieben, das von vielen ftp-Servern im Internet zu beziehen ist. HPACK verschlüsselt komprimierte Dateien unter Verwendung des PGP-Dateiformats und der PGP-Schlüsseldateien. Er bat mich, an dieser Stelle auf HPACK aufmerksam zu machen.

Textprüfsummen und digitale Unterschriften

Diese Textprüfsumme ist ein kleines, 128 Bit langes "Destillat" einer Nachricht, von der Idee her ähnlich einer Quersumme oder einer CRC-Summe. Man kann sich die Textprüfsumme auch als eine Art Fingerabdruck der Nachricht vorstellen. Die Textprüfsumme "repräsentiert" die Nachricht in dem Sinne, daß sich bei jeder Änderung an der Nachricht eine andere Textprüfsumme für die Nachricht ergibt. An der Textprüfsumme läßt sich also erkennen, ob sich ein Fälscher an der Nachricht zu schaffen gemacht hat. Die Textprüfsumme wird durch eine kryptographisch zuverlässige Einweg-Hash-Funktion berechnet.(*) Ein Fälscher kann wegen des immensen erforderlichen Rechenaufwands keine zweite Nachricht produzieren, die dieselbe Textprüfsumme wie die Originalnachricht hat. In dieser Hinsicht ist das bei PGP verwendete Verfahren zur Berechnung der Textprüfsumme wesentlich besser als die üblichen Quersummen oder CRC-Summen, bei denen es einfach ist, zu einer gegebenen Nachricht eine zweite Nachricht zu finden, die die identische Quer- oder CRC-Summe hat. Andererseits kann aus der Textprüfsumme ebensowenig wie aus einer Quer- oder CRC-Summe die Originalnachricht berechnet werden.

Die Textprüfsumme wird von dem PGP-Programm der Absenderin einer Nachricht berechnet. Die digitale Unterschrift entsteht dadurch, daß die Absenderin die Textprüfsumme und die Zeitmarke mit ihrem geheimen Schlüssel codiert. Die Absenderin verschickt Nachricht und digitale Unterschrift an den Empfänger. Dessen PGP-Programm ermittelt die Textprüfsumme, indem es die digitale Unterschrift mit dem öffentlichen Schlüssel der Absenderin decodiert. Zur Kontrolle wird die Textprüfsumme aus der erhaltenen Nachricht berechnet. Wenn die aus der Nachricht berechnete Textprüfsumme und die in der Unterschrift enthaltene Prüfsumme übereinstimmen, ist gewährleistet, daß die Nachricht nicht geändert wurde und daß sie von derjenigen Person stammt, deren öffentlicher Schlüssel für die Kontrolle der Unterschrift verwendet wurde.

Ein Fälscher müßte die Nachricht entweder so ändern, daß die Textprüfsumme gleich bleibt, was praktisch unmöglich ist, oder er müßte mit der geänderten Textprüfsumme eine neue digitale Unterschrift erzeugen, was ohne den geheimen Schlüssel der Absenderin auch nicht möglich ist.

Eine digitale Unterschrift beweist, wer eine Nachricht abgeschickt hat, und ob die Nachricht geändert wurde, sei es aufgrund eines technischen Fehlers oder absichtlich . Ebenso verhindert sie, daß ein Absender die Unterschrift unter einer Nachricht ableugnen kann.

Die Verwendung der Textprüfsumme für die digitale Unterschrift hat neben der Geschwindigkeit noch weitere Vorteile im Vergleich zur Codierung der gesamten Nachricht mit dem geheimen Schlüssel. Die Unterschriften haben alle die gleiche geringe Länge, unabhängig von der Größe der jeweiligen Nachricht. Sie ermöglichen der Software eine automatische Kontrolle der Korrektheit einer Nachricht, ähnlich wie Quer- oder CRC-Summen. Die Unterschrift kann getrennt von der Nachricht gespeichert werden, bei Bedarf sogar in einem öffentlich zugänglichen Archiv, ohne daß vertrauliche Informationen aus der Nachricht offengelegt werden, weil es unmöglich ist, aus der Kenntnis der Textprüfsumme irgend etwas über den Inhalt der Nachricht zu ermitteln.

Der bei PGP verwendete Algorithmus für die Berechnung der Textprüfsumme ist MD5 (Message Digest 5), von der RSA Data Security Inc. für Public Domain Verwendung freigegeben. Ronald Rivest, der Entwickler von MD5, schreibt darüber im RFC 1321 im April 1992:

"Es ist zu vermuten, daß der Rechenaufwand, zwei Nachrichten mit derselben Textprüfsumme zu erhalten, in der Größenordnung von 264 Rechenoperationen liegt, und daß der Rechenaufwand, eine Nachricht mit einer vorgegebenen Prüfsumme zu erzeugen, in der Größenordnung von 2128 Operationen liegt. Der MD5-Algorithmus ist sorgfältig auf Schwachstellen hin untersucht worden. Andererseits ist er verhältnismäßig neu, so daß eine weitere Analyse seiner Sicherheit natürlich gerechtfertigt ist - wie bei jedem neuen Vorhaben dieser Art. Der Grad von Sicherheit, den MD5 bietet, dürfte ausreichen, um zusammen mit RSA hochgradig sichere Systeme für digitale Unterschriften zu implementieren."