Beispiel:

ASCII-Text wird auf verschiedenen Computern leicht unterschiedlich dargestellt. Beispielsweise endet eine Zeile bei MS-DOS mit den beiden Zeichen für Wagenrücklauf und Zeilenvorschub. Bei Unix endet eine Zeile nur mit dem Zeichen für Zeilenvorschub. Beim Macintosh endet eine Zeile mit dem Zeichen für Wagenrücklauf, ohne Zeilenvorschub. Traurig, aber wahr.

Nicht verschlüsselte ASCII-Daten werden bei E-Mail-Systemen normalerweise in eine kanonische, maschinenunabhängige Form gebracht, wenn sie zwischen zwei Computern ausgetauscht werden. Bei kanonischer Textdarstellung besteht ein Zeilenende aus den Zeichen Wagenrücklauf und Zeilenvorschub. Beispielsweise konvertiert das weit verbreitete KERMIT den ASCII-Text in diese kanonische Form, bevor der Text an einen anderen Computer gesendet wird, und das KERMIT auf dem Computer, der den Text empfängt, konvertiert ihn wieder in diejenige Form, die sein Betriebssystem braucht. Dadurch ist es einfach, Texte zwischen verschiedenen Computern auszutauschen.

Diese automatische Anpassung der Textdarstellung an das jeweilige Betriebssystem ist bei verschlüsselten Nachrichten nicht möglich, weil der Klartext durch die Verschlüsselung dem Übertragungsprogramm verborgen bleibt. Diese Aufgabe muß das Verschlüsselungsprogramm übernehmen. Deshalb kann man bei PGP angeben, ob der Klartext als Binärdaten oder als ASCII-Text angesehen werden soll. In letzterem Fall wird der Klartext vor der Verschlüsselung in kanonische Form gebracht. Bei der Entschlüsselung wird er dann in die Form gebracht, die für das Betriebssystem des Computers, auf dem entschlüsselt wird, geeignet ist.

Wenn die Option t beim Verschlüsseln und / oder Unterschreiben einer Nachricht mit angegeben wird, konvertiert PGP den Text vor der Verschlüsselung bzw. dem Unterschreiben in die kanonische Form:

Um den Klartext nach der Verschlüsselung und / oder dem Unterschreiben von der Festplatte zu löschen, wird die Option w verwendet:

(*)
Wieder einmal bildet die Amiga-Version eine Ausnahme, hier wird standardmäßig der Originaldateiname als Voreinstellung angeboten. d.Ü.

Um den originalen Namen der Klartext-Datei bei der Entschlüsselung zu erhalten, kann die Option -p verwendet werden:

(*)
Die Frage, unter welchen Voraussetzungen die telefonische Kontrolle eines Schlüssels wirklich zuverlässig möglich ist, ist zusammen mit der Frage, wann man für die Echtheit eines fremden Schlüssel mit der eigenen Unterschrift bürgen kann, das wahrscheinlich schwierigste, aber auch interessanteste Problem bei PGP. So taucht in den Foren von MailBoxnetzen immer wieder die Frage auf, ob sich die telefonische Kontrolle eines Schlüssels auch dann durchführen läßt, wenn sich die Gesprächspartner nicht kennen. Wir halten das nicht für möglich. Für weitere Betrachtungen zu dem Problem der Schlüsselkontrolle sei auf die FAQs verwiesen. d.Ü.

(*)
Es gibt beispielsweise in Hamburg einen Keyserver, auf dem mehrere Megabyte an öffentlichen Schlüsseln liegen. d.Ü.

Die richtige Lösung wäre natürlich, PGP so zu verbessern, daß es geeignete Datenbanktechniken für die Handhabung großer Schlüsselbunde verwendet. Doch solange dies nicht geschehen ist, müssen Sie entweder kleinere Dateien verwenden oder sich mit Geduld wappnen.

(*)
Nähere Informationen hierzu sind in den Quelltexten (pgp.c) zu finden. d.Ü.

Unter MS-DOS könnte das Mantra so gesetzt werden:

Die einzelnen Konfigurationsparameter können je nach Typ als Wert ganze Zahlen, Zeichenketten (also Text), oder "on/off" haben. Eine Beispielkonfiguration, an der man sich bei der individuellen Einstellung orientieren kann, ist PGP beigelegt.

Leere Zeilen werden in config.txt ignoriert, ebenso alles, was in einer Zeile rechts von einem #, der Kommentarmarkierung, steht.

Beachten Sie, daß in der Beispielkonfiguration die Zeilen für die Einstellung mancher Parameter ebenfalls mit einem # beginnen. Für die Aktivierung dieser Parametereinstellung muß das # am Zeilenanfang gelöscht werden. Die Verwendung eines # ist auch sinnvoll, um mehrere Parametereinstellungen auszuprobieren, ohne die Texte der einzelnen Einstellungen zu löschen. Beispiel:

# Die folgende Einstellung ist besser, wenn Texte
# zu ver- oder entschlüsseln sind, die
# unter Windows bearbeitet wurden:
#
charset = latin1
# Für MS-DOS ist das folgende besser:
charset = cp850

Bei den Parameternamen wird nicht zwischen Groß- und Kleinschreibung unterschieden.

Ein Ausschnitt aus einer typischen Konfigurationsdatei:

# TMP is the directory for PGP scratch files,
# such as a RAM disk.TMP = "e:\"
# Can be overridden by environment variable TMP.
Armor = on
# Use -a flag
# for ASCII armor whenever applicable.
# CERT_DEPTH is how deeply
# introducers may introduce introducers.
cert_depth = 3

Die Parameter aus config.txt können auch in der Kommandozeile angegeben werden. Dadurch ist es möglich, im Einzelfall mit anderen Parametern zu arbeiten, ohne daß config.txt extra hierfür geändert werden muß. Die beiden Kommandos im nachfolgenden Beispiel liefern dasselbe Ergebnis:

TMP gibt an, welches Verzeichnis PGP für temporäre Dateien verwendet. Ein sinnvoller Platz für temporäre Dateien ist - falls vorhanden - eine RAM-Disk. Bei Verwendung einer RAM-Disk wird PGP etwas schneller, zudem wird die Sicherheit ein wenig gesteigert. Wenn TMP nicht definiert ist, werden temporäre Dateien im aktuellen Verzeichnis gespeichert. Falls eine Umgebungsvariable TMP definiert ist, verwendet PGP deren Wert als Namen des Verzeichnisses für temporäre Dateien.

PGP gibt eine Reihe von Anfragen, Warnungen und Erläuterungen am Bildschirm aus. Normalerweise erscheinen diese Texte auf englisch. PGP kann so angepaßt werden, daß es diese Meldungen in anderen Sprachen ausgibt, ohne daß die Datei mit dem ausführbaren Programm (also z.B. PGP.EXE für MS-DOS) geändert werden muß.

Eine Reihe von Menschen aus verschiedenen Ländern haben die Textmeldungen von PGP in ihre Muttersprache übersetzt. Diese übersetzten Texte stehen in einer speziellen Datei namens language.txt, die im PGP-Programmpaket enthalten ist. language.txt kann die Meldungen in mehreren Sprachen enthalten. Zur Zeit existieren neben den originalen englischen Texten Übersetzungen in Spanisch, Holländisch, Deutsch, Französisch, Italienisch, Russisch, Litauisch, Lettisch und Esperanto. Andere Sprachen können problemlos ergänzt werden.

Mit dem Parameter LANGUAGE wird festgelegt, in welcher Sprache die Meldungen angezeigt werden sollen. LANGUAGE kann folgende Werte annehmen:

en	für Englisch
es	für Spanisch
de	für Deutsch
nl	für Holländisch
fr	für Französisch
it	für Italienisch
ru	für Russisch
lt3	für Litauisch
lv	für Lettisch
esp	für Esperanto

Bei der Einstellung

LANGUAGE = fr

würden beispielsweise die Texte auf Französisch erscheinen - vorausgesetzt, language.txt enthält französische Texte.

Wenn PGP eine Meldung am Bildschirm anzeigen muß, sucht es in language.txt nach dem Text in der gewählten Sprache. Falls PGP die Datei nicht findet, oder wenn Texte in der gewählten Sprache in language.txt nicht vorhanden sind, oder wenn eine einzelne Meldung nicht übersetzt ist, wird der englische Text ausgegeben.

Um Festplatten- und Diskettenplatz zu sparen, sind die meisten Übersetzungen nicht im Standard-PGP-Paket vorhanden, sind aber getrennt erhältlich.(*)

(*)
Vergleiche hierzu den Abschnitt "Bezugsquellen für PGP" im Anhang. Sollen auch die Hilfetexte von PGP (Kommando pgp -h) in einer anderen Sprache als Englisch ausgegeben werden, muß außerdem eine Datei mit dem Suffix .hlp existieren, wobei der Name der Datei für einen der oben genannten Werte steht, also z.B. de.hlp für Deutsch. d.Ü.

Mit MYNAME kann ausgewählt werden, welchen geheimen Schlüssel PGP automatisch für Unterschriften wählt. Wenn MYNAME nicht definiert ist, wird der neueste geheime Schlüssel verwendet. Wenn die Option -u Benutzer-ID beim Aufruf von PGP angegeben wird, hat diese Auswahl Vorrang vor der Auswahl durch MYNAME.

Der Parameter TEXTMODE ist äquivalent zu der Kommandozeilen-Option -t. Wenn TEXTMODE=on gewählt wird, geht PGP davon aus, daß die zu verschlüsselnden Daten keine Binärdaten, sondern ASCII-Text sind. In diesem Fall werden die Daten vor der Verschlüsselung in die kanonische Form konvertiert. Text in kanonischer Form verwendet als Zeichensatz LATIN1 und als Zeilentrennung die Zeichen Wagenrücklauf und Zeilenvorschub.

PGP schaltet die Konvertierung in kanonische Form automatisch aus, wenn es Daten erkennt, die es für Binärdaten hält.

In der gegenwärtigen VAX/VMS-Implementierung ist TEXTMODE=on die Standardeinstellung.

Genaueres zu Fragen der Textkonvertierung steht weiter oben in diesem Handbuch im Abschnitt "Der Austausch von ASCII-Text zwischen unterschiedlichen Computern".

PGP kann die Sonderzeichen vieler Sprachen für die Zeichensätze verschiedener Computer konvertieren. Damit dies korrekt funktioniert, müssen Sie den Parameter CHARSET richtig einstellen. Diese Konvertierung erfolgt nur bei der Verschlüsselung von Textdateien. Falls Sie mit PGP ausschließlich Texte verschlüsseln, die nur Buchstaben des "normalen Alphabetes", also keine Umlaute, Buchstaben mit Akzenten oder anderen diakritischen Zeichen enthalten, ist der Parameter CHARSET für Sie unwichtig. CHARSET teilt PGP mit, welchen Zeichensatz Ihr Computer verwendet.

CHARSET kann folgende Werte annehmen:

NOCONV	keine Konvertierung
LATIN1	ISO 8859-1 Lateinisches Alphabet 1
KOI8	verwendet auf vielen russischen Unix-Anlagen
ALT_CODES	verwendet auf russischen MS-DOS-Computern
ASCII	7-Bit-Zeichensatz ohne Umlaute
CP850	für die meisten westeuropäischen Sprachen unter MS-DOS

