Teil 3 der Einführung in PGP von Jürgen Pötzsch
Fall 1:
Du möchtest eine verschlüsselte PM an jemanden schicken, und sie
gleichzeitig unterschreiben. Du suchst dir also wieder eine beliebige Datei
auf deiner Festplatte aus, die du verschlüsseln willst, und erinnerst
dich daran, daß "PGP -ea dateiname userid" eine verschlüsselte Datei namens
dateiname.ASC erzeugte, die du nur dann entschlüsseln konntest, wenn du
dich selbst als Empfänger angegeben hattest. Das gilt auch hier, füge
dem Befehl ein "s" hinzu (für "Sign"), er lautet damit "PGP -sea
dateiname User-ID". Damit wird die Datei unterschrieben, gepackt und
verschlüsselt. Prüfen kannst du die Unterschrift beim Entschlüsseln der Datei ("PGP
dateiname"), aber nur, wenn du sie auch an dich selbst verschlüsselt
hast.
Fall 2:
Du möchtest eine Nachricht in ein öffentliches Brett schicken, und
legst Wert darauf, daß diese Nachricht a) keinesfalls verändert irgendwo
ankommt, und b) (für jedermann überprüfbar) von niemand anderem als von
dir persönlich kommt. Die Nachricht soll also nicht verschlüsselt, sondern
klar lesbar, aber dennoch unterschrieben sein. Der Befehl "PGP -sat
dateiname" erledigt das für dich, du erhäst eine Datei etwa mit folgendem
Inhalt:
-----BEGIN PGP SIGNED MESSAGE-----
Hier steht der Nachrichtentext
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Und hier steht die Unterschrift.
-----END PGP SIGNATURE-----
Überprüft man die Datei mit "PGP dateiname", wird etwas wie die
folgende Nachricht angezeigt:
---------------------------------------------------------------------
Diese Datei trägt eine Unterschrift.
Zur Überprüfung wird der öffentliche Schlüssel benötigt. .
BESTÄTIGTE Unterschrift von "Juergen Poetzsch <[email protected]>".
Unterschrift erzeugt: 1995/08/29 13:45 GMT
----------------------------------------------------------------------
(Ab Version 2.6.3i erhält die letzte Zeile den Zusatz:
"... mit 512-Bit Schlüssel 0x0D0AC4D9" )
Wird aber auch nur ein einziges Bit in der Nachricht geändert, erhält
man
die folgende Mitteilung:
----------------------------------------------------------------------
Diese Datei trägt eine Unterschrift. Zur Überprüfung wird der
öffentliche
Schlüssel benötigt. . WARNUNG: Die Unterschrift stimmt nicht mit dem
Datei-Inhalt überein!
FEHLERHAFTE Unterschrift von "Juergen Poetzsch
Unterschrift erzeugt: 1995/08/29 13:45 GMT
-----------------------------------------------------------------------
(Zur letzten Zeile bei Version 2.6.3i: siehe oben)
Wurde in einer Klartextnachricht mit Unterschrift diese Unterschrift
geändert erhält man die Meldung:
-----------------------------------------------------------------------
FEHLER: Falsche Prüfsumme der Versandhülle.
-----------------------------------------------------------------------
Du siehst also, daß eine Unterschrift immer zum Inhalt der Datei
passen muß, die sie unterschreibt. Jede Manipulation am Inhalt der Nachricht
oder an der Unterschrift selbst, fällt sofort auf wenn du die
Unterschrift prüfst.
Fall 3:
Du hast ein Programm geschrieben, kannst dafür garantieren, daß es
100%ig virenfrei ist, und willst es verbreiten. Hier würde es keinen Sinn
machen, die EXE-Datei zu verschlüsseln und dabei zu unterschreiben, wie
im Fall 1, sie im Klartext mit angehängter Unterschrift zu verbreiten
wäre noch unsinniger. In beiden Fällen würde dein Programm nicht mehr
laufen, bzw. wenn du ein Archiv unterschreibst, ließe es sich nicht mehr
entpacken. Deshalb gibt es Möglichkeit Nr.3: vom Dokument abkekoppelte
Unterschriften.
"PGP -sb dateiname" erzeugt die ASCII-Unterschriftsdatei
"dateiname.SIG". Nehmen wir an, du willst die Datei PROG.EXE unterschreiben, dann
gibst du "PGP -sb prog.exe" an, wobei eine Datei namens PROG.SIG entsteht.
Diese Datei kannst du zusammen mit PROG.EXE in ein Archiv packen und
verbreiten. Jeder Empfänger dieses Pakets kann nun, sofern er deinen public
key besitzt, diese Unterschrift prüfen, der Befehl dazu lautet: "PGP
prog.sig prog.exe".
Hier gilt, was du oben über Unterschriften und das dazugehörige
Dokument gelernt hast: jeder Patch oder Virenbefall fällt sofort auf, womit du
beweisen kannst, daß die Datei verändert worden sein muß, nachdem du
sie unterschrieben hast.
In diesem Beispiel wird mit "-sb" eine Binärdatei mit der Endung SIG
erstellt. Wenn du gerne eine lesbare Signatur haben möchtest, kannst du
auch den Befehl "PGP -sab dateiname" verwenden, da die Unterschrift aber
meist ohnehin mit in ein Archiv gepackt wird, ist gegen die Erstellung
einer binären Unterschrift nichts einzuwenden. *.ASC-Dateien können
Schlüssel, verschlüsselte Nachrichten oder Signaturen enthalten, bei
*.SIG-Dateien ist der Inhalt schon am Namen ersichtlich.
Übrigens: diesem Kurs ist im Originalarchiv eine abgekoppelte
Unterschrift beigefügt, wenn dein PGP diese Unterschrift bestätigt, dann kannst
Du sicher sein, daß ich jeden Buchstaben in diesem Text genau so
geschrieben habe, wie du ihn hier vorliegen hast.
[Seitenbeginn] [Zurück zur PGP Seite]
Es wurde bereits im ersten Teil des Kurses angesprochen, es kann Fälle
geben, die es erfordern daß man seinen Schlüssel widerruft. Das könnte
passieren, wenn irgendjemand in den Besitz deines secret keys gekommen
ist, schlimmstenfalls sogar mit deiner Passphrase.
Um in einem solchen Fall wenigstens kundzutun, daß der Schlüssel nicht
mehr gültig ist, muß man seinen Schlüssel zurückrufen. Dazu erstellt
man sich ein sogenanntes "key revocation certificate" (eine
Schlüsselrückrufsurkunde). Dazu dient der Befehl:
"PGP -kd User-ID",
damit würde aus meinem Schlüssel der jetzt so aussieht...
Typ Bits ID Datum Benutzer
öff 512/0D0AC4D9 1994/04/03 Juergen Poetzsch <[email protected]>
unt 0D0AC4D9 Juergen Poetzsch <[email protected]>
... ein Rückrufszertifikat, das so aussieht:
Typ Bits ID Datum Benutzer
zur 512/0D0AC4D9 1994/04/03 *** ZURÜCKGEZOGEN ***
Juergen Poetzsch <[email protected]>
Das "zur" soll "zurückgezogen" bedeuten, in der englischen Version
erscheint hier ein "rev" für "revokation".
Dieses Rückrufszertifikat funktioniert wie ein normaler Schlüssel! Es
wird so aus dem Keyring extrahiert (-kxa), so weit wie möglich
verbreitet, und so in andere Keyrings aufgenommen wie ein normaler Schlüssel. Der
betreffende Schlüssel wird dann weltweit als ungültig betrachtet und
jeder Anwender wird darauf hingewiesen, wenn er ihn benutzen will. Für
Rückrufszertifikate gilt das gleiche was schon für User-IDs und
Unterschriften gesagt wurde, sie lassen sich nicht rückgängig machen. Du kannst
zwar einen zurückgerufenen Schlüssel aus Deinem eigenen Keyring entfernen
und den Originalschlüssel wieder aufnehmen, aber ein verbreitetes
Rückrufszertifikat läßt sich durch Aufnahme des ursprünglichen Schlüssels nicht
ersetzen, der Schlüssel bleibt dann zurückgerufen.
[Seitenbeginn] [Zurück zur PGP Seite]
Der schlimmste anzunehmende Fall, sozusagen der Super-GAU, tritt ein,
wenn dein Schlüsselpaar in falsche Hände gerät, und du keine
Sicherheitskopie davon besitzt. Dann kannst du nur noch einen öffentlichen Aufruf
an alle PGP-User starten, damit die deinen Key quasi "von Hand" als
ungültig markieren. Auch dazu dient der Befehl "PGP -kd userid", damit kann
ein beliebiger Key (außer deinem eigenen) gesperrt und auch wieder
entsperrt werden. Das hat den gleichen Effekt wie ein Rückruf, nur daß dieser
Befehl lediglich Einfluss auf den eigenen public Keyring hat (im
Gegensatz zum Rückrufszertifikat).
[Seitenbeginn] [Zurück zur PGP Seite]
unter "Kleinvieh" ist zu verstehen, daß es eine Reihe von
Kleinigkeiten an PGP einzustellen gibt, die nicht unbedingt wichtig sind, damit PGP
richtig arbeitet, aber sie können einem das Leben schon unnötig schwer
machen (eben "Mist" machen ;-) ).
Dir bisher bereits bekannte Einstellmöglichkeiten sind die Variablen
PATH (zu erweitern um den Pfad in dem sich PGP.EXE befindet), PGPPATH
(das Verzeichnis in dem PGP seine Keyrings findet), und TZ (eine
Zeitzonenangabe). Dazu noch etwas Vertiefendes bzw. weitere
Konfigurationsmöglichkeiten.
[Seitenbeginn] [Zurück zur PGP Seite]
Die Variable TZ wurde bisher nicht erklärt, das soll hier nachgeholt
werden. TZ beschreibt eine Zeitzone. Unsere Erde ist in Ost/West-Richtung
in 24 Zeitzonen aufgeteilt. Nullpunkt dieser Zeitzonen ist Greenwich,
ein Ort in der Nähe von London, auf den der 0. Längengrad willkürlich
festgelegt wurde. Wenn es in Greenwich 0:00 Uhr ist, dann ist es in
Deutschland im Winter 1:00 Uhr, im Sommer aber 2:00 Uhr. Wenn man international
Nachrichten austauschen möchte, dann sollte man sich einig werden,
welche Erstellzeit man im Kopf seiner Nachrichten oder in seinen
PGP-verschlüsselten oder unterschriebenen Nachrichten angibt. Deshalb einigt man
sich auf Greenwich als Bezugspunkt. Schreibe ich z.B. hier in Deutschland
eine Nachricht um 16:13 MESZ (mitteleuropäischer Sommerzeit), dann
erhält meine Nachricht die Erstellzeit 14:13 GMT (Greenwich mean time).
Schreibt jemand in New York seine Nachricht um 08:13 EST (eastern standard
time), dann erhält seine Nachricht ebenfalls die Erstellzeit von 14:13
GMT. Damit kann man problemlos die Erstellzeiten von Nachrichten
miteinander vergleichen und bei Kenntnis der Zeitzone auch ebenso problemlos auf
die Ortszeit des Erstellers, oder auf seine eigene Ortszeit
zurückrechnen.
Der Inhalt der Variablen TZ besteht aus drei Teilen:
1. der Name der Zeitzone (3 Buchstaben)
2. ein Korrekturwert bezüglich der Greenwich-Zeit
3. optional eine Sommerzeitangabe (3 Buchstaben).
Der Name der Zeitzone und die Sommerzeitangabe ist dem Anwender
überlassen, solange er sich an die Konvention hält, die besagt, daß beide
Angaben aus drei Buchstaben bestehen müssen. Richtig für Mitteleuropa ist
"CET-1DST", im Klartext "central european time" minus eine Stunde (zu
Greenwich) und "daylight saving time", was schlicht bedeutet, daß wir hier
im Sommer auf Sommerzeit umstellen. Man könnte genausogut "ABC-1DEF" oder
"CDU-1SPD" angeben, der Effekt wäre derselbe, nämlich daß im Winter
(vom 1. Sonntag im Oktober bis zum 1. Sonntag im April) eine Stunde von der
Ortszeit abgezogen wird, im Sommer (1. Sonntag im April bis 1. Sonntag
im Oktober) aber 2 Stunden abgezogen werden.
Bei einer Angabe wie "CET-1" (central european time -1 Stunde) wird
keine Sommerzeit berechnet, da die Angabe (die drei Buchstaben) für die
Sommerzeit fehlt.
Ob deine TZ-Variable richtig eingestellt ist, kannst du prüfen, indem
du PGP ohne Parameter aufrufst, die Zeile "Aktuelles Datum und Uhrzeit"
muß das heutige Datum anzeigen, und die GMT-Angabe muß der aktuellen
Uhrzeit um eine Stunden nachgehen (im Sommer um zwei Stunden!).
PGPPASS
Nicht zu verwechseln mit PGPPATH!!
Während PGPPATH den Pfad angibt in dem PGP "zu Hause" ist, kannst du
mit "SET PGPPASS=dies ist meine pass phrase" dein Passwort schon in der
AUTOEXEC.BAT setzen, dann fragt PGP z.B. beim automatischen Entschlüsseln
nicht mehr nach einem Passwort. Doch Vorsicht: mit diesem Feature kann
jeder der Zugriff auf deinen Rechner hat, nicht nur alle deine
verschlüsselte Nachrichten lesen, er kann auch mit einem einfachen SET-Befehl
dein Passwort im klarsten Klartext auf den Bildschirm zaubern. Dieses
PGP-Featurer ist ein ausgesprochener Risikofaktor und sollte nur dann
verwendet werden, wenn kein Fremder Zugriff auf deinen Rechner hat.
CONFIG.TXT
Ein Bestandteil des PGP-Paketes ist eine Datei namens CONFIG.TXT (beim
IBM-PC, beim AMIGA heißt sie PGP.CONFIG, das hier gesagte gilt für
beide Dateien (soweit ich informiert bin)).
Wie die Dateinamenserweiterung schon sagt, kann man diese Datei mit
einem herkömmlichen Texteditor ansehen und bearbeiten. Du findst dort eine
Reihe von Voreinstellungen, die auch verständlich kommentiert sind, so
daß sich eine Erklärung hier eigentlich erübrigt. Man sollte sich aber
wirklich die Mühe machen, diese Datei einmal durchzulesen, dafür ist sie
extra so ausführlich kommentiert.
Erwähnt seien hier nur einige der wichtigsten Voreinstellungen:
Completes_Needed und Marginals_Needed, das ist die bereits
angesprochenen Mindestanzahl "voll vertrauenswürdiger" und "normal
vertrauenswürdiger" Unterschriften, ab der PGP einen fremden Schlüssel als echt und
unbedenklich betrachten soll.
EncryptToSelf ist eine Variable, mit der du erzwingen kannst, daß jede
Nachricht, die du an jemand anderen verschlüsselst, auch gleichzeitig
an dich selbst verschlüsselt wird. Damit hast du die Möglichkeit,
Nachrichten die z.B. gebounced (zum Absender zurückgeschickt) werden, selbst
wieder zu entschlüsseln. Allerdings dauert die Verschlüsselung deiner
Nachrichten damit auch länger.
MyName ist wichtig, wenn man mehrere eigene Schlüssel verwendet. Hier
gibt MyName an, welcher der Schlüssel standardmäßig zum Unterschreiben
verwendet werden soll.
Damit ist eigentlich alles über PGP gesagt, was man darüber wissen
muß, um damit arbeiten zu können. Wer auf den Geschmack gekommen ist, und
mehr wissen will, dem sei die (im Vorwort bereits angesprochene)
Originaldokumentation zu PGP empfohlen, die es auch in einer deutschen
Übersetzung gibt.
[Seitenbeginn] [Zurück zur PGP Seite]
Ein "Angriff" im Cryptologie-Jargon bezeichnet jede Form eines
Versuchs, Daten, die nicht für die Augen des "Angreifers" bestimmt sind, lesbar
zu machen und zu lesen. Im Gegensatz zu einem Angriff wie man ihn sich
im täglichen Leben vorstellt, nimmt hier der Angegriffene von diesem
Angriff überhaupt nichts wahr, was aber gerade das Gefährliche an einem
solchen
Angriff ist.
Wie könnte ein solcher Angriff vor sich gehen?
Theoretisch könnte ein Angriff von jedem erfolgen, über dessen System
deine PMs geroutet werden, also jeder Sysop. Nehmen wir als Beispiel
eine fiktive Mailbox und nennen sie "Disneyland" In der Disneyland gibt es
einen User, wir nennen ihn Donald@disneyland, und eine Userin, die
nennen wir Daisy@disneyland. Die beiden tauschen regelmäßig miteinander PMs
aus. In dieser fiktiven Mailbox gibt es auch noch den fiesen Sysop namens
Carlo (Walt Disney möge mir nachsehen, daß ich mir Namen seiner Figuren
geliehen habe). Carlo macht sich einen Spaß daraus, den PM-Verkehr
seiner beiden User "abzuhören", dafür hat er sich extra ein Programm
installiert, das eine Kopie der PMs der beiden, in sein eigenes Postfach legt.
Irgendwann haben die PMs zwischen Donald und Daisy ein so vertrautes
Niveau erreicht, daß die beiden beschließen, PGP zu installieren, jeweils
ein Schlüsselpaar zu erstellen, und diese Schlüssel per PM
auszutauschen. Carlo bekommt das natürlich sofort mit, und reagiert prompt, indem er
selbst auch zwei Schlüsselpaare erstellt, einen mit Donalds Namen, und
einen mit Daisies. Zusätzlich verbessert er sein Watchdog-Programm so,
daß es die PMs nicht mehr kopiert, sondern komplett abfängt. Die public
keys die sich die beiden zuschicken, tauscht er durch seine gefälschten
Schlüssel aus und behält die Originalschlüssel in seinem Keyring. Weder
Donald, noch Daisy erfahren etwas von dieser Tauschaktion, denn sie
erhalten beide einen Schlüssel, der den Namen des anderen trägt, wie
verabredet.
Da haben wir das Problem: ein Schlüssel, den man über das Netz
bekommt, sagt überhaupt nichts, er kann von jedem kommen und muß nicht
zwangsläufig dem gehören, dem er zu gehören scheint. Naiv wie sie sind,
unterschreiben Donald und Daisy aber gegenseitig ihre Schlüssel (die falschen),
und schicken sie sich wieder zu. Kein Problem für Carlo, er besitzt ja
seine Fake-Keys, einschließlich der dazugehörigen secret keys. Er
unterschreibt einfach den für Donald gefälschten Key mit Daisies gefälschtem
Key und schickt ihn an Donald, Daisies gefälschten Key unterschreibt er
mit Donalds gefälschtem Key und schickt ihn an Daisy (klingt kompliziert,
ist es auch, aber wenn man etwas drüber nachdenkt, wird es klarer).
Zur Verdeutlichung:
Donalds echter Key:
pub 512/11111111 1994/04/03 Donald Duck <donald@disneyland>
Daisies echter Key:
pub 512/22222222 1994/04/03 Daisy Duck <daysi@disneyland>
Carlos gefälschte Keys:
pub 512/33333333 1994/04/03 Donald Duck <donald@disneyland>
pub 512/44444444 1994/04/03 Daisy Duck <daysi@disneyland>
Die Keys unterscheiden sich nur anhand der Key-ID, die User-IDs sind
jeweils gleich. Donald schickt also seinen Key (ID: 11...) an Daysy,
Carlo fängt ihn ab und ersetzt ihn durch Key 33..., gleiches gilt für
Daisies echten Key 22..., der wird durch Key 44... ersetzt.
Wenn Daisy den Key 33... unterschreibt, von dem sie glaubt er gehöre
Donald, fängt Carlo diesen Key ab und schickt Donald stattdessen Key
11..., den er mit Key 44... unterschrieben hat, von dem ja Donald glaubt, er
gehöre Daisy.
Wenn Donald den Key 44... unterschreibt, von dem er glaubt er gehöre
Daisy, fängt Carlo diesen Key ab und schickt Daisy stattdessen Key 22...,
den er mit Key 33... unterschrieben hat, von dem ja Daisy glaubt, er
gehöre Donald.
Und wieder sind Donald und Daysy glücklich und zufrieden, denn sie
haben jetzt sogar eine beglaubigte Unterschrift, die ihren Schlüssel ziert.
Sie gehen nun ruhigen Gewissens daran, ihre PMs verschlüsselt
auszutauschen. Kein Problem für Carlos Software, sie empfängt z.B. eine PM von
Donald (die er ja mit Daisies falschem Key verschlüsselt hat),
entschlüsselt sie, kopiert sie in Carlos Postfach, verschlüsselt sie wieder mit
Daisies echtem Key und schickt sie weiter an Daisy, die nun wiederum eine
PM erhält, die so verschlüsselt ist, daß sie sie mit ihrem secret key
entschlüsseln kann, die Welt ist also (für sie) in bester Ordnung. Die
Antwort von Daisy an Donald erleidet das gleiche Schicksal, sie wird
ebenfalls bei Carlo entschlüsselt, kopiert, mit Donalds echtem Schlüssel
verschlüsselt und an Donald weitergeleitet.
Carlo hat seine Angriffs-Software mittlerweile so verfeinert, daß sie
sogar die Nachrichten der beiden auf Fingerprints scannt, und diese
gegebenenfalls auch austauscht! Und wenn sie nicht gestorben sind, dann
tauschen sie noch heute verschlüsselte Nachrichten aus, und sind sicher, daß
niemand ihre PMs lesen kann.
Eine hübsche Geschichte, nicht wahr? Was, du meinst, das sei etwas
weit hergeholt? Das ist es keineswegs. Jeder halbwegs begabte Programmierer
mit knapp überdurchschnittlichen PGP-Kenntnissen ist in der Lage, ein
Scannerprogramm zu schreiben, daß selbsttätig einen PGP-Key in PMs
erkennt, feststellt, ob es ihn schon gefaked hat, ihn gegebenenfalls
austauscht und in der PM ersetzt. Dasselbe Programm ist auch problemlos in der
Lage verschlüsselte Mails zu erkennen, für den Sysop zu entschlüsseln, mit
dem echten Schlüssel des Originalempfängers wieder zu verschlüsseln und
an ihn weiterzuleiten. Selbst Fingerprints in den verschlüsselten Mails
zu fälschen und dem Fake-Schlüssel anzupassen ist eine der leichtesten
Programmierübungen.
Damit jetzt niemand denkt PGP sei unsicher, PGP ist das wahrscheinlich
sicherste Verschlüsselungsprogramm der Welt, wenn man es richtig
bedient und Verantwortungsbewußt damit umgeht. Die einzigen, die in meiner
fiktiven Geschichte fehlerfrei gearbeitet haben, waren PGP, Carlo und seine
Angriffssoftware, die Fehler lagen bei Donald und Daisy. Ein simpler
Telefonanruf hätte gereicht, um Carlo durch Vergleich der Fingerprints auf
die Schliche zu kommen und zumindest festzustellen, daß man nicht den
Key dessen besitzt, den man an der Strippe hat. Der Telefonanruf bietet
zwar auch keine letztendliche Sicherheit, denn auch da gibt es
Angriffsmöglichkeiten, aber dazu müßte der Angreifer schon zwei Datenwege
manipulieren.
Der gravierendste Fehler der beiden war aber, daß sie einen Schlüssel
unterschrieben haben, von dem sie nur geglaubt haben er stamme von dem,
dessen Namen er trägt, ohne es es aber wirklich zu wissen.
[Seitenbeginn] [Zurück zur PGP Seite]
Er kann keine Unterschriften Dritter fälschen. Nehmen wir an, Daisy
und Donald haben einen gemeinsamen Bekannten: Dagobert. Nehmen wir weiter
an, Dagobert hat die neu erstellten Keys von Donald und Daisy
unterschrieben, bevor die beiden ihre Schlüssel tauschen. Dann könnte sich Carlo
zwar auch noch einen Schlüssel mit Dagoberts Namen erstellen und damit
seine Fakes unterschreiben, aber das PGP von Daisy und Dagobert würde
sofort feststellen, daß diese Unterschrift nicht mit dem Schlüssel
übereinstimmt, den es selbst von Dagobert besitzt.
Jede Unterschrift macht einen Schlüssel sicherer gegen Manipulationen
und mit Unterschriften von Usern denen man vertraut, kann man eine
Vertrauenskette (Cryptologie-Jargon: trusted chain) aufbauen, die es uns
erlaubt einen Schlüssel zu benutzen, den wir nur über das Netz bekommen
haben, und nicht vom Inhaber persönlich.
[Seitenbeginn] [Zurück zur PGP Seite]
Tja, damit sind wir am Ende unseres PGP-Einführungskurses. Was hier
zur Sprache kam, war nur das Wesentliche, was man für die Benutzung von
PGP wissen muß. Vieles wurde nicht gesagt, z.B. der interne Aufbau
geheimer und öffentlicher Schlüssel, wie der in PGP integrierte Packalgorithmus
funktioniert und vieles mehr. Das war aber auch nicht Ziel dieses
Kurses, diese Informationen erhält der Interessierte auch aus vielen bereits
existierenden Texten von FTP-Servern oder aus dem Brett
/Z-NETZ/ALT/PGP/ALLGEMEIN.