LATIN1 verwendet PGP für die interne kanonische Textdarstellung. Wenn also CHARSET=LATIN1 gewählt wird, findet keine Zeichenkonvertierung statt. Zu beachten ist, daß PGP auch KOI8 wie LATIN1 behandelt, obwohl KOI8 für einen völlig anderen Zeichensatz (kyrillisch) steht. Eine Konvertierung von KOI8 in LATIN1 oder CP850 wäre sinnlos. Die Einstellungen NOCONV, LATIN1 und KOI8 sind für PGP äquivalent.

Wenn Sie mit MS-DOS arbeiten und Nachrichten verschicken oder erhalten, die in einer westeuropäischen Sprache geschrieben sind, sollten Sie CHARSET=CP850 einstellen. Wenn Sie eine Nachricht mit der Option -t oder TEXTMODE=on verschlüsseln, konvertiert PGP Ihren CP850-Text vor der Verschlüsselung in den LATIN1-Zeichensatz. Bei der Entschlüsselung wird LATIN1 in CP850 umgewandelt.

Weiteres hierzu steht weiter oben in diesem Handbuch im Abschnitt "Der Austausch von ASCII-Text zwischen unterschiedlichen Computern".

Der Parameter ARMOR ist äquivalent zur Kommandozeilenoption -a. Wenn ARMOR=on gewählt wird, stellt PGP die verschlüsselten Daten im Radix-64-Format dar. Dieses Format ist für den Versand über manche E-Mail-Kanäle sinnvoll. Die von PGP erzeugten Dateien im Radix-64-Format haben das Suffix .asc.

Wenn Sie PGP hauptsächlich für E-Mail einsetzen, kann es sinnvoll sein, ARMOR=on zu wählen.

Weiteres hierzu steht im ersten Teil des Handbuches im Abschnitt "Versand von Nachrichten im Radix-64-Format".

Wenn PGP eine sehr große Datei im Radix-64-Format erzeugen soll, teilt es diese Datei in mehrere Dateien auf, die jeweils klein genug sind, um im Internet versandt zu werden. Normalerweise lassen Mailer-Programme für das Internet keine Nachrichten zu, die mehr als etwa 50000 Byte groß sind. Eine Datei mit 720 Zeilen im Radix-64-Format liegt weit genug unter dieser Grenze, um problemlos versandt werden zu können. Die einzelnen Dateien, die PGP erzeugt, erhalten als Suffix .as1, .as2, .as3 usw.

Der Parameter ARMORLINES gibt an, wieviele Zeilen eine von PGP erzeugte .asc-Datei maximal enthalten darf. Wird ARMORLINES auf Null gesetzt, kann eine .asc-Datei beliebig groß werden.

Im Fido-Netz dürften Nachrichten in der Regel nicht länger als 32 kB sein, so daß ARMORLINES=450 eine sinnvolle Einstellung für Fido ist. Weiteres hierzu steht im ersten Teil des Handbuches im Abschnitt "Versand von Nachrichten im Radix-64-Format".(*)

(*)
Zum Thema "verschlüsselte Nachrichten im Fido-Netz" fragen Sie bitte einen Systemverwalter Ihres Vertrauens. d.Ü.

Wenn PGP eine .asc-Datei einliest, erkennt es automatisch, daß es eine Datei im Radix-64-Format ist, und konvertiert sie zurück in ihre binäre Form (also eine .pgp Datei), bevor es mit der eigentlichen Entschlüsselung beginnt. Bei der Entschlüsselung erzeugt PGP natürlich auch eine Datei mit dem Klartext.

PGP ermöglicht die Auswahl, ob man die .pgp-Datei behalten möchte, oder ob sie nach der Entschlüsselung gelöscht werden soll. Die .asc-Datei bleibt in jedem Fall erhalten.

Wenn KEEPBINARY=on eingestellt wird, bleibt die .pgp-Datei erhalten; wird KEEPBINARY=off eingestellt, wird die .pgp-Datei nach der Entschlüsselung gelöscht.

Weiteres hierzu steht im ersten Teil des Handbuches im Abschnitt "Versand von Nachrichten im Radix-64-Format".

Mit COMPRESS=on/off kann eingestellt werden, ob PGP den Klartext vor der Verschlüsselung komprimiert. Die Einstellung COMPRESS=off ist im Wesentlichen für das Debuggen von PGP interessant. In der Regel sollte COMPRESS=on gewählt werden, damit PGP den Klartext vor der Verschlüsselung komprimiert.(*)

(*)
Das reduziert Versandkosten und -zeit und erschwert in der Regel eine Kryptoanalyse. d.Ü.

Mit COMPLETES_NEEDED läßt sich einstellen, wieviele voll vertrauenswürdige Unterschriften PGP unter einem Schlüssel verlangt, um diesen Schlüssel als vollständig bestätigt zu betrachten. Mit diesem Parameter hat man also die Möglichkeit, PGP mehr oder weniger mißtrauisch einzustellen.

Genaueres hierüber finden Sie im Abschnitt "Wie überprüft PGP, welche Schlüssel gültig sind?".

Mit MARGINALS_NEEDED läßt sich einstellen, wieviele teilweise vertrauenswürdige Unterschriften PGP unter einem Schlüssel verlangt, damit dieser Schlüssel als vollständig bestätigt betrachtet wird. Mit diesem Parameter hat man also die Möglichkeit, PGP mehr oder weniger mißtrauisch einzustellen.

Genaueres hierüber finden Sie im Abschnitt "Wie überprüft PGP, welche Schlüssel gültig sind?".

CERT_DEPTH gibt an, bis zu welcher Tiefe PGP Unterschriften unter öffentliche Schlüssel prüft, d.h. wie "indirekt" die Bestätigung der Echtheit eines Schlüssels sein darf. Wenn Sie beispielsweise CERT_DEPTH=1 wählen, erkennt PGP nur solche Schlüssel als voll bestätigt an, die von einer Person unterschrieben sind, deren öffentlichen Schlüssel Sie persönlich mit Ihrem geheimen Schlüssel unterschrieben haben. Setzen Sie CERT_DEPTH=0, erkennt PGP nur die Unterschriften als voll vertrauenswürdig, die Sie selbst geleistet haben. Wenn Sie CERT_DEPTH=2 setzen, ist für PGP auch der Schlüssel von Carol voll bestätigt, wenn Carols Schlüssel von Bob, Bobs Schlüssel von Alice, und Alices Schlüssel von Ihnen selbst unterschrieben ist. Der kleinste zulässige Wert für CERT_DEPTH ist 0, der größte 8.

Genaueres hierüber finden Sie im Abschnitt "Wie überprüft PGP, welche Schlüssel gültig sind?".

Die Prüfung der Echtheit eines öffentlichen Schlüssels durch Unterschriften basiert letztlich auf der Echtheit Ihres eigenen Schlüssels, den PGP als absolut vertrauenswürdig ansieht. (Sie können auch mehrere eigene Schlüssel haben, die PGP als voll vertrauenswürdig anerkennt.) Um mögliche Fälschungen an Ihrem Bund mit öffentlichen Schlüsseln erkennen zu können, muß PGP kontrollieren, ob auch Ihr eigener Schlüssel nicht gefälscht wurde. Hierfür vergleicht PGP Ihren öffentlichen Schlüssel mit einer Sicherheitskopie Ihres geheimen Schlüssels, die auf einem fälschungssicheren Medium, beispielsweise einer schreibgeschützten Diskette, gespeichert ist. Zusammen mit dem geheimen Schlüssel sind alle Informationen gespeichert, die Ihr öffentlicher Schlüssel hat. Dies bedeutet, daß PGP Ihren öffentlichen Schlüssel mit der Sicherheitskopie Ihres geheimen Schlüssels vergleichen kann.

Mit dem Parameter BAKRING können Sie den Pfadnamen festlegen, unter dem PGP die Sicherheitskopie Ihres geheimen Schlüssels sucht. Für MS-DOS können Sie beispielsweise BAKRING=a:\secring.pgp angeben, so daß PGP die Sicherheitskopie auf einer schreibgeschützten Diskette sucht. Den Vergleich mit der Sicherheitskopie führt PGP nur durch, wenn Sie mit pgp -kc Ihren gesamten Bund mit öffentlichen Schlüsseln prüfen.

Wenn BAKRING nicht definiert ist, führt PGP diese Kontrolle Ihres eigenen öffentlichen Schlüssel nicht durch.

Genaueres hierüber finden Sie im Abschnitt "Wie überprüft PGP, welche Schlüssel gültig sind?".

Dies legt den Namen der Datei fest, in der PGP die öffentlichen Schlüssel sucht. $PGPPATH wird von PGP durch die DOS-Variable PGPPATH ersetzt.

Analog zu PUBRING legt SECRING den Namen der Datei mit privaten (geheimen) Schlüsseln fest.

Diese Einstellung bezeichnet die Datei, die PGP als "Pool" für die Zufallszahlen dient. Diese Datei wird von PGP nach Generierung der Zufallszahlen verschlüsselt, um einem möglichen Angriff vorzubeugen.

Wenn Sie beim Entschlüsseln die Option -m angeben, können Sie den entschlüsselten Text am Bildschirm lesen, ohne daß PGP ihn in eine Datei schreibt. Standardmäßig verwendet PGP hierzu eigene Routinen, die ähnlich dem Programm "more" bei Unix arbeiten.

Falls Sie ein anderes Programm für Textanzeige am Bildschirm bevorzugen, können Sie es unter PAGER eintragen. Unter MS-DOS können Sie beispielsweise das populäre Shareware-Programm LIST von Vernon D. Buerg verwenden. In diesem Fall würde der PAGER-Eintrag so lauten:

PAGER = list

Wenn jedoch die Absenderin einer Nachricht die Option -m (Klartext nach Entschlüsseln nicht in eine Datei schreiben) angegeben hat, verwendet PGP in jedem Fall seine eigene Anzeigefunktion. Weiteres hierzu steht im Abschnitt "Anzeige des entschlüsselten Klartextes am Bildschirm".

Normalerweise zeigt PGP das Mantra während der Eingabe nicht am Bildschirm an. Dadurch wird es für neugierige Augen schwerer, das Mantra mitzulesen. Es gibt aber Menschen, die Schwierigkeiten haben, ihr Mantra korrekt einzutippen, ohne daß sie es am Bildschirm sehen können. So entstand der Wunsch, PGP für die Anzeige des Mantra konfigurierbar zu machen. In der Abgeschiedenheit einer Wohnung ist es nicht allzu problematisch, das Mantra am Bildschirm anzeigen zu lassen. Wird SHOWPASS=on eingestellt, zeigt PGP das Mantra beim Eintippen am Bildschirm an.

PGP versieht Schlüssel und Unterschriften mit einer Zeitmarke in Greenwich Mean Time (GMT), oder Coordinated Universal Time (UTC), was für unsere Zwecke dasselbe ist. Wenn PGP das Betriebssystem nach Datum und Zeit fragt, nimmt es an, daß die Zeit als GMT-Zeit zurückgegeben wird. Unter Umständen wird die Zeit aber auf schlecht konfigurierten MS-DOS-Rechnern als US Pacific Standard Time plus acht Stunden zurückgegeben. Seltsam, nicht wahr? Vielleicht liegt es an einer Art US-Westküsten-Chauvinismus, daß MS-DOS davon ausgeht, die lokale Zeit sei die US Pacific Time, und GMT darauf basierend ausrechnet. Dies wirkt sich nachteilig auf das Verhalten der MS-DOS-internen Funktionen aus, die PGP verwendet.

Wenn jedoch die MS-DOS Umgebungsvariable TZ für Ihre Zeitzone korrekt definiert ist, korrigiert dies auch die irrtümliche Annahme von MS-DOS, die ganze Welt lebe an der Westküste der USA.

TZFIX gibt die Anzahl der Stunden an, die PGP zur "Betriebssystemzeit" addiert, um GMT-Zeitangaben für Unterschriften und Schlüssel zu erhalten. Wenn die MS-DOS Umgebungsvariable TZ korrekt definiert ist, kann TZFIX auf dem Standardwert 0 bleiben. Unter Unix ist TZFIX in der Regel auch nicht notwendig. TZFIX kann aber für irgendwelche obskuren Betriebssysteme sinnvoll sein, die nie etwas von GMT gehört haben.

Für MS-DOS Systeme, bei denen TZ nicht definiert ist, sollten Sie TZFIX auf 0 in Kalifornien setzen, auf -1 in Colorado, -2 in Chicago, -3 in New York, -8 in London und -9 in Amsterdam. Während der Zeitumstellung im Sommer müssen Sie diese Werte um eins verringern. Was für ein Durcheinander.

Die Definition der MS-DOS Umgebungsvariablen TZ in der autoexec.bat ist eine wesentlich sauberere Lösung. In diesem Fall liefert MS-DOS die korrekte GMT-Zeit und berücksichtigt auch die Sommerzeit, abhängig von der jeweiligen Zeitzone:

In Los Angeles:	SET TZ=PST8PDT
In Denver:	SET TZ=MST7MDT
In Arizona(*):	SET TZ=MST7
In Chicago:	SET TZ=CST6CDT
In New York:	SET TZ=EST5EDT
In London:	SET TZ=GMT0BST
In Amsterdam(**):	SET TZ=MET-1DST
In Moskau:	SET TZ=MSK-3MSD
In Auckland:	SET TZ=NZT-13

(*)
In Arizona gibt es keine Sommerzeit - zumindest wird dort die Uhr im Sommer nicht umgestellt.

(**)
Die Einstellung für Amsterdam gilt für ganz Westuropa außer den britischen Inseln, also auch für Deutschland.

Die ersten drei Zeichen des Wertes von TZ müssen Buchstaben sein, danach muß eine ein- oder zweistellige Zahl, ggf. mit einem Minuszeichen davor, stehen. Stehen hinter der Zahl noch Buchstaben, wertet gmtime() dies als Signal, daß es eine Sommerzeit gibt. Welche Buchstaben vor und ggf. hinter der Zahl stehen, wertet gmtime() nicht weiter aus.

Bei der Sommerzeit-Option ist zu beachten, daß gmtime() als Beginn und Ende der Sommerzeit die in den USA zutreffenden Tage verwendet, die von den in Europa üblichen etwas abweichen. Wie es mit der Sommerzeit in anderen Weltgegenden aussieht, weiß ich nicht.

Falls Ihnen jetzt von dem ganzen Durcheinander um Zeitzonen der Kopf raucht: Geben Sie einfach den MS-DOS-Befehl

Normalerweise liegen mit PGP unterschriebene Nachrichten in Binärform vor, auch dann, wenn sie nicht verschlüsselt werden. Auch die Unterschrift wird in Binärform an die unterschriebenen Daten angehängt. Um eine solche unterschriebene Nachricht über einen 7-Bit-E-Mail-Kanal zu versenden, kann die ASCII-Darstellung im Radix-64-Format verwendet werden (vgl. den ARMOR-Parameter). Die Daten bestehen dann zwar aus druckbaren ASCII-Zeichen, der originale Text ist aber mit bloßem Auge trotzdem nicht mehr zu erkennen, obwohl die Nachricht nicht verschlüsselt ist. Die Empfängerin einer solchen Nachricht muß die "ASCII-Transportverpackung" mit Hilfe von PGP wieder "entfernen", bevor sie die Nachricht lesen kann.

Wenn die originale Nachricht nicht eine Binärdatei, sondern ASCII-Text ist, besteht die Möglichkeit, eine Unterschrift so an den Text anzufügen, daß er nicht in seiner Darstellung geändert wird. In diesem Fall wird nur die Unterschrift im Radix-64-Format dargestellt. Der Text bleibt also auch ohne Hilfe von PGP für die Empfängerin lesbar. Für die Prüfung der Unterschrift ist PGP natürlich trotzdem erforderlich.

Diese Option wird so eingeschaltet: CLEARSIG=on, ARMOR=on (ersatzweise die Option -a), TEXTMODE=on (ersatzweise die Option -t). Beispiel:

VERBOSE kann auf 0, 1 oder 2 gesetzt werden, je nachdem, wie detailliert die Meldungen von PGP sein sollen:

0	Meldungen werden nur ausgegeben, wenn es Probleme gibt. Das richtige für Unix-Fans.
1	Die Standardeinstellung. PGP zeigt in sinnvollem Umfang diagnostische Meldungen und Bedienungshinweise.
2	Ausführliche Meldungen. Diese Option ist hauptsächlich für die Fehlersuche gedacht. Normalerweise ist sie nicht sinnvoll. Ach so, PGP hat doch keinerlei Probleme, oder?

Wenn INTERACTIVE=on gesetzt wird, fragt PGP beim Bearbeiten einer Datei, die mehrere öffentliche Schlüssel enthält, für jeden Schlüssel einzeln nach, ob er in pubring.pgp aufgenommen werden soll.

Es ist wichtig, daß die Freeware-Version von PGP nur zusammen mit den Handbuchdateien, die zum normalen PGP-Distributionspaket gehören, vertrieben wird. Das Handbuch enthält wichtige Informationen zur Bedienung von PGP, sowie wichtige rechtliche Hinweise. Manche Leute haben aber ältere Versionen von PGP ohne das Handbuch vertrieben, was bei den Leuten, die dieses "Vertriebspaket" bekamen, zu einer Reihe von Problemen führte. (Bitte beachten Sie hierzu auch den Abschnitt "Lizensierung und Vertrieb"). Um die Weitergabe von PGP ohne Dokumentation zu unterbinden, wurde PGP so modifiziert, daß es prüft, ob die Handbuchdateien irgendwo auf dem Computer vorhanden sind (z.B. im PGP-Verzeichnis), bevor es die Erzeugung eines Schlüsselpaares zuläßt. Manche Menschen verwenden PGP aber auf winzigen Palmtop- Rechnern mit sehr beschränkter Speicherkapazität. Hier kann es sinnvoll sein, die Handbuchdateien von der Festplatte zu löschen. Um diesen Anwenderinnen gerecht zu werden, kann PGP mit Hilfe der NOMANUAL-Option so eingstellt werden, daß es Schlüsselgenerierung auch dann zuläßt, wenn es die Handbuchdateien nicht findet. Dies geschieht mit der NOMANUAL-Option beim Kommando für die Schlüsselerzeugung:

VERSION_BYTE legt fest, ob die von PGP erzeugten Daten im Format von PGP 2.3 (VERSION_BYTE = 2) oder im Format von PGP 2.6 MIT (VERSION_BYTE = 3) erzeugt werden.

Diese Option ist wegen ihrer "Großzügigkeit" etwas problematisch. Die Angabe einer Versionsnummer in Dateien mit einem speziellen Format, wie dem von PGP, soll verhindern, daß eine veraltete Programmversion versucht, Daten zu bearbeiten, die mit einer neuen Programmversion erzeugt wurden. Dies könnte zu erheblichen technischen Problemen führen. Die Formatänderung, die für die Version 2.6 des MIT durchgeführt wurde, stellt hier eine Ausnahme dar - das Datenformat ist nur in sehr geringem Umfang geändert worden. Prinzipiell hindert Sie bei PGP 2.6ui nichts daran, beispielsweise VERSION_BYTE = 42 anzugeben. Dies wird allerdings mit großer Wahrscheinlichkeit dazu führen, daß die so erzeugte Datei von einer künftigen Version von PGP, die unter dem Datenformat Nr. 42 ganz bestimmte Daten erwartet, zunächst akzeptiert wird, daß diese künftige Version aber vollkommenen Unsinn mit den Daten anstellen wird. Sie sollten deshalb nur die Werte 2 oder 3 angeben.

Mit ARMOR_VERSION können Sie den Text festlegen, der in PGP-Dateien in ASCII-Darstellung als Versionsangabe erscheint.

Auch mit der Möglichkeit, unter ARMOR_VERSION beliebigen Text einzutragen, sollten Sie sehr vorsichtig umgehen. Sie sollten nur die Texte 2.3, 2.3a, 2.6, 2.6.1, 2.6.i, 2.6.2 oder 2.6ui verwenden.

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.

(*)
"16 Runden" bedeutet, daß der DES-Algorithmus sechzehnmal hintereinander für die Verschlüsselung desselben Datenblocks verwendet wird, also gewissermaßen eine 16-fache Verschlüsselung. Diese 16 Runden sind Standard bei DES; die im folgenden beschriebene IDEA-Verschlüsselung benutzt 8 Runden. d.Ü.

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. Zu IDEA siehe auch das dritte Kapitel im Anhang.

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.

(*)
Da IDEA nach der Veröffentlichung der differentiellen Kryptoanalyse geändert wurde, um gegen sie resistent zu sein, ist das nicht so besonders überraschend. d.Ü.

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.

(*)
Das liegt daran, daß gut verschlüsselte Daten sehr "zufällig aussehen", Kompressionsalgorithmen aber darauf basieren, eine bestimmte Systematik in den Daten zu erkennen und auf Grundlage dieser Systematik eine kürzere Darstellung der Daten zu suchen. d.Ü.

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.(*)

(*)
Auch andere Packer wie z.B. arc, zoo und lharc werden automatisch erkannt. GIF8-Bilder werden ebenfalls nicht weiter gepackt etc. d.Ü.

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.

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.

(*)
Eine Einwegfunktion ist eine Funktion, bei der es keine Möglichkeit gibt oder keine Möglichkeit bekannt ist, aus dem Funktionswert auf das Funktionsargument rückzuschließen. Eine Hashfunktion ist eine Funktion, die eine große Menge von Funktionsargumenten möglichst gleichmäßig auf eine vergleichsweise kleine Menge von Funktionswerten abbildet. d.Ü.

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."

Die folgende Diskussion mag manchmal maßlos paranoid erscheinen, aber so eine Einstellung ist für eine fundierte Auseinandersetzung mit möglichen Angriffen durchaus angemessen.

Offensichtliche Passworte, die einfach zu raten sind - wie beispielsweise die Namen von Kindern oder der Partnerin - sind ungeeignet. Ein einzelnes Wort als Mantra kann ebenfalls leicht geraten werden, wenn ein Computer die Wörter eines Lexikons solange als Passwörter ausprobiert, bis das richtige gefunden ist. Deshalb ist eine Kombination mehrerer Wörter, von uns "Mantra" genannt, wesentlich besser als ein einfaches Passwort. Ein verfeinerter Angriff könnte darin bestehen, einen Computer ein Lexikon mit berühmten Zitaten durcharbeiten zu lassen, um das Mantra zu finden. Eine leicht zu merkendes, aber schwer erratbares Mantra läßt sich bequem aus ein paar kreativ sinnlosen Sprüchen oder weithin unbekannten literarischen Zitaten zusammenstellen.

Weiteres hierzu steht im Abschnitt "öffentliche Schlüssel vor Manipulation schützen".

Zusammengefaßt: Wenn man einen öffentlichen Schlüssel für die Verschlüsselung einer Nachricht oder für die Prüfung einer Unterschrift verwenden will, muß sichergestellt sein, das er nicht gefälscht ist. Der Echtheit eines neu erhaltenen öffentlichen Schlüssels sollte man nur dann vertrauen, wenn man ihn unmittelbar, auf sicherem Weg, von seinem Besitzer erhalten hat, oder wenn seine Echtheit von jemandem bestätigt ist, dem man vertraut. Man muß auch dafür sorgen, daß kein Fremder Änderungen an dem eigenen öffentlichen Schlüsselbund vornehmen kann. Man braucht physikalische Kontrolle sowohl über den Bund mit öffentlichen Schlüsseln wie auch über den Bund mit geheimen Schlüsseln. Am besten aufgehoben sind diese beiden Dateien auf dem eigenen PC, um einiges schlechter auf einem am Ende auch noch räumlich weit entfernten Mehrplatz-Rechner. Auf jeden Fall sollte man Sicherheitskopien der beiden Schlüsseldateien haben.

Nichts hindert eine unehrliche Benutzerin daran, die Einstellung von Datum und Zeit auf ihrem Computer zu ändern und bei dieser falschen Datumseinstellung ihre Schlüsselbestätigungen und Unterschriften zu erzeugen. So kann diese unehrliche Benutzerin es so erscheinen lassen, als habe sie eine Unterschrift viel früher oder später geleistet, als es tatsächlich der Fall ist, oder als habe sie ihr Paar von öffentlichem und geheimem Schlüssel zu einem anderen Zeitpunkt generiert. Dies kann von juristischem oder finanziellem Nutzen sein. Beispielsweise kann dadurch ein Schlupfloch entstehen, um eine Unterschrift nicht anerkennen zu müssen.

Abhilfe bieten könnten allgemein vertrauenswürdige Institutionen oder Notare, die notariell beglaubigte Unterschriften mit einer vertrauenswürdigen Zeitangabe machen können. Dies setzt nicht notwendigerweise eine zentrale Institution voraus. Unter Umständen kann jeder vertrauenswürdige Vermittler oder eine unbeteiligte dritte Person diese Aufgabe wahrnehmen, ähnlich öffentlich bestellten Notaren. Die Bestätigung eines öffentlichen Schlüssels könnte von dem Notar unterschrieben werden, und die Zeitmarke bei der Unterschrift des Notars könnte juristische Bedeutung erlangen. Der Notar könnte über solche Bestätigungen Protokoll führen. Das Protokoll wäre öffentlich einsehbar.

Der Notar könnte auch die Unterschrift anderer durch seine eigene Unterschrift bestätigen. Dies könnte als urkundliche, beweiskräftige Unterschrift gelten, so wie es "real existierende Notare" mit Unterschriften auf Papierdokumenten seit langem machen. Auch in diesem Fall würde der Notar über die Unterschriften Protokoll führen, indem er die von dem Textdokument abgetrennten Unterschriften archiviert. Die Unterschrift des Notars hätte eine vertrauenswürdige Zeitangabe, mit größerer Glaubhaftigkeit als die Zeitangabe der originalen Unterschrift. Eine Unterschrift würde durch die hinzukommende notarielle Unterschrift und das Protokoll des Notars "Beweiskraft" erhalten.

Das Problem notariell beglaubigter Unterschriften und glaubwürdiger Zeitmarken bedarf weiterer Diskussion. Eine gute Abhandlung hierüber ist der Aufsatz von Dorothy Denning in IEEE Computer 1983 (siehe Literaturverzeichnis). Die möglichen Verfahren für Bestätigung und Beglaubigung müssen noch viel detaillierter ausgearbeitet werden. Dies wird sich durch die zunehmende Nutzung von PGP ergeben und dadurch, daß bei anderen Programmen, die das Prinzip öffentlicher Schlüssel verwenden, andere Bestätigungsverfahren entwickelt werden.

(*)
Interessanterweise ist das aber alles, was das deutsche Datenschutzgesetz verlangt. d.Ü.

Hierzu eine wahre Horrorgeschichte: Eine Freundin von mir, verheiratet und Mutter kleiner Kinder, hatte eine kurze und nicht sehr ernstzunehmende Liebesaffäre. Sie schrieb ihrem Liebhaber auf dem Computer einen Brief, und nachdem sie den Brief abschickte, löschte sie die Datei. Nachdem die Affäre schon vorbei war, ging die Diskette kaputt, auf der der Brief gespeichert war. Weil die Diskette einige andere wichtige Daten enthielt, bat sie ihren Ehemann, die Diskette zu reparieren. Der ließ die Diskette von einem Datenwiederherstellungsprogramm bearbeiten, wobei neben den von seiner Frau benötigten Dateien auch der besagte Brief wieder zu Tage kam, was eine Kette tragischer Ereignisse auslöste. (*)

(*)
Von weiteren Horrorgeschichten - darunter auch ein mutmaßlicher Mordfall - über nicht richtig gelöschte Daten berichtet Peter Gutmann in seinem Handbuch zu SFS.

(*)
dieses Wissen haben bei den meisten Betriebssystemen, wenn überhaupt, nur ausgekochte Betriebssystemspezialisten d.Ü.

Selbst wenn man den Klartext auf der Festplatte oder Diskette überschreibt, kann ein technisch gut ausgestatteter Angreifer die Daten wiedergewinnen. Geringe magnetische Spuren der Originaldaten bleiben auch nach einem Überschreiben auf der Festplatte oder Diskette. Diese Spuren können unter Umständen mittels spezieller Hardware gelesen werden.

Ein Schutz hiergegen fällt unter das allgemeine Thema des Schutzes gegen Viren. Es gibt einige relativ brauchbare kommerzielle Anti-Virus-Produkte, und es gibt "Hygienemaßnahmen", deren Beachtung das Risiko einer Virusinfektion erheblich reduzieren kann. Eine umfassende Abhandlung dieses Themas würde den Rahmen dieses Handbuchs sprengen. PGP selbst hat keinerlei inneren Schutz gegen Viren, es geht davon aus, daß der PC, auf dem es benutzt wird, eine "vertrauenswürdige Umgebung" ist. Falls es einmal so einen Spezialvirus für PGP geben sollte, ist zu hoffen, daß eine entsprechende Warnung schnell bekannt wird und viele Leute erreicht.

Ein ähnlicher Angriff könnte eine geschickte Imitation von PGP sein, die sich im Wesentlichen wie PGP verhält, aber nicht so arbeitet, wie anzunehmen wäre. Beispielsweise könnte diese Imitation absichtlich dahingehend verstümmelt sein, daß Unterschriften nicht mehr korrekt geprüft werden, so daß gefälschte Schlüssel nicht mehr erkannt werden können. Eine solche Version von PGP - ähnlich einem "Trojanischen Pferd" - ist von einem Angreifer verhältnismäßig einfach erstellt, weil der Quellcode von PGP weit verbreitet ist. Deshalb ist es kein Problem, den Quellcode dahingehend zu manipulieren, daß eine Imitation von PGP entsteht, die zwar echt aussieht, jedoch nur die Anweisungen ihres teuflischen Meisters ausführt. Dieses "Trojanische Pferd" von PGP könnte weit verteilt werden, mit dem Anschein, es käme von mir. Wie hinterhältig.

Die allgemeine Verfügbarkeit des Quellcodes von PGP hat aber auch einen anderen, vertrauensschaffenden Aspekt: Die entsprechenden Programmierkenntnisse vorausgesetzt, ist es nur noch eine Frage des Fleißes, den Quelltext auf obskure Stellen durchzusehen. Außerdem kann man das Programm neu übersetzen und sich so eine eigene Arbeitsversion erstellen. Der im nächsten Absatz erwähnte Vergleich mehrerer PGP-Versionen aus unterschiedlichen Bezugsquellen sollte aber zumindest für die selbst erstellte Version vorsichtig interpretiert werden: Selbst wenn der gleiche Compiler verwendet wird, besteht immer noch die Möglichkeit, daß die eigene PGP-Version mit der Compiler-Version 12.34a1 übersetzt wird, während das Entwicklerteam Version 12.34b3 verwendet hat. Unterschiede in den PGP-Versionen bedeuten deshalb nicht gleich das Schlimmste. Auf der anderen Seite heißt das aber auch, daß ein neu übersetztes PGP andere Benutzer verunsichern kann. Deshalb sollte man normalerweise besser die Originalversion weitergeben. d.Ü.

Man sollte sich die Mühe machen, PGP von einer zuverlässigen Bezugsquelle zu erhalten, was auch immer das heißen mag. Oder man besorgt sich PGP von mehreren unabhängigen Quellen und vergleicht die einzelnen Versionen mit einem geeigneten Programm.

Mit Hilfe digitaler Unterschriften ergeben sich weitere Möglichkeiten festzustellen, ob an PGP herumgepfuscht wurde. Wenn eine Person, der man vertraut, eine digitale Unterschrift für die Datei mit dem ausführbaren PGP-Programm(*) leistet und damit garantiert, daß die Datei zum Zeitpunkt der Unterschrift nicht infiziert oder anderweitig verfälscht ist, kann man einigermaßen sicher sein, eine brauchbare Kopie zu haben. Mit Hilfe einer älteren, vertrauenswürdigen Version von PGP kann die Unterschrift für die neue, zunächst zweifelhafte Version kontrolliert werden. Dieser Test setzt natürlich voraus, daß der für die Kontrolle der Unterschrift verwendete öffentliche Schlüssel einen hohen Grad an Vertrauen hat.

(*)
Für MS-DOS heißt dies ganz schlicht: PGP.EXE d.Ü.

(*)
Für die Bundesrepublik gilt ähnliches - Spitzel von Verfassungsschutz und Polizei hat es schon häufig gegeben. Mittlerweile geht die Diskussion ihres legalen Einsatzes bis zu der Frage, ob in Zukunft verdeckt arbeitende Polizeibeamte mit Gesetzessegen auch Straftaten begehen dürfen. d.Ü.

Diese Art von Angriffen ist einfacher und billiger als ein kryptoanalytischer Angriff auf PGP.

Wer allerdings der Meinung ist, derartig ausfeilten Angriffen ausgesetzt zu sein, sollte sich ohnehin mit einem Sicherheitsberater in Verbindung setzen.

Aber mittlerweile gibt es PGP auch für Unix und VAX/VMS, also Mehrplatz-Betriebssysteme. Bei diesen Betriebssystemen besteht ein wesentlich höheres Risiko, daß Klartext-Dateien, Schlüssel oder Passworte offengelegt werden. Der Systemverwalter oder ein versierter Eindringling kann die Klartext-Dateien lesen und unter Umständen auch mittels spezieller Software heimlich die Tastatureingaben und die Bildschirmausgaben mitlesen. Unter Unix kann jede Benutzerin mit dem Kommando ps einiges an Informationen über die anderen Benutzer erhalten, beispielsweise alle Umgebungsvariablen.(*) Ähnliche Probleme gibt es für MS-DOS-Rechner, die in einem Netzwerk arbeiten. Das aktuelle Sicherheitsrisiko hängt von der jeweiligen Situation ab. Ein Mehrplatz-Rechner kann sicher sein, wenn man allen Benutzern traut oder wenn die Sicherheitsmechanismen ausreichen, um den Angriffen von Eindringlingen standzuhalten, oder auch, wenn es ganz einfach keine hinreichend interessierten potentiellen Eindringlinge gibt. Manche Unix-Systeme sind schon dadurch sicher, daß sie von nur einer Person benutzt werden - es gibt bereits Notebooks, die mit Unix arbeiten. PGP vollkommen von der Benutzung unter Unix auszuschließen, wäre unsinnig.

(*)
Wenn jemand dann auf einer Unix-Mehrplatz-Maschine noch aus Faulheit pgppass - nicht zu verwechseln mit pgppath! - setzt, legt er sein Mantra allen anderen Benutzern offen. d.Ü.

(*)
Diese Art der Überwachung, die eigentlich auch noch das durch PGP verhinderte Durchsuchen der ganzen Post nach Schlüsselworten einschließt, ist wohl die am besten genutzte Informationsquelle, die Nachrichtendiensten zur Verfügung steht. Grundsätzlich läßt sich PGP aber auch zum Verschleiern dieser Information verwenden, doch das würde hier zu weit führen. d.Ü.

Möglicherweise hat eine Regierung auch geheimgehaltene Methoden, mit denen IDEA(TM), der bei PGP verwendete konventionelle Verschlüsselungsalgorithmus, geknackt werden kann. Das wäre der schlimmste Alptraum eines jeden Kryptographen. In der praktischen Kryptographie gibt es keine Garantie für absolute Sicherheit.

Doch nach wie vor ist etwas Optimismus gerechtfertigt. Die Entwickler von IDEA gehören zu den besten Kryptographen Europas. Die besten Kryptoanalytiker der nicht geheimen Welt haben IDEA einer ausgedehnten Analyse und eingehenden Überprüfung unterzogen. Einer differentiellen Kryptoanalyse, bei der DES fast geknackt worden wäre, scheint IDEA besser standzuhalten.

Aber selbst wenn IDEA die eine oder andere subtile Schwachstelle haben sollte, komprimiert PGP den Klartext vor der Verschlüsselung, was die von einer solchen Schwachstelle ausgehende Gefährdung um einiges reduzieren dürfte. Der für das Knacken erforderliche Rechenaufwand dürfte in den meisten Fällen um einiges höher sein als der Wert der entschlüsselten Nachricht.

Wenn man in einer Situation ist, in der die Furcht vor so einem Angriff größten Kalibers berechtigt ist, wäre es an der Zeit, die Dienste einer Sicherheitsberaterin in Anspruch zu nehmen, die auf die jeweilige Situation zugeschnittene Lösungen anbieten kann. Boulder Software Engineering bietet diese Leistungen an. Adresse und Telefonnummer stehen im Anhang.

Kurz gesagt, ein Gegner kann mühelos, sogar routinemäßig Datenkommunikation abhören, insbesondere, wenn ein Modem oder E-Mail benutzt wird, es sei denn, die Daten sind gut kryptographisch geschützt. Wenn man PGP verwendet und die erforderlichen Vorsichtsmaßnahmen beachtet, muß ein Angreifer erheblich mehr Arbeit und Kosten aufbringen, um in die Privatsphäre einzubrechen.

Wenn man sich vor einfachen Angriffen schützt und annehmen kann, daß man nicht einem entschlossenen und sehr gut ausgestatteten Angreifer gegenübersteht, dann dürfte die Verwendung von PGP sicher sein. PGP sorgt für eine prima geschützte Privatsphäre.

MS-DOS und MS Windows sind eingetragene Warenzeichen der Firma Microsoft. Amiga ist eingetragenes Warenzeichen der Firma Commodore Business Machines Inc. Der Autor übernimmt keine Haftung für Schäden, die aus der Nutzung der Software entstehen, auch dann nicht, wenn die Schäden aus Fehlern der Software resultieren. Der Autor macht keine Angaben über die Verkaufbarkeit der Software oder ihre Brauchbarkeit für bestimmte Anwendungen. Die Software wird nur in der bestehenden Form zur Verfügung gestellt, ohne jede explizite oder implizite Garantie.

Für Anwender außerhalb der USA sei angemerkt, daß das US-Patent auf RSA nur innerhalb der USA(*) gilt und daß es kein RSA-Patent in anderen Ländern gibt. US-Bundesbehörden können RSA nutzen, weil die Entwicklung von RSA staatlich durch Zuschüsse der National Science Foundation und der US-Navy finanziert wurde. Die Verwendung von PGP durch Stellen der US-Regierung unterliegt jedoch Einschränkungen, die sich aus meiner Einigung mit ViaCrypt ergeben. Hierzu später mehr.

(*)
und Kanada d.Ü.

PKP erhielt nicht nur die ausschließlichen Patentrechte für RSA, sondern auch die ausschließlichen Rechte für drei andere Patente für asymmetrische Verschlüsselungsverfahren, die an der Stanford University mit Bundeszuschüssen entwickelt wurden. Im Prinzip entscheidet damit in den USA eine einzige Firma über die Verwendung von public key Verschlüsselungssystemen. PKP beansprucht sogar das Patentrecht an dem grundlegenden Konzept der Kryptographie mit öffentlichen Schlüsseln, unabhängig davon, wie intelligent auch immer ein neuer Algorithmus sein wird, der unabhängig von PKP entwickelt werden könnte. Ich halte ein derart umfassendes Monopol für gefährlich, weil ich der Meinung bin, daß Kryptographie mit öffentlichen Schlüsseln einen zentralen Beitrag zum Schutz der Bürgerrechte und der Privatsphäre in unserer immer mehr verkabelten Gesellschaft leisten kann. Zumindest setzt das Monopol von PKP diese lebenswichtige Technologie dem Risiko der Einflußnahme durch die Regierung aus.

Seit der Version 2.5 (vertrieben vom MIT, dem Inhaber des originalen Patentes auf RSA) verwendet die Freeware-Version von PGP die RSAREF-Routinen, die innerhalb der USA für nichtkommerzielle Anwendungen benutzt werden dürfen.

Die PGP Version 2.0 entstand aus der gemeinsamen Arbeit eines internationalen Programmierteams, das unter meiner Leitung Verbesserungen gegenüber der ersten Version implementierte. Diese Version wurde von Branko Lancaster in Holland und von Peter Gutmann in Neuseeland veröffentlicht, außerhalb der Reichweite des Patentgesetzes der USA. Obwohl es nur in Europa und Neuseeland veröffentlicht wurde, verbreitete sich PGP spontan in die USA, ohne daß ich oder das Entwicklungsteam etwas damit zu tun gehabt hätten.

Das bei PGP ebenfalls verwendete blockorientierte Verschlüsselungsverfahren IDEA unterliegt in Europa einem Patent, das der ETH Zürich und einer Schweizer Firma namens Ascom Tech AG gehört. Die Patentnummer ist PCT/CH91/00117. Die US-Patentnummer ist US005214703, die europäische Patentnummer lautet EP 0 482 154 B1. Für die nicht-kommerzielle Verwendung von IDEA werden keine Lizenzgebühren verlangt. Die Ascom-Tech AG hat eine Lizenz für die nicht-kommerzielle Nutzung von IDEA bei PGP erteilt. In den USA müssen staatliche und kommerzielle Anwenderinnen eine lizensierte PGP-Version von ViaCrypt beziehen, diese schließt eine Lizenz für IDEA mit ein.

Die Verwendung der IDEA-Routinen aus PGP in anderen, kommerziellen Produkten ist ohne eine Lizenz von Ascom Tech nicht erlaubt. Kommerzielle Anwender von IDEA können Details zur Lizensierung bei Dieter Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502 Solothurn, Switzerland, Tel +41-65-242885, Fax +41-65-235761, E-Mail: (profos@tech.ascom.ch) erfahren.

Die bei PGP verwendeten ZIP-Kompressionsroutinen stammen aus Freeware-Quellcode und werden mit Erlaubnis des Autors verwendet. Mir sind keine Patente bekannt, die für die Kompressionsalgorithmen erteilt worden wären, aber Sie können diese Frage gerne selbst genauer untersuchen. Ascom hat vor kurzem seine Politik bezüglich der kommerziellen Nutzung außerhalb der USA geändert, hierbei scheint noch einiges in Bewegung zu sein(*).

(*)
Laut Aussage der Ascom-Tech bezog sich die Lizenz lediglich auf die nicht-kommerzielle Nutzung von IDEA in PGP. Offensichtlich lag ein Mißverständnis vor.

Unabhängig von den komplizierten und teilweise überlappenden Beschränkungen und Bedingungen der verschiedenen Patent- und Urheberrechte (RSA, RSAREF und IDEA), die verschiedene Institutionen haben, gilt eine weitere Beschränkung auf die Benutzung von PGP, die sich aus meiner Einigung mit ViaCrypt ergibt: Die Freeware-Version darf nur privat und nichtkommerziell genutzt werden.(*)

(*)
Kommerzielle Anwender außerhalb der USA und Kanadas sollten sich mit Ascom Tech in Verbindung setzen.

PGP ist keine Shareware, es ist Freeware, veröffentlicht als gesellschaftliche Dienstleistung. Daß PGP kostenlos ist, ermutigt viele Menschen, PGP auch zu verwenden. Dies wird hoffentlich größere soziale Auswirkungen haben, woraus sich ein großer Bekanntheitsgrad und eine weite Verbreitung von RSA ergeben könnte.

Scheuen Sie sich nicht, das vollständige PGP-Paket soweit wie möglich zu verbreiten. Geben Sie es allen Ihren Freunden. Wenn Sie Zugang zu MailBoxen haben, stellen Sie PGP in möglichst allen MailBoxen öffentlich zur Verfügung. Auch den Quellcode können Sie beliebig verbreiten. Die ausführbare PGP-Version 2.6 für MS-DOS steht zusammen mit der Dokumentation, einigen öffentlichen Schlüsseln, darunter mein eigener, sowie Unterschriften unter das Programm in einer Datei namens PGP26[MIT].ZIP.(*) Die Quelldateien für MS-DOS sind in einer Datei namens pgp26src.zip enthalten.

(*)
Aufgrund der Exportbestimmungen der USA, die die Ausfuhr dieses Paketes verbieten, bietet es sich an, PGP26I.ZIP zu verwenden. Hiermit lassen sich außerdem auch nach dem 1. September 1994 noch Nachrichten schreiben, die von der 2.3a gelesen werden können. d.Ü.

Kostenlose Kopien und Updates von PGP finden Sie weltweit in tausenden von MailBoxen und anderen öffentlich zugänglichen Archiven, wie ftp-Servern im Internet. Der Ursprung von PGP ist das MIT, speziell der ftp-Server net-dist.mit.edu im Verzeichnis /pub/PGP. Mich selbst brauchen Sie nicht nach PGP zu fragen, insbesondere, wenn Sie außerhalb der USA und Kanadas wohnen.

Nach all der Arbeit an PGP möchte ich noch anmerken, daß ich gegen Fanpost nichts einzuwenden habe, allein schon, um seine Popularität abschätzen zu können. Teilen Sie mir mit, was Sie von PGP halten und wieviele Ihrer Freunde es verwenden. Hinweise auf Fehler und Verbesserungsvorschläge sind natürlich ebenfalls gerne gesehen. In künftigen PGP-Versionen werden Ihre Anregungen möglicherweise berücksichtigt werden.

Das PGP-Projekt wurde nicht finanziell gefördert und hat mir beinahe die Haare vom Kopf gefressen. Sie dürfen deshalb nicht mit einer Antwort auf Ihren Brief rechnen, es sei denn, Sie legen einen frankierten Rückumschlag bei. Lieber antworte ich auf E-Mail. Bitte schreiben Sie auf Englisch, weil meine Fremdsprachenkenntnisse begrenzt sind. Wenn Sie mich anrufen, und ich bin nicht da, probieren Sie am besten etwas später noch einmal. Rückrufe auf Ferngespräche mache ich in der Regel nicht, es sei denn, Sie akzeptieren ein R-Gespräch. Falls Sie mich für längere Zeit brauchen: Ich stehe als Berater auf entsprechender finanzieller Basis zu Verfügung und antworte auch auf derartige Anfragen.

Die ungelegenste Post, die ich bekomme, stammt von Menschen, die mir in der besten Absicht ein paar Dollar schicken mit der Bitte, ihnen PGP zuzusenden. Ich mache das nicht, um rechtlichen Problemen mit PKP aus dem Weg zu gehen. Noch schlechter ist es, wenn so eine Anfrage aus dem Ausland kommt. In dem Fall würde ich es riskieren, die US-amerikanischen Gesetze über den Export von Kryptographie zu verletzen. Aber auch wenn es keine rechtliche Auseinandersetzung um PGP gäbe: Normalerweise reicht das Geld in so einem Brief nicht aus, um den Zeitaufwand zu rechtfertigen, den ich mit dem Versand hätte. Ich bin nicht darauf eingerichtet, im Nebenberuf preiswertes Versandhaus zu spielen. Andererseits kann ich das Geld auch nicht einfach behalten, weil es als Honorar für eine Leistung gedacht ist. Um das Geld aber zurückzuschicken, muß ich mich in mein Auto setzen, zum Postamt fahren und Briefmarken kaufen. Normalerweise kommen diese Anfragen ohne frankierten Rückumschlag. Als nächstes muß ich mir die Zeit nehmen, eine freundliche Antwort zu schreiben, daß ich dem Wunsch der Absender nicht nachkommen kann. Wenn ich die Beantwortung zurückstelle und den Brief einfach auf meinen Schreibtisch lege, kann es passieren, das er innerhalb von Minuten unter Papierstapeln vergraben wird, und erst Monate später wieder ans Tageslicht kommt. Wenn Sie all diese kleinen Unbequemlichkeiten mit der Anzahl der Anfragen multiplizieren, wird Ihnen das Problem klar. Reicht es nicht, daß PGP nichts kostet? Wie schön wäre es, wenn diese Leute versuchen würden, PGP aus irgendeiner der unzähligen vorhandenen Quellen zu beziehen. Wenn Sie kein Modem haben, fragen Sie in Ihrem Bekanntenkreis. Wenn Sie keine Bezugsquelle finden, können Sie mich kurz anrufen.(*)

(*)
In Deutschland ist als Ansprechpartner der FoeBuD e.V. geeignet: FoeBuD e.V., Marktstraße 18, 33602 Bielefeld. Montags bis freitags von 17 bis 19h auch telefonisch unter 0521-175254.

Es gibt so viele fremdsprachige Übersetzungen von PGP, daß die meisten Sprachkits nicht im Standardpaket von PGP enthalten sind, um Speicherplatz zu sparen. Einzelne Sprachkits können Sie aus einer großen Zahl unabhängiger Quellen beziehen. Häufig sind es die gleichen Quellen, bei denen Sie auch das eigentliche PGP-Paket finden. Diese Kits enthalten übersetzte Versionen von language.txt, pgp.hlp und vom Handbuch. Falls Sie daran denken, PGP in Ihre Muttersprache zu übersetzen, setzen Sie sich mit mir in Verbindung, damit Sie die neuesten Informationen und Standardisierungsrichtlinien bekommen, und um herauszufinden, ob es bereits eine Übersetzung in Ihre Sprache gibt. Wenn Sie ein Sprachkit für eine bestimmte Sprache suchen, probieren Sie es am besten in den entsprechenden Internetgruppen oder fragen sie Mike Johnson (mpj@csn.org).

Wenn Sie Usenet-Anschluß haben, beobachten Sie die Newsgroups sci.crypt und die PGP-spezielle Newsgroup alt.security.pgp, um Ankündigungen von neuen PGP-Versionen zu erhalten. Wenn sie PGP suchen, versuchen Sie es zunächst via ftp bei net-dist.mit.edu. Oder fragen Sie Mike Johnson (mpj@csn.org) nach einer Liste von ftp-Sites und BBS-Nummern.

Bitte beachten Sie bei obigen Ausführungen, daß es die US-Regierung als illegalen Export betrachtet, wenn Sie von außerhalb der USA PGP, andere Programme oder Daten, die den Exportbeschränkungen unterliegen von einem US-amerikanischen ftp-Server oder einer US-amerikanischen MailBox kopieren. Möglicherweise gefährden Sie damit sogar einen amerikanischen MailBoxbetreiber. Nach einer Meldung in alt.security.pgp wurde in den USA schon gegen einen MailBoxbetreiber ermittelt, der PGP öffentlich angeboten hat.

In Deutschland ist zu erwarten, daß neue Versionen von PGP nach kurzer Zeit, in der der Sourcecode auf offensichtliche Manipulationen geprüft wird, in der //BIONIC zu finden sein werden. Diese MailBox ist erreichbar unter der Nummer 0521-68000, Loginname PGP, kein Passwort. Wieder mal ein bißchen Werbung in eigener Sache... Weiterhin auch in der HIT, 0681-399426, Username SAUGER, im Brett /BINAER/SAUGER, letztere Adresse gilt allerdings nur für die MS-DOS-Version. Die Amiga-Version wird in sämtlichen Boxen, die das Aminet führen, weitergegeben werden, im FrAS in größeren Abständen wohl auch. Mit kurzer zeitlicher Verzögerung werden Sie neue PGP-Versionen auch auf ftp-Servern außerhalb der USA finden.

Bei künftigen Versionen von PGP kann sich unter Umständen das Datenformat von Nachrichten, Unterschriften, Schlüsseln oder Schlüsseldateien ändern, wenn dadurch wichtige neue Funktionen ermöglicht werden. Daraus können sich Probleme mit der Kompatibilität zur gegenwärtig aktuellen Version ergeben. Diese Versionen werden möglicherweise Konvertierungsprogramme für alte Schlüssel enthalten, aber Nachrichten, die mit alten PGP-Versionen erzeugt wurden, werden nicht unbedingt kompatibel zu den neuen Versionen von PGP sein.

Wenn Sie außerhalb der USA und Kanadas leben, rate ich Ihnen, gegen diese Verordnungen des State Departement nicht dadurch zu verstoßen, daß Sie sich PGP aus den USA besorgen. Tausende von US-Bürgern haben sich PGP nach seiner ersten Veröffentlichung besorgt, und irgendwie ist es dann aus den USA herausgekommen und hat sich dann wie Unkraut von selbst weiterverbreitet. Wenn PGP bereits den Weg in Ihr Land gefunden hat, dann werden Sie wahrscheinlich keine US-Exportgesetze verletzen, wenn Sie sich PGP aus einer Quelle außerhalb der USA besorgen.

Die Versionen 2.0 bis 2.3a von PGP entstanden außerhalb der USA und wurden dort veröffentlicht, auf öffentlich zugänglichen Computern in Europa. Jede dieser Veröffentlichungen hat ihren Weg in die USA gefunden. Es gibt einige Beschränkungen in den USA, die die Einfuhr von Kriegswaffen reglementieren, aber diese sind meines Wissens nie auf Software angewendet worden. Juristische Maßnahmen gegen einen solchen Import dürften eine spektakuläre Auseinandersetzung ergeben.

Die Versionen 2.4-2.6 entstanden in den USA und dürfen nicht von dort exportiert werden.(*) Die ftp-Site des MIT ergreift Schutzmaßnahmen gegen den Export dieser Software, wie sie auf anderen Rechnern bereits seit langem praktiziert werden. Bitte versuchen Sie nicht, diese Schutzmechanismen zu umgehen, um die zukünftige Entwicklung von PGP nicht zu gefährden.

(*)
Die Version 2.6 ist selbstverständlich in Europa problemlos und ohne das Brechen irgendeines Gesetzes zu erhalten. d.Ü.

(*)
Wir haben mit juristischem Englisch nicht viel Erfahrung. Wir wollen deshalb den Leserinnen, die des Englischen kundig sind, das Original dieses auf Deutsch doch etwas seltsam anmutenden Textes nicht vorenthalten: "documentation: PGP is export restricted by the Office of Export Administration, United States Departement of Commerce and the Offices of Defense Trade Controls and Munitions Control, United States Departement of State. PGP cannot be exported or reexported, directly or indirectly, (a) without all export or reexport licenses and governmental approvals required by any applicable laws, or (b) in violation of any prohibition against the export or reexport of any part of PGP."

Aber! Falls Sie jemand darum bittet, unverschlüsselt zu senden, beachten Sie bitte diese Aufforderung unbedingt. In Kriegsgebieten kann das Empfangen einer verschlüsselten Nachricht für die Empfängerin bedeuten, als Spionin sofort und ohne gerichtliches Verfahren standrechtlich erschossen zu werden! Im ZCONNECT-Datenaustauschverfahren der Zerberus GmbH ist deswegen ein eigener Header definiert worden, der auffordert, beim Antworten auf gar keinen Fall verschlüsselte Texte zu senden (was zum Beispiel von MailBox- oder Pointsoftware ausgewertet werden kann). Übrigens: Auch die Briefumschläge des Roten Kreuzes werden in Krisenregionen immer unverschlossen transportiert.

Um diesen Prozeß finanzieren zu können, habe ich ein Spendenkonto eingerichtet.(*)

(*)
Die näheren Angaben hierzu stehen bereits im ersten Kapitel der Übersetzung. d.Ü.

Version 2.0 ist weitgehend kompatibel mit neueren Versionen. Weil neue Versionen von PGP auch neue Möglichkeiten bieten, können die älteren Versionen manche Dateien, die mit neueren Versionen erzeugt wurden, nicht in jedem Fall bearbeiten. Wir haben uns Mühe gegeben, die internen Datenstrukturen dieser Version von PGP so zu entwerfen, daß sie an künftige Änderungen angepaßt werden können, so daß hoffentlich niemand noch einmal bei einer kommenden Version von PGP die alten Schlüssel wegwerfen und neue generieren muß.

Bis zur Version 2.3 (2.3a ist ein kleiner Bugfix, d.h. es ist ein Programmierfehler entfernt worden, der Klartext-Unterschriften betraf) war PGP "Guerilla-Freeware", die außerhalb der USA unter Philip Zimmermanns Federführung entstand. Das hatte zur Folge, daß die Verwendung von PGP innerhalb der USA eine Verletzung von Patentrechten darstellte. Das nächste PGP, das entwickelt wurde (2.4), umging diese Probleme dadurch, daß es sich um eine kommerzielle Version handelte, die von ViaCrypt, Phoenix, Arizona vertrieben wurde. Mit dem Kauf dieser Version erhielt man das Recht, PGP kommerziell einzusetzen, die nötigen Abgaben an PKP und Ascom Tech waren im Preis eingeschlossen.

Um eine in den USA legale Version von PGP zu erstellen, schloß Philip Zimmermann ein Abkommen mit PKP und dem MIT, ein PGP zu entwickeln, das die frei verwendbaren RSAREF-Routinen benutzt. Teil dieser Abmachung war eine Änderung der Urheberrechtsbestimmungen. PGP wird ab der Version 2.5 (die erste MIT-Version) nicht mehr unter den Bestimmungen der General Public License der Free Software Foundation (Stichwort GNU-Projekt) vertrieben, sondern diese Bestimmungen haben Einschränkungen erfahren, die sich zum Teil in den RSAREF-Bedingungen begründen, zum Teil in der Abmachung von Philip Zimmermann mit PKP.

Kurze Zeit nach der Freigabe der Version 2.5 entstand die Version 2.6. Diese Version hatte - wiederum aufgrund eines Abkommens - eine "Zeitbombe" eingebaut, die zur Folge hatte, daß sie ab dem 1. September 1994 Nachrichten, Schlüssel und Unterschriften erzeugt, die mit früheren Versionen nicht gelesen werden können. Das dient dazu, die Verwendung der (in den USA immer noch illegalen) Version 2.3(a) einzudämmen. Um internationale PGP-Kommunikation zu ermöglichen, ohne US-Exportverbote zu verletzen, haben einige Leute sehr bald die nötigen Änderungen am Quelltext veröffentlicht. Diese hat Peter Simons in seine Amiga-Version 2.3a.2 eingebaut, wobei die Version 2.3a.3 enstand (aktuell ist 2.3a.5, die deutlich schneller ist) und ein Engländer mit dem Pseudonym Mathew hat sie in eine MS-DOS-Version 2.3a eingebaut und das Produkt 2.6ui genannt, wobei "ui" für "unofficial international" steht. Unofficial deshalb, weil die Version von keinem Programmierer des PGP-Teams abgesegnet ist, international deshalb, weil die Version außerhalb der USA entstanden ist und ohne Probleme in allen Ländern, die Verschlüsselung gestatten, verwendet werden kann - außer in den USA.

Um ihren kommerziellen Kunden eine Kommunikation mit 2.6-Anwendern zu ermöglichen, brachte ViaCrypt die Version 2.7 auf den Markt.

Die neueste Version ist die 2.6.2, ein Bugfix zur 2.6 vom MIT. Diese Version sollte nur innerhalb der USA verwendet werden, da eine Verbreitung der USA-Version nach Europa das Abkommen zwischen Philip Zimmermann und PKP gefährdet. Außerhalb der USA sollte nach wie vor die Version 2.6.i bzw. 2.3a.5 verwendet werden. Eine 2.6.i für den Amiga ist auch bereits in Umlauf.

Bitweise Addition zweier Zahlen ohne Übertrag (XOR)

Addition zweier Zahlen ohne Berücksichtigung des Übertrags über 216 hinaus.

Multiplikation zweier Zahlen und Bildung des Restes nach Division durch 216+1. Hierbei werden 0 und 216 besonders behandelt: Vor Beginn der Multiplikation wird eine 0 durch 216 ersetzt, das Ergebnis 216 wiederum wird als 0 interpretiert. Daraus folgt: 0 "mal" 0 = 1.

Aus dem 128-Bit-Schlüssel werden Teilschlüssel berechnet, und zwar S1,1 bis S8,6 und S9,1 bis S9,4. Hierfür wird der Schlüssel in acht 16 Bit große Teile geteilt, diese ergeben S1,1 bis S1,6, S2,1 und S2,2. Anschließend wird der gesamte 128-Bit-Schlüssel um 25 Bit nach links rotiert und wieder in acht Blöcke zu je 16 Bit unterteilt, die dann S2,3 bis S2,6 und S3,1 bis S3,4 werden. Dann wird wieder rotiert und so weiter.

Die eigentliche Verschlüsselung läuft so ab, daß ein Klartextblock von 64 Bit Länge in vier Blöcke zu je 16 Bit eingeteilt wird, die anschließend dem Verfahren in Abb. 4 unterworfen werden. Dargestellt ist nur der erste Durchlauf, das Verfahren wird achtmal angewendet.

Zum Entschlüsseln kann dasselbe Verfahren verwendet werden. Damit dabei der ursprüngliche Klartext erhalten bleibt, müssen die Teilschlüssel wie in Abb. 5 gewählt werden.

Das System basiert auf Rechnungen im Körper der ganzen Zahlen modulo pq, wobei p und q zwei Primzahlen sind. In diesem System zu rechnen, geht ebenso vor sich wie gewohnt, nur, daß vom Ergebnis nur der Rest bei Division durch pq behalten wird. Wenn wir als Beispiel pq = 15 setzen, dann sind folgende Rechnungen korrekt:

2 + 5 = 7
2 * 5 = 10
4 * 5 = 5
4 * 4 = 1
1 / 4 = 4

Von besonderem Interesse sind hier die Exponentialfunktionen:

5 ^ 2 = 10
4 ^ 7 = 4

Denn es ist kein effizientes Verfahren bekannt, diese Rechnung umzukehren, d.h. es ist keine Möglichkeit bekannt, in annehmbarer Zeit Probleme wie (x^5 = 12) zu lösen. (Auf der Schwierigkeit des diskreten Logarithmus, also der Lösung von (6^x = 8) etc., beruhen andere Verfahren.) Weiterhin interessant ist eine Beziehung, die schon Euler bekannt war:

a^{phi (x)} = 1 (mod x)

Wobei = hier das Zeichen dafür ist, daß wir das oben erwähnte Modulo-Rechnen durchführen, und zwar mod x. phi (x) ist die Eulersche Phi-Funktion. Für uns wichtig ist nur, daß phi (pq) = (p - 1)(q - 1) gilt, wiederum für Primzahlen p und q. Eine kurze Rechnung ergibt:

a ^ {phi (pq)} = 1 (mod pq)
a ^ {(k * phi (pq))} = 1 (mod pq)
a ^ {(k * phi (pq) + 1)} = a (mod pq)

Wenn wir nun zwei Zahlen d und e einführen, von denen wir verlangen, daß de = k * phi (pq) + 1 gelten soll (k sei eine beliebige ganze Zahl ungleich null), dann erhalten wir (ab sofort alle Rechnungen modulo pq):

a^de = a
a^d = b
b^e = a

Wobei die Kenntnis von b und d nicht ausreicht, um a zu berechnen. RSA funktioniert nun so, daß als öffentlicher Schlüssel d und das Produkt pq veröffentlicht werden und die Nachrichten a damit wie eben beschrieben verschlüsselt werden. Die verschlüsselten Nachrichten (b) können dann bedenkenlos versandt werden, da sie ohne e nicht entschlüsselt werden können.

Aus pq und d das geheime e berechnen: Hierzu muß nach derzeitigem Wissensstand pq in seine Faktoren zerlegt werden, was ebenfalls für nicht sinnvoll lösbar gehalten wird.

Eine an verschiedene Empfänger verschlüsselte Nachricht entschlüsseln: Wenn dasselbe a an mehrere Empfänger verschlüsselt wird, wobei dasselbe d verwendet wird (das ist nicht unwahrscheinlich), ist es mit einem kleinen mathematischen Kunstgriff möglich, die Nachricht zu entschlüsseln. Dies betrifft PGP nicht, da hier beim Verschlüsseln an mehrere Empfänger der IDEA-Schlüssel stets mit Zufallszahlen aufgefüllt wird, die für jeden Empfänger verschieden sind (Hybridverfahren).

Die Electronic Frontier Foundation (EFF) wurde im Juli 1990 mit dem Ziel gegründet, die Freiheit des Wortes in digitalen Medien zu verteidigen, insbesondere um sicherzustellen, daß die Grundsätze der Verfassung der USA und ihrer Ergänzungen (Bill of Rights) auch bei computerbasierter Kommunikation zur Geltung kommen. Die EFF ist in Washington DC unter der Telefonnummer 202-347-5400 erreichbar. Ihre Internet-Adresse ist eff@eff.org.

Die Computer Professionals for Social Responsibility (CPSR) unterstützen EDV-Fachleute und Anwenderinnen, die sich für einen verantwortungsvollen Umgang mit Informationstechnologie einsetzen, und fördern die breite politische Auseinandersetzung um die gesellschaftlichen Auswirkungen der Informationstechnologie. Sie sind in Palo Alto unter der Telefonnummer 415-322-3778 und unter der Internet-Adresse cpsr@csli.stanford.edu erreichbar.

Die League for Programming Freedom (LPF) ist eine "grass-root"-Vereinigung von Professoren, Studierenden, Geschäftsleuten, Programmiererinnen und Anwendern, die sich dem Ziel der uneingeschränkten Freiheit bei der Programmerstellung widmen. Die LPF sieht Patente auf Computeralgorithmen als schädlich für die US-amerikanische Computerindustrie an. Telefon: 617-433-7071.
E-Mail: lpf@uunet.uu.net.

Genauere Informationen zu diesen Gruppen finden sie in der Datei politic.doc.(*)

(*)
Eine vergleichbare Datei über Gruppen aus dem deutschen Sprachraum existiert ebenfalls. d.Ü.

Chaos Computer Club e.V. (CCC)
Schwenckestraße 85
D-20257
Hamburg
Tel: +49-40-4903757
Fax: +49-40-4917689

Forum Informatikerinnen für Frieden und gesellschaftliche Verantwortung e.V. (FIFF)
Reuterstraße 44
D-53113 Bonn
Tel: +49-228-219548 (di+do 12-17.30 Uhr)
Fax: +49-228-214924
eMail: fiff@fiff.gun.de

FoeBuD e.V.
Marktstraße 18
D-33602 Bielefeld
Tel: +49-521-175254 (mo-fr 17-19 Uhr)
Fax: +49-521-61172
Box: +49-521-68000
eMail: foebud@bionic.zer.de

Arbeitsgemeinschaft freier MailBoxen e.V. (AGFMB)
Goethestraße 66
D-44147 Dortmund

Hack-tic
Postbus 22953
NL-1100 DL Amsterdam
Tel: +31-20-6222885
eMail: rop@xs4all.nl

Dorothy Denning, "Cryptography and Data Security", Addison-Wesley, Reading, MA 1982

Dorothy Denning, "Protecting Public Keys and Signature Keys", IEEE Computer, Feb 1983

Martin E. Hellman, "The Mathematics of Public-Key Cryptography", Scientific American, Aug 1979

Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54. (Ein "Muß" zu PGP und verwandten Themen)

Xuejia Lai, "On the Design and Security of Block Ciphers", Institute for Signal and Information Processing, ETH-Zentrum, Zurich, Switzerland, 1992

Xuejia Lai, James L. Massey, Seanm Murphy, "Markov Ciphers and Differential Cryptoanalysis", Advances in Cryptology - EUROCRYPT'91

Philip Zimmermann, "A Proposed Standard Format for RSA Cryptosystems", Advances in Computer Security, Vol. III, edited by Rein Turn, Artech House, 1988

Paul Wallich, "Electronic Envelopes", Scientific American, Feb 1993, page 30. (Handelt von PGP.)

William Bulkeley, "Cipher Probe" Wall Street Journal, 28 April 1994, front page. (Handelt von PGP und Zimmermann.)

James Bamford, "The Puzzle Palace: A Report on America's Most Secret Agency", 656 p., 09/1983 (ISBN 0-14-006748-5, Penguin Books), Viking Penguin.

James Bamford, "The Puzzle Palace: Inside the National Security Agency, America's Most Secret Intelligence Organization", rev. & updated ed., 656 p., 12/1993 (ISBN 0-14-023116-1, Penguin Books), Viking Penguin.

John Cary, "Spy vs. Computer Nerd: The Fight Over Data Security2", Business Week, 4 Oct 1993, page 43.

Jon Erickson, "Cryptography Fires Up the Feds", Dr. Dobb's Journal, December 1993, page 6.

John Markoff, "Federal Inquiry on Software Examines Privacy Programs", New York Times, Tuesday 21 Sep 1993, page C1.

Kurt Kleiner, "Punks and Privacy", Mother Jones Magazine, Jan/Feb 1994, page 17.

John Markoff, "Cyberspace Under Lock and Key", New York Times, Sunday 13 Feb 1994.

Philip Elmer-DeWitt, "Who Should Keep the Keys", Time, 14 Mar 1994, page 90.

Branko Lankester, Hal Finney und Peter Gutmann haben sehr viel Zeit damit verbracht, neue Eigenschaften in PGP 2.0 einzubauen und es auf verschiedene Unix-Varianten zu portieren. Hal und Branko leisteten Schwerstarbeit bei der Implementierung meiner Protokolle für die Schlüsselverwaltung. Branko hat damit mehr Zeit verbracht als alle anderen, die sich an der Entwicklung von PGP beteiligt haben.

Hugh Kennedy portierte PGP auf VAX/VMS, Lutz Frank auf den Atari ST, Cor Bosman und Colin Plumb portierten PGP auf den Commodore Amiga.(*)

(*)
Die aktuelle Version portierte Peter Simons. d.Ü.

(*)
Diese übersetzten language.txt. Diese Übersetzung ist schwer aufzutreiben. Mittlerweile existiert auch eine Übersetzung dieser Datei von Marc Aurel. d.Ü.

Charlie Merritt lehrte mich, wie man professionell Arithmetik für große Zahlen programmiert, wie sie bei Public Key Verschlüsselungen üblich sind. Jimmy Upton schrieb eine schnelle Implementierung des Algorithmus zum Multiplizieren mit anschließender Modulo-Bildung. Von Thad Smith stammt ein noch schnellerer Algorithmus hierfür. Zhahai Stewart hatte viele gute Ideen zu den Dateiformaten von PGP und ähnlichem. Er machte den Vorschlag, mehr als eine Benutzerinnen-ID für einen Schlüssel zuzulassen. Vom Konzept beglaubigter Schlüssel erzählte mir Whit Diffie. Kelly Goen hatte die meiste Arbeit bei der elektronischen Erstveröffentlichung von PGP 1.0.

Viele Beiträge zur Verbesserung des Programmcodes stammen von Colin Plumb, Derek Atkins und Castor Fu. Weitere Beiträge, nicht nur zur Programmierung, kommen von Hugh Miller, Eric Hughes, Tim May, Stephan Neuhaus und vielen anderen; zu viele, um ihre Namen jetzt im Gedächtnis zu haben. Die Portierung auf den Macintosh ist in zwei Projekten bei Zbigniew Fiedorwicz und Blair Weiss in Arbeit.(*) Seit der Veröffentlichung von PGP 2.0 haben mir viele andere Programmiererinnen Patches, Bugfixes und Anpassungen für die Portierung auf andere Computer zugesandt. Es sind zu viele, um ihnen hier einzeln zu danken.

(*)
PGP ist mittlerweile auch für den Macintosh verfügbar. d.Ü.

Zimmermann bietet anwenderspezifische Implementierungen von Kryptographie, von Authentizitätsprüfungen und von asymmetrischen Systemen an, außerdem allgemeine anwenderspezifische Entwicklungen.

PGP verwendet das Verschlüsselungsverfahren RSA, das durch ein Patent im Besitz der Firma Public Key Partners geschützt ist. Für PGP-Anwenderinnen außerhalb der USA sei angemerkt, daß es nur in den USA ein Patent auf RSA gibt. Zu beachten ist, daß es allen Personen, die in den USA und Kanada leben, aufgrund der Exportgesetze dieser Staaten verboten ist, kryptographische Software dieser Art zu exportieren. Wenn Sie jedoch außerhalb der USA leben, begehen Sie wahrscheinlich keinen Verstoß gegen das US-Exportgesetz, wenn Sie sich PGP von einer Quelle außerhalb der USA besorgen. Beachten Sie, daß sich der Name "PGP" aufgrund der Verhandlungen mit den RSA-Patentinhabern bei zukünftigen Versionen möglicherweise ändern wird.

Im Folgenden finden Sie eine kleine Auswahl von Stellen, an denen Sie angeblich PGP bekommen können (Stand: Juni 1993). Für die Richtigkeit dieser Informationen gibt es keine Garantie. Einige Einrichtungen in den USA haben PGP aus Angst vor juristischen Einschüchterungsversuchen durch die RSA-Patentinhaber zurückgezogen.

Das Standardpaket von PGP besteht aus zwei komprimierten Dateien, wobei die Dateinamen die Versionsnummer enthalten. Die Version 2.6.i steht in der Datei pgp26i.zip. Diese Datei enthält das ausführbare Programm für MS-DOS und dieses Handbuch (im englischen Original). Außerdem gibt es die Datei pgp26is.zip, die den Quellcode enthält. Diese Dateien können mit PKUNZIP Version 1.10 oder neuer dekomprimiert werden. Unix-Anwender, die keine UNZIP-Implementierung haben, können an denselben Stellen auch die Quelltexte als komprimierte tar-Datei pgp26is.tar.Z finden.

Zur Erinnerung: Wählen Sie Binärübertragung, wenn Sie sich die Dateien per ftp holen. Unter Kermit muß auf beiden Seiten die Betriebsart "8 Bit binär" gewählt werden. Und nun eine kleine Liste anonymer ftp-Server, die PGP anbieten:

Deutschland: ftp.informatik.uni-hamburg.de (134.100.4.42)
Directory: /pub/virus/crypt/pgp/

Finnland: nic.funet.fi (128.214.6.100)
Directory: /pub/unix/security/crypt/

Italien: ghost.dsi.unimi.it (149.132.2.1)
Directory: /pub/security/

Großbritannien: src.doc.ic.ac.uk (146.169.2.10)
Directory: /computing/security/software/PGP

Falls Sie ftp nicht einsetzen können: nic.funet.fi bietet auch "ftp-Mail-Service" an. Um PGP zu bekommen, senden Sie die folgende Nachricht an mailserv@nic.funet.fi:

Jeden Monat findet die Veranstaltung PUBLIC DOMAIN statt, mit Vorträgen und Aktionen zu Themen aus dem Bereich Zukunft und Technik, Wissenschaft und Politik, Kunst und Kultur. Jede Woche gibt es ein Treffen in einem Café, wo sich die Aktiven in großer Runde zum Gedankenaustausch einfinden, und das gleichzeitig auch Anlaufpunkt für alle Interessierten ist.

Der FoeBuD unterhält in den eigenen Räumen die MailBox //BIONIC. Hier befinden sich auch das Archiv, öffentliche Terminals sowie eine kleine Teeküche - ein beliebter Treffpunkt. Nicht nur auf der jährlichen Computermesse CeBIT in Hannover ist der FoeBuD seit einigen Jahren mit einem eigenen Stand vertreten, auch an anderen Congressveranstaltungen und Messen beteiligt er sich aktiv mit eigenem Programm.

Ein weiterer Schwerpunkt liegt im Design anwenderfreundlicher Software, Veröffentlichung allgemeinverständlicher Fachliteratur (wie z.B. diese Anleitung) und Kommunikationsdesign im weitesten Sinne, beispielsweise Konzeption und Organisation eines Mediencafés ("Globaler Dorfbrunnen"). Hier werden Ideen erdacht und Lösungen entwickelt.

Die Veranstaltungen waren auf Anhieb ein großer Erfolg und entwickelten sich schnell zunächst zum Treffpunkt der Bielefelder und später dann der bundesweiten Szene. 1987 gründeten Menschen, die sich bei der PUBLIC DOMAIN zusammengefunden hatten, den FoeBuD e.V. Die Besucherzahlen stiegen und stiegen, längst hatte es sich herumgesprochen, daß die PUBLIC DOMAIN jedesmal ein gesellschaftliches Ereignis ist, das den Rahmen des Üblichen sprengt. Viele Besucherinnen und Besucher reisen zum Teil erheblich mehr als hundert Kilometer weit an. Weitere Informationen zu den PUBLIC DOMAINs lesen Sie bitte in der Broschüre "Vision und Information" nach, die beim FoeBuD e.V. erhältlich ist.

Die eher ganzheitliche Herangehensweise von Frauen an Anwendungen, die Vorliebe für andere Spiele und der andere Stil beim Programmieren bis hin zur (Fach-) Sprache sind eine eigene kulturelle Qualität. Der FoeBuD versucht, den Austausch im Umgang mit dem Rechner und im Umgang miteinander zu fördern und Frauen und Männern die Entwicklung einer eigenen Identität zu ermöglichen.

Damit alle (also auch diejenigen, die keinen Computer, kein Modem oder Telefon haben) die Chance haben, an dieser Kommunikation teilzunehmen, fordert der FoeBuD öffentliche Terminals, beispielsweise in Bibliotheken und eigens dafür geschaffenen Räumen wie den geplanten Mediencafés. Dort sollen nicht nur die technischen Möglichkeiten vorhanden sein, sondern auch qualifiziertes Personal zur Verfügung stehen, das den kompetenten Umgang - technisch und inhaltlich - damit vermitteln kann. Denn was nützt eine allgemein zugängliche Umweltdatenbank, wenn ich nicht weiß, wie die Informationen abzufragen oder zu deuten sind.

Im kleinen Rahmen passiert das schon in den Räumen des FoeBuD, wo sich neben der MailBox //BIONIC auch das Archiv, öffentliche Terminals und eine winzige Teeküche befinden. Was hier bereits läuft - bisher ehrenamtlich und mit großem persönlichen Engagement - kann als Labormodell betrachtet werden, das nun durch eine öffentliche Finanzierung auf die nächsthöhere Stufe der Entwicklung gestellt werden muß, damit das hier auf engstem Raum versammelte, wertvolle Know-How für die Allgemeinheit nutzbar gemacht werden kann.

Unsere Welt wird immer komplexer, das verfügbare Wissen nimmt täglich zu, Probleme spielen sich schon längst nicht mehr nur lokal oder innerhalb einer Fachdisziplin ab. Eine Vielfalt von Wechselwirkungen will bedacht werden, Wahrnehmung und Sprache verändern sich durch die Medien. Ebenso sind neue Kulturtechniken gefragt, beispielsweise ein sinnvoller Umgang mit einem Überangebot an Information. Das Informationszeitalter hat längst begonnen. Über die Bedeutung von Streitkultur, Datenschutz und Privatsphäre in der Demokratie muß neu nachgedacht werden. Umwälzungen in der Technik haben immer auch Auswirkungen auf das soziale Verhalten der Menschen - ein Bewußtsein für eine zeitgemäße Kultur muß aber erst geschaffen werden.

Mit dem "Bielefeldversuch" ist ein Kristallisationspunkt verschiedener Interessen, Fähigkeiten und Talente entstanden. Für einige bietet der FoeBuD den essentiellen Freiraum zum Experimentieren, für andere ist er ein Berufs(er)findungslabor oder eine innovative SoftWare-Schmiede. Eine Bielefelder Zeitung schrieb davon, daß hier der Expertennachwuchs der Region gemacht wird, und Art d'Ameublement setzt den Schwerpunkt natürlich auf den künstlerischen Aspekt.

Es gilt, eine umfassende Konzeption mit Modellcharakter zu entwickeln, um innovative Ideen, soziale Verantwortung und kritischen Geist zur Entfaltung zu bringen und zur Gestaltung einer lebenswerten Zukunft für uns alle einzusetzen.

Unterstützen Sie unsere Arbeit: Über Menschen, die bei uns mitarbeiten wollen, freuen wir uns ebenso wie über Spenden und Fördermitgliedschaften, die es uns ermöglichen, unser Projekt zu finanzieren!