Amiga MA Magazine 1998 #6/amigamamagazinepolishissue1998.iso/varia/pgp/pgp_docs/doc/pgpdoc1.de

Text File | 1994-12-10 | 90KB | 2,077 lines

                  Phils Pretty Good Software
                         präsentiert:

                             =====
                              PGP
                             =====


                      Pretty Good Privacy
                 Prima Geschützte Privatsphäre
Chiffrierung mit öffentlichen Schlüsseln für die Allgemeinheit



                  --------------------------
                         PGP Handbuch
                      Teil I: Grundlagen
                  --------------------------
                     von Philip Zimmermann
                 Überarbeitet am 14. Juni 1993

                         Übersetzt von
             Christopher Creutzig und Abel Deuring


                       PGP Version 2.3a
                         1. Juli 1993
                         Software von
                       Philip Zimmermann
                             sowie
        Branko Lancester, Hal Finney und Peter Gutmann



Zusammenfassung: PGP verwendet eine System mit öffentlichen
Schlüsseln für die Verschlüsselung von E-Mail und von Dateien.
Es ermöglicht eine sichere Kommunikation zwischen Personen, die
nie direkt getroffen haben müssen. Ein abhörsicherer Kanal für
den Austausch eines Schlüssels ist nicht erforderlich. PGP
bietet viele Möglichkeiten und ist schnell. Es hat eine
ausgefeilte Schlüsselverwaltung, bietet digitale
Unterschriften, komprimiert die unverschlüsselten Daten, und
hat eine ergonomische Oberfläche.


Copyright (c) für Programm und Dokumentation: Philip Zimmermann.
Informationen zur Lizensierung von PGP, Distribution,
Copyrights, Warenzeichen, Gewährleistungen,
Exportbeschränkungen enthält der Abschnitt "Rechtsfragen"
Spendenaufruf
=============


Am 14. September 1993 erhielt die Firma LEMCOM Systems
(ViaCrypt) aus Phoenix, Arizona, eine Vorladung des
Distriktsgerichts von Nordkalifornien. LEMCOM Systems wurde
darin aufgefordert, vor einer "Grand Jury" eine Zeugenaussage
zu machen, und Dokumente herauszugeben, die "ViaCrypt, PGP,
Philip Zimmermann, und jede andere Person oder Institution, die
im Interesse von Philip Zimmermann in der Zeit von 1. Juni 1991
bis heute arbeiteten herauszugeben."

Philip Zimmermann wurde mitgeteilt, daß er der Hauptverdächtige
in einem Ermittlungsverfahren ist, das vom US-Zollamt in San
Jose durchgeführt wird. Ob es weitere Verdächtigte gibt, ist
nicht bekannt. Die entstehenden Kosten für Philip Zimmermann
werden astronomisch sein, unabhängig davon, ob es nun zu eine
Anklage kommt oder nicht.

Falls es zu einem Prozeß kommt, wird dies einer der wichtigsten
Prozesse sein, die in letzter Zeit um Kryptographie, um den
effizienten Schutz des Briefgeheimnisses und um den freien Fluß
von Informationen und Ideen im Cyberspace nach Ende des kalten
Krieges geführt wurden. Dieser Prozeß wird von großer Bedeutung
sein, sowohl für diejenigen von uns, die sich für die Idee des
effektiven Schutzes der Privatsphäre im Kommunikationsbereich
einsetzen, als auch für Philip, dem eine Haftstrafe droht für
seine uneigennützige und erfolgreiche Entwicklung von
"Kryptographie für die Allgemeinheit", auch als PGP bekannt.
Exportbeschränkungen müssen dafür herhalten, die Verfügbarkeit
von effektiver kryptographischer Technologie zu beschneiden:
Der Zoll vertritt die Auffassung, daß die Veröffentlichung
eines kryptographischen Programms im Internet mit seinem Export
gleichzusetzen ist. Philip hat als erster keine Risiken und
Mühen gescheut, wirklich effektive Werkzeuge zu entwickeln, die
unserer Kommunikation den Schutz vor neugierigen Augen geben,
und das in einer politischen Situation, in der dieser Schutz
immer größeren Anfeindungen ausgesetzt ist, in einer Situation,
in der die US-Regierung mit Clipper Chips und Gesetzentwürfen
zum digitalen Telefon auf unsere Sorgen und Befürchtungen
antwortet. [Der Clipper Chip dient der Verschlüsselung von
Daten und Telefongesprächen. Er ist so konstruiert, daß
Regierungsbehörden in der Lage sind, alle clipper-
verschlüsselten Daten zu entschlüsseln. d.Ü.] Die Zeit ist
gekommen, daß wir alle die Last mit Philip teilen.

Philip baut ein Verteidigungsteam auf, um sich auf einen Prozeß
vorzubereiten, und er braucht dazu Ihre Hilfe. Der Prozeß wird
eine teure Angelegenheit werden, und die Zeit läuft schon. Ich
rufe alle, in den USA und anderswo, auf, Philips Verteidigung
zu unterstützen und vielleicht einen bahnbrechenden
Präzedenzfall zu schaffen. Philips Anwalt in Boulder hat einen
Verteidigungsfond eingerichtet. Spenden werden in jeder Form
(Scheck, Zahlungsanweisung, telegrafischer Transfer) und in
jeder Währung angenommen.



Schecks und Zahlungsanweisungen sollten NICHT für Philip
Zimmermann ausgestellt werden, sondern für seinen Anwalt,
Philip Dubois. Seine Adresse ist:

    Philip Dubois
    2305 Broadway
    Boulder, CO USA  80304
    (Phone #: [phone])

Überweisungen können auf folgendes Konto erfolgen:

    Bank: VectraBank
    Routing #: 107004365
    Account #: 0113830
    Account Name: "Philip L. Dubois, Attorney Trust Account"

Falls nach Abschluß des Verfahrens Geld übrig bleibt, wird es
an die SpenderInnen entsprechend ihrem Beitrag zum Fond
anteilig zurückgezahlt.

Sie können anonym spenden, oder auch aber, aber BITTE - spenden
Sie reichlich. Wenn Sie die Ziele, für die PGP steht, und die
Ideen, die seine Entwicklung anregten, bewundern, drücken Sie
Ihre Unterstützung durch einen Beitrag zu diesem Fond aus.

Hugh Miller <[e-mail]>


Anmerkung der Übersetzer: PGP ist ein hoch professionell
geschriebenes Programm, das kostenlos ist. Freeware von
vergleichbarer Qualität und vergleichbarem Verbreitungsgrad ist
sehr selten. Wir möchten deshalb alle NutzerInnen von PGP
auffordern, zu überlegen, was sie für die Registrierung eines
Sharewareprogramms vergleichbarer Qualität zahlen würden, oder
wieviel Geld sie für ein vergleichbares Produkt, das es nur
gegen Geld gibt, zahlen würden. Diesen Betrag sollten sie dann
Philips Anwalt überweisen. (Wobei mehr Geld natürlich auch
nicht falsch ist...)

[Die Anregung für diese "Bemessungsgrundlage" stand irgendwann
mal in /T-NETZ/PGP/ALLGEMEIN. Leider erinnern wir uns nicht
mehr, von wem sie stammt...]

Auslandsüberweisungen sind sehr teuer. Der FoeBuD e.V. (Verein
zur Förderung des beweglichen und unbeweglichen Datenverkehrs,
Bielefeld, Marktstr. 18) hat deshalb ein Spendenkonto zur
Unterstützung von Philip Zimmermann eingerichtet.
Überweisungen, die auf diesem Konto eingehen, werden in
regelmäßigen Abständen auf das oben genannte Konto von Philip
Dubois weitergeleitet. Die Daten des Konto:

FoeBuD e.V.
Sparkasse Bielefeld
Kontonummer 2134187
BLZ 48050161
Vorwort zur deutschen Übersetzung
=================================


PGP ist ein hervorragendes Programm für die Verschlüsselung von
Nachrichten. Richtig eingesetzt, schließt es die Möglichkeit,
per E-Mail oder Diskette versandte Daten zu entschlüsseln,
weitgehend aus. Es ist aber kaum dazu geeignet, Daten auf einem
Computer in komfortabler und zuverlässiger Weise vor fremdem
Zugriff zu schützen. Dies sollte bei der Verwendung von PGP
beachtet werden. Für eine genauere Diskussion dieses Themas sei
auf den zweiten Teil des Handbuchs verwiesen.

Für MSDOS gibt es mittlerweile zwei gute Programme für die
Verschlüsselung von Daten auf Festplatten und Disketten, SFS
und Secure Drive. Secure Drive kommt aus den USA, unterliegt
also den US-Exportrestriktionen. SFS ist z.Zt. noch im Stadium
des Betatests, kann aber bei manchen FTP-Servern und Mailboxen
bezogen werden.



Bei Übersetzungen ist es häufig schwer, zu entscheiden, in
welchem Umfang Fachbegriffe eingedeutscht werden sollten.
Werden zu viele Begriffe übersetzt, kann das Menschen
verwirren, denen die englischen Begriffe vertraut sind.
Umgekehrt kann ein zu wenig eingedeutscher Text für diejenigen
unverständlich bleiben, die die englischen Begriffe nicht
kennen. Wir haben uns für eine recht weitgehende Eindeutschung
entschieden. Um nicht zuviel Verwirrung stiften, folgt eine
Liste der Worte, bei denen wir im Zweifel waren, ob eine
Übersetzung sinnvoll ist:

- batch file              Stapeldatei
- directory               Verzeichnis
- environment variable      Umgebungsvariable
- exit code               Beendigungscode
- file name extension       Namenserweiterung / Suffix
- key ring                Schlüsseldatei
- pass phrase             Mantra
- public key ring          Datei mit öffentlichen Schlüsseln
- private key ring         Datei mit geheimen Schlüsseln


Die Kryptographie hat, wie andere Fachgebiete auch, ihren
eigenen Jargon. Als kleine Lesehilfe soll das folgende Glossar
dienen:

Angriff: Der Versuch, verschlüsselte oder anderweitig nicht
offen zugängliche Daten zu erhalten, d.h., sie ohne
Berechtigung zu lesen oder zu kopieren.

Klartext:Mit Klartext ist im Zusammenhang mit Verschlüsselung
von Computerdaten nicht nur Text im Sinne von "für den Menschen
lesbar" gemeint, sondern alle nicht verschlüsselten Daten. PGP
verschlüsselt einzelne Dateien, so daß "Klartext" in diesem
Handbuch und allgemein bei der Benutzung von PGP als
"unverschlüsselte Datei" gelesen werden kann.

Kryptanalyse: Methoden und Verfahren, um chiffrierte Daten ohne
Kenntnis des Schlüssels zu entschlüsseln.

Kryptographie: Die Lehre von der Verschlüsselung.

Nachricht: Mit "Nachricht" ist im Rahmen dieses Handbuches eine
einzelne - verschlüsselte oder unverschlüsselte - Datei
gemeint.

Hinweis: Die Begriffe "Geheimer Schlüssel" und "privater
Schlüssel" meinen dasselbe.


Wir haben uns Mühe gegeben, Begriffe mit wohldefinierter
Bedeutung für PGP eindeutig zu wählen. Formulierungen wie "10
verlorene Bereiche in 8 Bereichen" (dies verlautbarten ältere
Versionen des MSDOS-Programms CHKDSK) haben sich hoffentlich
nicht eingeschlichen.


Die vorliegende Version der Übersetzung ist eine Betaversion.
Es hat einige Anfragen gegeben, wann wir denn endlich fertig
sein würden, so daß wir den Entschluß faßten, die Übersetzung
trotz einiger Mängel zu veröffentlichen. Dies bedeutet, daß
noch mit ein paar Fehlleistungen zu rechnen ist, daß die
Angleichung der Fachbegriffe an die Übersetzung von
"language.txt" und an die deutschen FAQs (beide von Marc Aurel)
noch nicht restlos gelungen ist, und daß mit einigen
Tippfehlern zu rechnen ist. Kritik, Anregungen, Hinweise auf
Fehler usw. nehmen wir gerne entgegen.


Philip Zimmermann schreibt an einigen Stellen in der ersten
Person. Wir haben diese Form beibehalten. Bei Formulierungen
wie "Aber ich nehme an, daß IDEA besser als DES ist" ist unter
"ich" also Philip Zimmermann zu verstehen. An manchen Stellen
haben wir Philip Zimmermanns originalen Text ergänzt. Diese
Stellen sind durch [eckige Klammern  mit dem Vermerk d.Ü.]
gekennzeichnet.


Danksagungen
------------

Von vielen Leuten bekamen wir Tips und Hilfen für die
Übersetzung. In Bielefeld waren das insbesondere Elke, Gerhard
und Ingo.


------------
Die Arbeit an der Übersetzung hat uns Spaß gemacht, nicht
zuletzt, weil Philip Zimmermanns originaler Text gut lesbar und
sehr informativ ist. Wir hoffen, daß die deutsche Version nicht
zu hohe Qualitätsverluste hat.


Christopher Creutzig <[e-mail]>
Abel Deuring <[e-mail]>

[Ende des Vorworts]
Inhalt
======
Überblick
Warum eigentlich PGP benutzen?
Die Funktionsweise von PGP
PGP installieren
Bedienung von PGP
 Kurzanleitung am Bildschirm
 Verschlüsseln einer Nachricht
 Verschlüsseln einer Nachricht für mehrere EmpfängerInnen
 Unterschreiben einer Nachricht
 Unterschreiben und Verschlüsseln
 Konventionelle Verschlüsselung
 Entschlüsselung und Prüfung der Unterschrift
 Der Umgang mit Schlüsseln
   Einen RSA-Schlüssel generieren
   einen einzelnen Schlüssel in die Schlüsseldatei aufnehmen
   Einen Schlüssel oder eine Benutzer-ID aus der
     Schlüsseldatei entfernen
   Einen Schlüssel in eine eigene Datei kopieren
   Inhaltsangabe der Schlüsseldatei
   Öffentliche Schlüssel vor Manipulation schützen
   Wie untersucht PGP, welche Schlüssel gültig sind?
   Private Schlüssel vor Diebstahl schützen
   Einen Schlüssel zurückziehen
   Ich hab meinen privaten Schlüssel verloren, was jetzt?
PGP für Fortgeschrittene
 Versand von Nachrichten im Radix-64-Format
 Die Umgebungsvariable (environment variable) für das PGP-
   Verzeichnis
 Konfigurierbare Parameter: CONFIG.TXT
Schwachstellen
Vertrauen in Placebos und Wundermedikamente?
PGP zum Nachschlagen
Rechtsfragen
Danksagungen
Über den Autor

Überblick
=========

PGP steht für "Pretty Good(tm) Privacy", zu deutsch etwa "recht
gute Privatsphäre", wobei "Pretty Good" auch als Kurzform von
"Phil's Pretty Good Software" anzusehen ist, von wo das
Programm stammt. Es handelt sich um ein hochsicheres Ver- und
Entschlüsselungsprogramm, das auf sehr vielen verschiedenen
Rechnern existiert, so z.B. (in alphabetischer Reihenfolge) auf
Amiga, Atari, MSDOS, unter Unix, für VAX/VMS etc. PGP gestattet
den Austausch von Nachrichten ohne Verzicht auf Privatsphäre,
Authentifikation und Komfort. Hierbei verstehen wir unter
Privatsphäre, daß eine Nachricht nur von den gewünschten
Adressaten gelesen werden kann, unter Authentifikation, daß
eine Nachricht überprüfbarerweise von der Person stammt, von
der sie zu stammen scheint (elektronische Unterschrift) und
unter Komfort, daß der Anwender sich keine unnötigen Gedanken
darüber machen muß, wo er welche Schlüssel aufbewahrt und
welchen Schlüssel er zum Datenaustausch mit wem benutzt, wie
dies bei herkömmlicher Verschlüsselungssoftware allzuoft der
Fall ist.

Ebenfalls im Gegensatz zu herkömmlicher Verschlüsselungstechnik
werden keine abhörsicheren Kanäle gebraucht, durch die
Schlüssel ausgetauscht werden, da PGP ein System mit
öffentlichen Schlüsseln nutzt. PGP verbindet die Sicherheit von
RSA (ein Algorithmus für Systeme mit öffentlichen Schlüsseln,
der von Rivest, Shamir und Adleman entwickelt wurde und als
sehr sicher gilt) mit der Geschwindigkeit konventioneller (das
heißt ohne öffentliche Schlüssel arbeitender) Kryptographie und
verwendet ein Verfahren zur Generierung von Textprüfsummen
(Message Digest 5), um elektronische Unterschriften zu
erzeugen, komprimiert die Daten vor der Verschlüsselung, ist
benutzerfreundlich, hat eine komfortable Schlüsselverwaltung
und ist portabel. Die Implementierung des RSA-Algorithmus bei
PGP arbeitet schneller als die meisten RSA-Implementierungen in
anderen Programmen. Sie können von Ihrem Heim-PC, der
beispielsweise unter MSDOS läuft, einen Text verschlüsselt an
einen Bekannten senden, der diesen auf seinem Amiga
entschlüsseln kann. Oder Sie senden einen Text an die Uni, den
Sie für wichtig halten und deshalb unterschreiben möchten -
kein Problem, wenn die Uni PGP installiert hat, kann der
Empfänger Ihre Unterschrift auch auf einer Unix-Maschine
prüfen. Und PGP ist schnell. PGP ist das Kryptographiesystem
für die Allgemeinheit.

PGP versendet seine Dateien nicht selbst, sondern beschäftigt
sich ausschließlich mit dem Ver- und Entschlüsseln. Zum
Versenden brauchen Sie weitere Programme. (Die selben wie für
nicht-verschlüsselte Texte.)

Dieses Buch ist in zwei Teile unterteilt: Teil I behandelt
allgemeine Fragen zu PGP und der Bedienung und sollte von allen
Anwendern gelesen werden. Teil II beinhaltet fortgeschrittene
Techniken beim Umgang mit PGP und einige Spezialthemen, die für
den normalen Anwender eher uninteressant sein dürften.



Warum eigentlich PGP benutzen?
==============================

Es schützt die Privatsphäre. Ob Sie nun eine politische
Kampagne planen, über Ihr Einkommen reden oder eine Affäre
geheimhalten wollen, ob Sie über etwas reden wollen, das Ihrer
Einschätzung nach zu Unrecht illegal ist oder ob Sie Daten
speichern, transportieren und versenden müssen, die unter das
Datenschutzgesetz fallen (SysOps, die ihre Userdaten über eine
Telephonleitung transportieren), ob Sie manchmal Nachrichten
schreiben wollen, von denen andere genau wissen sollen, daß sie
von Ihnen stammen oder ob Sie eben dies bei Nachrichten von
anderen prüfen wollen - die meisten Menschen, die E-Mail
nutzen, werden PGP früher oder später verwenden können.

Und wenn Sie sich davor sträuben, Ihre privaten Mails zu
verschlüsseln: Warum verwenden Sie eigentlich Briefumschläge?
Nehmen wir einmal an, es sei die gängige Ansicht, brave Bürger
bräuchten keine Briefumschläge zu verwenden. Wenn nun irgend
jemand aus irgendeinem Grund einen Briefumschlag verwenden
würde (mehrere Blätter, ein Liebesbrief, den die Mutter des
Adressaten nicht lesen soll etc.), dann wäre dies höchst
verdächtig. Glücklicherweise verwenden die meisten Menschen
Briefumschläge, doch bei elektronischen Briefen ist dies
bislang noch nicht der Fall. Dabei sind die elektronischen
Datenwege sehr viel leichter zu überwachen (rein technisch) als
konventionelle Briefpost, und elektronische Nachrichten können
auch sehr schnell auf bestimmte Schlüsselwörter durchsucht
werden. Und: Gehen Sie eigentlich regelmäßig zum AIDS-Test?
Möchten Sie sich auf illegalen Drogenkonsum untersuchen lassen?
Verlangen Sie nicht einen richterlichen Durchsuchungsbefehl,
wenn die Polizei bei Ihnen eine Hausdurchsuchung machen will?
Haben Sie am Ende etwas zu verbergen? Wahrscheinlich sind Sie
ein Drogendealer oder ein Subversiver, wenn Sie Briefumschläge
benutzen.

Was wäre, wenn es der allgemeinen Auffassung entspräche,
rechtschaffene Bürger sollten all ihr Post auf Postkarten
schreiben? Wenn ein braver Mensch auf die Idee käme, sein
Briefgeheimnis durch einen Umschlag zu schützen, wäre das
höchst verdächtig. Sicherheitsbehörden würden vielleicht jeden
Briefumschlag öffnen, um zu kontrollieren, was er verbirgt.
Glücklicherweise leben wir nicht in so einer Welt - die meisten
Menschen verwenden Briefumschläge, so daß ein Briefumschlag
auch nichts Verdächtiges ist. Es wäre schön, wenn alle E-Mail
verschlüsselt würde, ob sie nun verbotene Nachrichten enthält
oder nicht, so daß die Verschlüsselung von E-Mail genauso wenig
verdächtig wird wie Briefumschläge.

Wenn Sicherheitsbehörden das Brief- oder Telefongeheimnis
brechen wollen, müssen sie einigen Aufwand treiben. Sie müssen
den Umschlag unter Wasserdampf öffnen, den Brief lesen und den
Umschlag wieder zukleben. Das Abhören von Telefongesprächen ist
sehr zeitintensiv, und auch eine Transskription kostet Zeit.
Eine so arbeitsintensive Überwachung kann nicht im großen Stil
betrieben werden. Nur in wichtigen Fällen ist so eine
Überwachung durchführbar.

Ein immer größerer Teil unserer Privatkommunikation läuft über
E-Mail. E-Mail läßt sich sehr leicht überwachen. Die Suche nach
verdächtigen Schlüsselworten ist kein Problem. Das kann ganz
einfach routinemäßig, vollautomatisch in großen Maßstab
durchgeführt werden, ohne daß das irgendwie auffällt.
Internationale Kommunkationswege werden auf diese Art von der
NSA abgehört.

Wir werden bald den "Information Superhighway" haben, der unser
Land kreuz und quer mit Glasfaserkabeln überzieht, und die
allgegenwärtigen PCs verbindet. E-Mail wird allgemeiner
Standard werden. Regierungsbehörden werden für die
Verschlüsselung unserer Nachrichten ihre eigene Technologie
empfehlen. Viele Leute mögen dieser Technologie vertrauen. Aber
andere werden es vorziehen, ihre eigene Wahl zu treffen.

Die Gesetzesvorlage 266, die 1991 im US-Senat vorgelegt wurde,
enthält ein paar beunruhigende Regelungen. Wäre der Entwurf
verabschiedet worden, wären die Hersteller von abhörsicherer
Kommunikationstechnik verpflichtet gewesen, in ihre Produkte
"Falltüren" einzubauen, mit deren Hilfe die Regierung sämtliche
Verschlüsselungen hätte knacken können. Im Wortlaut: "Der Senat
ist der Ansicht, daß die Anbieter elektronischer Kommunikation
und die Hersteller elektronischer Kommunikationsgeräte
sicherstellen müssen, daß die Regierung Zugriff auf die
entschlüsselte Sprachübertragung, Daten- und andere
Kommunikation hat, sofern hierfür eine Gesetzesgrundlage
vorhanden ist." Diese Vorlage wurde nach heftigen Protesten von
Bürgerrechtsgruppen und Industrieverbänden zurückgezogen.

1992 legte das FBI dem Kongreß ein Gesetz zum Abhören von
Telefonen vor. Dies Gesetz sollte alle Hersteller von
Kommunikationsgeräten verpflichten, Vorrichtungen in die Geräte
einzubauen, die es jeder FBI-Dienststelle ermöglichen sollten,
elektronische Kommunikation abzuhören. Obwohl auch diese
Vorlage im Kongreß kaum auf Resonanz stieß, wurde sie 1993
erneut vorgelegt.

Besonders besorgniserregend ist ein neuer Vorstoß des Weißen
Hauses, von der NSA jahrelang vorbereitet, und am 16. April
1993 veröffentlicht. Kernstück ist eine von staatlicher Seite
entworfener Verschlüsselungschip namens Clipper, der nach einem
geheimgehaltenen Verfahren arbeitet. Die Regierung fordert die
Kommunikationsindustrie auf, diesen Chip in alle Geräte
einzubauen, die "sichere" Kommunikation ermöglichen sollen, wie
Telefone, Faxgeräte usw. AT&T baut diesen Chip schon jetzt in
abhörsichere Telefone ein. Der Haken bei Clipper: Bei der
Herstellung bekommt jeder Clipperchip seinen individuellen
Schlüssel, und die Regierung erhält Kopien dieser Schlüssel, um
abhören zu können. Aber keine Sorge -- Die Regierung
verspricht, daß diese "Zweitschlüssel" nur ordnungsgemäß
entsprechend den rechtlichen Rahmenbedingungen eingesetzt
werden. Damit der Clipperchip für die Behörden seinen vollen
Nutzen entfalten kann, wäre der nächste logische Schritt ein
Verbot anderer Formen von Kryptographie.

Wenn Privatsphäre zum Gesetzesbruch wird, werden nur
Gesetzesbrecher Privatsphäre genießen. Geheimdienste, Militär,
Drogenkartelle, große Wirtschaftsunternehmen, sie alle haben
gute Kryptographiesysteme. Nur normale Menschen und politische
Basisorganisationen sind davon ausgenommen - waren davon
ausgenommen, denn nun gibt es PGP.

Das ist der Grund, warum PGP geschrieben wurde, und das ist
auch der Grund, warum mensch PGP nutzen sollte.



Die Funktionsweise von PGP
==========================

Das Ganze ist natürlich leichter zu verstehen, wenn Sie bereits
etwas von Verschlüsselungssystemen im Allgemeinen und ,public
key'-Systemen im Besonderen verstehen. Da dies nicht
vorausgesetzt werden kann, nun eine kleine Einführung:

Zunächst sollten einige Begriffe geklärt werden. Nehmen wir
einmal an, ich möchte Ihnen eine Nachricht schreiben, die sonst
niemand lesen können soll. Hierzu kann ich die Nachricht
,verschlüsseln' oder ,kodieren', das heißt ich verändere sie
nach einem hoffnungslos komplizierten System, so daß niemand
etwas damit anfangen kann, ausgenommen Sie, der beabsichtigte
Empfänger der Nachricht. Ich verwende einen Schlüssel, und Sie
müssen diesen Schlüssel ebenfalls benutzen, um die Nachricht zu
entschlüsseln. Zumindest bei herkömmlichen 'single key'-
Systemen.

Daß herkömmliche Systeme einen gemeinsamen Schlüssel zum Ver-
und Entschlüsseln benutzen, bedeutet, daß dieser Schlüssel auf
einem sicheren Weg zwischen Absender und Empfänger ausgetauscht
werden muß. Das kann umständlich sein, und wenn ein sicherer
Weg existiert, um den Schlüssel auszutauschen, warum dann
verschlüsseln?

In Systemen mit öffentlichem Schlüssel ('public key'-Systeme)
gibt es für jeden Teilnehmer ein Schlüsselpaar, einen
öffentlichen und einen geheimen Schlüssel. Was der eine
verschlüsselt hat, kann der andere entschlüsseln. Den
öffentlichen Schlüssel zu kennen, reicht nicht aus, um damit
verschlüsselte Nachrichten lesen zu können. Der geheime
Schlüssel läßt sich nicht aus dem öffentlichen Schlüssel
berechnen. Deshalb kann der öffentliche Schlüssel ohne Bedenken
verbreitet werden (darum heißt er öffentlich), wobei ein sehr
viel geringerer Bedarf an sicheren Transportwegen besteht als
bei herkömmlichen Systemen.

Jeder kann mit dem öffentlichen Schlüssel einer Person eine
Nachricht für diese verschlüsseln, und der Empfänger kann mit
Hilfe seines privaten Schlüssels diese Nachricht lesen. Da
sonst niemand den privaten Schlüssel kennt, kann sonst niemand
die Nachricht lesen. Nicht einmal der Absender kann das.

Weiterhin gibt es die Möglichkeit, eine Nachricht zu
,unterschreiben'. Hierzu kann der Absender einer Nachricht
diese mit seinem privaten Schlüssel kodieren, und jeder
Empfänger kann die Echtheit des Absenders dadurch prüfen, daß
er versucht, die Nachricht mit dessen öffentlichem Schlüssel zu
dekodieren. Gelingt dies, ist die Nachricht mit dem privaten
Schlüssel kodiert, also unterschrieben worden, so daß der
Absender echt ist. Hiermit wird bewiesen, daß die Nachricht
wirklich von xy stammt und daß sie nicht verändert wurde, denn
xy ist der einzige Mensch, der den Schlüssel besitzt, mit dem
die Nachricht kodiert wurde. Die Fälschung einer Nachricht
fällt sofort auf. Umgekehrt kann der Absender einer
unterschriebenen, nicht gefälschten Nachricht seine
Urheberschaft nicht abstreiten.

Diese zwei Schritte können natürlich miteinander kombiniert
werden, um Briefgeheimnis und Authentifikation des Absenders zu
gewährleisten: Die Nachricht wird zunächst mit dem eigenen
privaten Schlüssel kodiert und diese unterschriebene Nachricht
anschließend mit dem öffentlichen Schlüssel des Empfängers
kodiert. Der Empfänger dekodiert die Nachricht zunächst mit
seinem privaten Schlüssel und anschließend mit dem öffentlichen
Schlüssel des Absenders. PGP erledigt dies automatisch.

Da alle bisher bekannten public-key-Algorithmen deutlich
langsamer arbeiten als herkömmliche Verschlüsselungsalgorithmen
(Ein Algorithmus ist eine Rechenvorschrift), bietet es sich an,
die eigentliche Nachricht mit einem guten, schnellen
herkömmlichen System vorzunehmen. PGP generiert für jede
Verschlüsselung hierzu einen zufällig ausgewählten Schlüssel,
der nur ein einziges mal verwendet wird, und verschlüsselt
hiermit die Nachricht. Anschließend wird dieser Einmal-
Schlüssel mit dem öffentlichen Schlüssel des Empfängers kodiert
und in die verschlüsselte Nachricht hineingeschrieben. Der
Empfänger kann nun mit Hilfe seines privaten Schlüssels den
Einmal-Schlüssel wieder herstellen und die gesamte Nachricht
entziffern.

Die öffentlichen Schlüssel werden in sogenannten 'key
certificates' aufbewahrt, die außer dem Schlüssel selbst noch
eine Nutzerkennung (die üblicherweise aus Realnamen und
Netzadresse besteht) und den Vermerk, wann der Schlüssel
erzeugt wurde, enthalten. 'Public key certificates' enthalten
die öffentlichen Schlüssel, während 'secret key certificates'
die privaten Schlüssel beinhalten. Private Schlüssel sind mit
einem Paßwort geschützt, da sie gestohlen werden könnten. PGP
benutzt zwei "Schlüsselbunde", d.h., zwei Dateien, in denen es
Schlüssel speichert. In der einen Datei (pubring.pgp) werden
die öffentlichen Schlüssel gespeichert, in der anderen Datei
(secring.pgp) die privaten Schlüssel.

Weiterhin hat jeder Schlüssel eine Kennung, die aus den letzten
64 Bits des Schlüssels besteht, von denen aber nur die letzten
24 Bit angezeigt werden - z.B. EAA1E9. Normalerweise haben zwei
verschiedene Schlüssel zwei verschiedene Kennungen.

Um Nachrichten zu unterschreiben, nutzt PGP 'message digest',
eine Methode, um aus einer Nachricht eine 128-bit-Zahl zu
erzeugen, die die Nachricht eindeutig genug bestimmt, damit
eine Veränderung oder ein Neuschreiben mit dem Ergebnis eines
gleichen Ergebnisses praktisch unmöglich ist. Diese Zahl wird,
ähnlich wie eine CRC-Checksum (siehe ZModem oder verschiedene
Speichersysteme), dazu verwendet, Veränderungen der Nachricht
zu diagnostizieren. Anschließend wird diese 128-bit-Zahl mit
dem privaten Schlüssel kodiert. Die verschlüsselte Zahl wird
nun zusammen mit der Schlüsselidentifikation und einem Vermerk,
wann die Unterschrift gemacht wurde, an die Nachricht
angehängt. Die Software des Empfängers sucht in der Datei mit
öffentlichen Schlüsseln nach dem Schlüssel des Absenders und
überprüft damit die Unterschrift.

Ebenso entschlüsselt die Software des Empfängers automatisch
ankommende Nachrichten, bei diesen wird an den Anfang der
Nachricht ebenfalls die Schlüsselkennung gesetzt. PGP sucht in
der Datei mit privaten Schlüsseln nach dem passenden Schlüssel
und entschlüsselt automatisch die Nachricht.

Das System von nur zwei Dateien, in denen die privaten bzw.
öffentlichen Schlüssel gespeichert werden, hat den Vorteil,
nicht mehrere Dutzend Dateien mit Schlüsseln auf der Platte
(oder Diskette) haben zu müssen. Ein einzelner Schlüssel läßt
sich immer noch in eine eigene Datei packen, um ihn zu
versenden, damit andere diesen Schlüssel in ihre
Schlüsseldateien aufnehmen können.



PGP installieren
================

Die MSDOS-Version von PGP 2.3[a] ist in einer komprimierten
Archiv-Datei namens PGP23[a].ZIP enthalten. (Künftige Versionen
von PGP werden Namen in der Form "PGPxy-ZIP" haben, wobei xy
für die Versionsnummer x.y steht.) Diese Archivdatei kann mit
dem MSDOS Sharewareprogramm PKUNZIP ausgepackt werden, oder
unter Unix mit "unzip". Zu dem Programmpaket gehört eine Datei
namens README.DOC, die man auf jeden Fall von der Installation
von PGP lesen sollte. README.DOC enthält die aktuellsten
Informationen darüber, was in der jeweiligen Version von PGP
neu ist, und Informationen über die anderen Dateien des
Programmpakets.

Wenn man bereits PGP 1.0 installiert hat, sollte man diese
Version löschen, weil sie von niemandem mehr verwendet wird.
Wer die alte Version trotzdem behalten möchte, sollte die
Programmdatei in pgp1.exe umbenennen, um Namenskonflikte mit
der neuen Version zu vermeiden. [Version 1.0 ist nicht
kompatibel mit Version 2.x. Näheres hierzu steht im zweiten
Teil des Handbuchs d.Ü.]

Für die Installation unter MSDOS wird PGPxx.ZIP einfach in ein
geeignetes Verzeichnis auf der Festplatte kopiert (z.B.
C:\PGP), und mit PKUNZIP ausgepackt. Für eine bequem nutzbare
Installation sollte auch AUTOEXEC.BAT geändert werden. Näheres
hierzu steht an einer anderen Stelle des Handbuches. Dies kann
aber später erfolgen, wenn man ein wenig mit PGP gespielt und
dies Handbuch durchgelesen hat. Der erste Schritt nach der
Installation (und dem Lesen dieses Handbuches) ist die
Generierung eines Schlüssels mit dem Befehl:

    pgp -kg

Die Installation unter Unix und VAX/VMS unterscheidet sich kaum
von der MSDOS-Installation, jedoch muß möglicherweise der
Quellcode neu compiliert werden. Hierfür ist ein Unix-Makefile
dem Quellcode beigefügt.

Genaueres zur Installation steht in der Datei SETUP.DOC. Dort
ist im einzelnen beschrieben, was im PGP-Verzeichnis stehen
muß, was in AUTOEXEC.BAT einzutragen ist, und wie PKUNZIP
benutzt wird.



Bedienung von PGP
=================


Kurzanleitung am Bildschirm
---------------------------

Mit dem Kommando

    pgp -h

(h für help - Hilfe) gibt PGP einen "Kurzüberblick" über die
möglichen Befehle.

Abhängig davon, ob eine Datei namens PGP.HLP vorhanden ist oder
nicht, wird der Befehl unterschiedlich ausgeführt. Ist PGP.HLP
nicht vorhanden, erscheint eine ca. 15 Zeilen umfassende
"Superkurzanleitung" am Bildschirm. Wenn PGP.HLP vorhanden ist,
wird sein Inhalt am Bildschirm angezeigt. Im Text kann mit den
Tasten "Leertaste", "Return" und "b" geblättert werden. Mit "q"
wird das Programm beendet. [Falls die Datei "DE.HLP" vorhanden
ist, und in der Datei "CONFIG.TXT" der Eintrag "language=de"
vorhanden ist, wird der Hilfstext auf deutsch angezeigt.
Details zu "CONFIG.TXT" enthält der zweite Teil des Handbuchs.
d.Ü.]



Verschlüsseln einer Nachricht
-----------------------------

Das Verschlüsseln einer Nachricht mit dem öffentlichen
Schlüssel der EmpfängerIn geschieht mit folgendem Befehl:

    pgp -e textdatei BenutzerIn_ID

Dieser Befehl erzeugt eine Datei namens "textdatei.pgp", die
den verschlüsselten Text enthält. Beispiel:

    pgp -e brief.txt Alice

oder
    pgp -e brief.txt "Alice S"

Im ersten Beispiel durchsucht PGP die Datei mit den
öffentlichen Schlüsseln nach ID, die das Wort "Alice" enthält.
Im zweiten Beispiel wird nach IDs gesucht, die "Alice S"
enthalten. Leerstellen in der ID-Angabe können nur benutzt
werden, wenn die Zeichenkette für die ID in Anführungszeichen
eingeschlossen wird. Bei der Suche wird nicht zwischen Groß-
und Kleinbuchstaben unterschieden. Wenn PGP eine passende ID
findet, wird deren Schlüssel für das Chiffrieren der Datei
"brief.txt" verwendet. Die Datei mit dem verschlüsselten Text
heißt "brief.pgp".

PGP versucht, die Datei mit dem Klartext zu komprimieren, bevor
es die Daten verschlüsselt. Dies erhöht erheblich die Schutz
gegen eine Kryptanalyse. Außerdem ist die verschlüsselte Datei
in der Regel kleiner als die originale Klartextdatei.

Wenn die verschlüsselte Datei per E-Mail versendet werden soll,
kann es sinnvoll sein, sie in druckbaren ASCII-Zeichen im Radix-
64 Format darzustellen. Dies ist möglich durch Hinzufügen der
Option "-a", wie weiter unten beschrieben.



Verschlüsseln einer Nachricht für mehrere EmpfängerInnen
--------------------------------------------------------

Wenn dieselbe Nachricht an mehrere EmpfängerInnen verschickt
werden soll, kann sie so verschlüsselt werden, daß alle
EmpfängerInnen dieselbe verschlüsselte Nachricht entschlüsseln
können. Beim Verschlüsseln kann man hierfür mehrere
BenutzerInnen-IDs angeben. Beispiel:

    pgp -e brief.txt Alice Bob Carol

Die durch dies Kommando erzeugte Datei letter.pgp kann sowohl
von Alice als auch von Bob und Carol entschlüsselt werden. Es
können beliebig viele EmpfängerInnen angegeben werden.



Unterschreiben einer Nachricht
------------------------------

Der folgende Befehl unterschreibt eine Klartextdatei mit dem
geheimen Schlüssel:

    pgp -s textdatei [-u BenutzerIn_ID]

Die [eckigen Klammern] bedeuten eine Eingabe, die nicht
unbedingt erforderlich ist; die Klammern selbst dürften nicht
mit eingegeben werden.

Der obige Befehl erzeugt eine Datei namens "textdatei.pgp".

Beispiel:

pgp -s brief.txt -u Bob

PGP sucht in der Datei "secring.pgp" nach einer ID, in der die
Zeichenfolge "Bob" vorkommt. Groß- und Kleinbuchstaben werden
bei der Suche nicht unterschieden. Wenn PGP einen geheimen
Schlüssel mit passender ID findet, wird dieser Schlüssel für
die Unterschrift verwendet. Die Datei, die den Text mit
Unterschrift enthält, heißt "brief.pgp".

Wird "-u BenutzerIn_ID" nicht angegeben, verwendet PGP den
ersten Schlüssel aus secring.pgp für die Unterschrift. [In der
Regel wird secring.pgp nur einen einzigen geheimen Schlüssel
enthalten, so daß "-u BenutzerIn_ID" nicht angegeben werden
muß. d.Ü.]



Unterschreiben und Verschlüsseln
--------------------------------

Der folgende Befehl unterschreibt zuerst die Klartextdatei mit
dem geheimen Schlüssel der AbsenderIn, und verschlüsselt dann
die Daten mit dem öffentlichen Schlüssel der EmpfängerIn:

    pgp -es textdatei EmpfängerIn_ID [-u BenutzerIn_ID]

Die [eckigen Klammern] bedeuten eine Eingabe, die nicht
unbedingt erforderlich ist; die Klammern selbst dürften nicht
mit eingegeben werden.

Die mit dem obigen Befehl erzeugte Datei, die den
unterschriebenen und anschließend verschlüsselten Text enthält,
erhält den Namen "textdatei.pgp". Der für die Unterschrift
verwendete geheime Schlüssel wird automatisch in "secring.pgp"
mit Hilfe von "BenutzerIn_ID" herausgesucht. Der öffentliche
Schlüssel der EmpfängerIn wird aus "pubring.pgp" herausgesucht.
Wenn EmpfängerIn_ID nicht in der Befehlszeile angegeben wird,
fragt PGP automatisch nach.

Wird "BenutzerIn_ID" nicht angegeben, verwendet PGP den ersten
geheimen Schlüssel aus "secring.pgp" für die Unterschrift.

Wenn die verschlüsselte Datei per E-Mail versendet werden soll,
kann es sinnvoll sein, sie in druckbaren ASCII-Zeichen im Radix-
64 Format darzustellen. Dies ist möglich durch Hinzufügen der
Option "-a", wie weiter unten beschrieben.

Es können mehrere EmpfängerInnen angegeben werden, durch
einfaches Hinzufügen ihrer IDs in der Befehlszeile.



Konventionelle Verschlüsselung
------------------------------

Machmal kann es vorkommen, daß man eine Datei nach der
herkömmlichen Methode mit einem konventionellen Schlüssel
verschlüsseln möchte. Sinnvoll ist das beispielsweise für die
Verschlüsselung einer Archivkopie von Daten, die einfach nur
gespeichert, aber nicht an andere Leute verschickt werden soll.

Der Befehl hierfür lautet:

    pgp -c textdatei

Der Inhalt der Datei mit dem Namen "textdatei" wird
verschlüsselt, und in eine Datei mit dem Namen "textdatei.pgp"
geschrieben. Öffentliche Schlüssel, BenutzerInnen IDs usw
werden nicht verwendet. PGP fragt bei obigen Befehl nach einem
Mantra, mit der die Datei verschlüsselt werden soll. Dieses
Mantra braucht nicht die gleiche zu sein, mit der der geheime
Schlüssel gesichert ist, und SOLLTE auch nicht dieselbe sein.
PGP versucht, die Daten vor der Verschlüsselung zu
komprimieren.

PGP verschlüsselt eine Datei bei mehreren Verschlüsselung
niemals in identischer Form, selbst wenn dasselbe Mantra
verwendet wird.



Entschlüsselung und Prüfung der Unterschrift
--------------------------------------------

Mit folgendem Befehl wird eine verschlüsselte Datei
entschlüsselt, und /oder eine Unterschrift geprüft:

    pgp verschlüsselte_datei [-o klartext_datei]

Die [eckigen Klammern] bedeuten eine Eingabe, die nicht
unbedingt erforderlich ist; die Klammern selbst dürften nicht
mit eingegeben werden.

PGP geht davon aus, daß das Suffix des Namens von
verschlüsselte_datei ".pgp" ist. Der optionale Parameter
"klartext_datei" gibt an, in welcher Datei die entschlüsselten
Daten gespeichert werden sollen. Fehlt diese Angabe, wird der
Name von "verschlüsselte_datei" ohne Suffix für die
Klartextdatei verwendet. Falls verschlüsselte_datei eine
Unterschrift enthält, wird sie automatisch geprüft. Die
BenutzerInnen-ID des/der Unterschreibenden wird am Bildschirm
angezeigt.

PGP bearbeitet "verschlüsselte_datei" vollautomatisch. Die
Datei kann sowohl verschlüsselt sein, als auch nur
unterschrieben - ohne Verschlüsselung -, oder auch
unterschrieben und verschlüsselt. PGP verwendet die in
"verschlüsselte_datei" gespeicherte Schlüssel-ID, um aus der
Datei mit den geheimen Schlüsseln denjenigen herauszusuchen,
für den "verschlüsselte_datei" verschlüsselt wurde. Falls
"verschlüsselte_datei" eine Unterschrift enthält, verwendet PGP
die zusammen mit der Unterschrift gespeicherte Schlüssel-ID, um
aus der Datei mit öffentlichen Schlüsseln denjenigen
herauszusuchen, mit dem die Unterschrift geprüft werden kann.
Falls all diese Schlüssel vorhanden sind, ist während der
Entschlüsselung keine weitere Eingabe erforderlich, ausgenommen
das Mantra, mit dem der geheime Schlüssel gesichert ist.

Falls "verschlüsselte_datei" konventionell verschlüsselt wurde
(also mit der Option "-c"), fragt PGP bei der Entschlüsselung
nach dem Mantra, mit dem die Datei verschlüsselt wurde.



Der Umgang mit Schlüsseln
-------------------------

Schon zu Zeiten von J.Cäsar, als die Kryptographie in den
Kinderschuhen steckte, war der Umgang mit Schlüsseln die
delikateste Angelegenheit der ganzen Geschichte. Einer der
größten Vorteile von PGP ist die hochentwickelte
Schlüsselverwaltung.


Einen RSA-Schlüssel generieren
------------------------------

Um ein Schlüsselpaar zu erzeugen, geben Sie folgenden Befehl
ein:

    pgp -kg

Nach der Eingabe dieses Befehls fragt PGP nach der
Schlüsselgröße. PGP bietet einige mögliche Schlüsselgrößen als
Auswahlmöglichkeiten an, 384 bits ,,für den Hausgebrauch'', 512
bits ,,für normale Anwendungen'' oder 1024 bits ,,für
militärische Sicherheit''. (Die Werte für die Schlüsselgrößen
sind allerdings nur als Anhaltspunkte anzusehen.) Je größer der
Schlüssel ist, desto sicherer ist die Verschlüsselung, aber
auch umso langsamer. Die meisten Anwender verwenden 1024 oder
512 bit.

Dann möchte PGP eine Benutzer-ID haben, das heißt einen Namen,
der angibt, wem der Schlüssel eigentlich gehört. Vorzugsweise
sollte der gesamte Name verwendet werden, da so weniger
Verwechslungsmöglichkeiten entstehen. Eingebürgert hat sich die
Methode, hinter dem Realnamen in eckigen Klammern (<>) eine E-
Mail-Adresse anzugeben, also z.B.:

        Patrick Lenz <[e-mail]>
        Johanna Wiesmüller <[e-mail]>

Sollten Sie keine E-Mail-Adresse haben, verwenden Sie irgend
etwas anderes, was sicherstellt, daß die angegebene ID einmalig
ist, z.B. Ihre Telefonnummer:

        Kai Fliemann <V+49-4711-123456>


Nun fragt PGP Sie nach einem Mantra, mit dem Ihr privater
Schlüssel geschützt werden soll. Hierbei handelt es sich um
eine größere Ausgabe eines Paßwortes, die beliebig lang sein
darf. Ohne dieses Mantra ist Ihr privater Schlüssel praktisch
wertlos. Dieses Mantra dürfen Sie auf keinen Fall vergessen,
sonst haben Sie keine Möglichkeit, wieder an Ihren privaten
Schlüssel zu kommen. Außerdem gilt das Übliche: Nicht
aufschreiben, kein kurzes oder anderweitig leicht zu ratendes
Mantra verwenden (,,Alea iacta est'' wäre viel zu simpel, auch
,,Ich liebe Moni!'' sollte nicht verwendet werden...) und nicht
über ein Netzwerk eintippen. Normalerweise (also außer, die
Konfiguration wurde geändert) erscheint das Mantra nie am
Bildschirm. PGP unterscheidet bei Mantra zwischen Groß- und
Kleinschreibung. Neben Buchstaben kann das Mantra auch Ziffern,
Satzzeichen usw., enthalten.

Um das Schlüsselpaar zu erzeugen, braucht PGP große, wirklich
zufällige Zufallszahlen. Diese werden nun abgeleitet aus den
Zeitabständen zwischen einigen Tastendrücken, um die Sie
gebeten werden. Tippen Sie einfach ein wenig Zufallstext in
ständig wechselnder Geschwindigkeit. PGP sagt Ihnen, wieviel
Sie tippen müssen.

Anschließend können Sie erst einmal Kaffee trinken gehen, die
Schlüsselerzeugung ist ein langsamer Prozeß. Aber sie wird ja
nur einmal ausgeführt...

Die frisch erzeugten Schlüssel kommen in die Dateien mit
öffentlichen bzw. geheimen Schlüsseln. Von dort aus kann der
öffentliche Schlüssel später (mit der Option -kx) in eine
eigene Datei kopiert werden, die Sie dann weitergeben können.
Dann können Ihre Freunde und Bekannten Ihren öffentlichen
Schlüssel in ihre eigene Datei mit öffentlichen Schlüsseln
aufnehmen.

Den privaten Schlüssel sollten Sie natürlich niemals
weitergeben. Auch sollten Sie darauf achten, Ihr Schlüsselpaar
selbst zu erzeugen und keine Schlüssel für Freunde zu
erstellen. Der private Schlüssel sollte nicht auf einem Rechner
liegen, der für andere Benutzer zugänglich ist, auch wenn er
durch ein Paßwort geschützt ist.


einen einzelnen Schlüssel in die Schlüsseldatei aufnehmen
---------------------------------------------------------

Um einen öffentlichen Schlüssel in die Datei mit öffentlichen
Schlüsseln aufzunehmen, benutzen Sie folgenden Aufruf:

        pgp -ka Datei [Schlüsseldatei]

(Die Klammern [] bedeuten, daß die Angabe eines Schlüsselrings
freiwillig ist. Wird keines angegeben, wird pubring.pgp, bzw.
für private Schlüssel secring.pgp verwendet.)

"Datei" ist die Datei, die den neuen Schlüssel enthält,
"Schlüsseldatei" die Datei, die alle öffentlichen Schlüssel
enthält.

Wird pgp mit diese Befehl aufgerufen, dann prüft es zunächst,
ob der Schlüssel schon bekannt ist. In diesem Fall wird er
nicht ein weiteres mal eingebunden, sondern auf neue
Unterschriften und/oder Benutzer-IDs untersucht, die
gegebenenfalls in das Schlüsselfile aufgenommen werden. PGP
durchsucht die komplette Datei und bearbeitet alle darin
enthaltenen Schlüssel auf diese Art und Weise. Was
"unterschriebene Schlüsseln" sind, wird weiter unten erläutert.



Einen Schlüssel oder eine Benutzer-ID aus der Schlüsseldatei
------------------------------------------------------------
entfernen
---------

Der Befehl hierfür lautet

        pgp -kr Benutzer-ID [Schlüsseldatei]

Wird ein Schlüssel gefunden, der zur angegeben ID paßt, fragt
PGP, ob Sie diesen entfernen möchten, bzw. ob Sie ihn ganz
entfernen möchten oder nur die eine oder andere ID, wenn
mehrere vorhanden sind. Geben Sie keine Schlüsseldatei an,
verwendet PGP "pubring.pgp". Sie müssen nicht die vollständige
Benutzer-ID angeben. Es genügt bereits ein kurzer Textauszug
aus der ID, z.B. der Nachname. Dies gilt übrigens für alle
Befehle, bei denen die Benutzer-ID  anzugeben ist, mit Ausnahme
der Eingabe einer neuen ID bei der Schlüsselgenerierung und dem
Ändern der ID ("pgp -kg" und "pgp -ke").



Einen Schlüssel in ein eigenes File kopieren
--------------------------------------------

Um einen Schlüssel in eine eigene Datei zu kopieren (die Sie
beispielsweise weitergeben können), dient der Befehl

        pgp -kx Benutzer-ID [Zieldatei] [Schlüsseldatei]

Wird die Angabe der Zieldatei weggelassen, fragt PGP, wohin Sie
den Schlüssel kopieren möchten. Bei dieser Operation bleibt das
Schlüsselfile vollständig, der Schlüssel wird wiklich nur
kopiert.

Ist der Schlüssel unterschrieben, dann werden die
Unterschriften ebenfalls mit kopiert. Wollen Sie den Schlüssel
in ASCII-Darstellung verschicken (bspw. im Internet, Mausnetz
oder Bitnet oder als "Anhängsel" an eine Textnachricht),
benutzen Sie den Befehl

        pgp -kxa Benutzer-ID [Zieldatei] [Schlüsselfile]


Eine Inhaltsangabe der Schlüsseldatei
-------------------------------------

erhalten Sie mit dem Befehl

        pgp -kv[v] [Benutzer-ID] [Schlüsseldatei]

Geben Sie eine Benutzer-ID an, werden alle Schlüssel
aufgelistet, die den angegebenen Text enthalten, ansonsten alle
Schlüssel, die in der Schlüsseldatei stehen. Geben Sie keine
Schlüsseldatei an, wird pubring.pgp verwendet. Verwenden Sie
die Option -kvv, werden zusätzlich zu den Schlüsseln alle
Unterschriften ausgegeben.



Öffentliche Schlüssel vor Manipulation schützen
-----------------------------------------------

PGP bietet ein Verschlüsselungssystem, das mit öffentlichen
Schlüsseln arbeitet, diese brauchen nicht vor Entdeckung
geschützt zu werden. Im Gegenteil, je weiter sie verbreitet
sind, desto besser. Andererseits ist es sehr wichtig, bei
öffentlichen Schlüsseln sicherzugehen, von wem sie stammen.
Hier liegt wahrscheinlich die größte Schwachstelle eines jeden
Systems mit öffentlichen Schlüsseln. Lassen Sie uns ein kleines
Desaster basteln und anschließend klären, wie derartige
Situationen sich mit PGP vermeiden lassen.

Nehmen wir an, Sie wollen Alice eine eher private Nachricht
schicken. Dazu holen Sie sich aus einer öffentlichen Quelle
Alices öffentlichen Schlüssel, verschlüsseln die Nachricht
damit und senden sie über eine oder mehrere Mailboxen an Alice.

Soweit, so gut, aber leider hat, was keiner wußte, Charlie
einen Weg gefunden, um sich selbst auf dem Weg einzuhängen.
(Das ist nicht weiter schwierig.) Charlie hat eine Möglichkeit,
den gesamten E-Mail-Verkehr von und zu Alice abzufangen, zu
verändern oder einfach mitzulesen. Er ersetzt den von Alice
veröffentlichten Schlüssel durch einen öffentlichen Schlüssel,
den er selbst erzeugt hat. Da dieser Schlüssel natürlich die ID
von Alice trägt, verwenden Sie ihn, Charlie fängt die Nachricht
ab, liest sie und schickt sie dann entweder - mit Alices
wirklichem öffentlichen Schlüssel kodiert - weiter, verändert
sie evtl. zwischendurch, oder unterläßt dies vollständig. Da er
den privaten Schlüssel für den Schlüssel hat, von dem Sie
glauben, er sei Alices, kann er dies tun. Alice erhielt
natürlich ebenfalls einen falschen Schlüssel, als sie Ihren
erhalten wollte, so daß auch das Unterschreiben von Nachrichten
ohne Probleme zu fälschen ist.

Es gibt nur einen Ausweg aus diesem Dilemma: öffentliche
Schlüssel müssen vor derartigen Angriffen geschützt werden.
Wenn Alice Ihnen ihren öffentlichen Schlüssel direkt in die
Hand gedrückt hat, stellt das kein Problem dar, aber wenn Sie
in der Schweiz wohnen und Alice in Norwegen, kann das etwas
problematisch sein.

Vielleicht kennen Sie aber jemanden, dem Sie vertrauen und der
zufällig gerade nach Norwegen in Urlaub fährt... Diesem netten
Menschen könnten Sie dann ja Ihren öffentlichen Schlüssel
mitgeben, und er würde Ihnen den von Alice bringen. Falls Alice
den Menschen nicht zufällig ebenfalls gut kennt, kann sie immer
noch nicht sicher sein, daß der Schlüssel, den sie hat, von
Ihnen ist, aber Sie können relativ sicher sein.

Nun ist es aber relativ unpraktisch, zu allen E-Mail-
Bekanntschaften Freunde hinzuschicken oder selber hinzufahren,
um Schlüssel auszutauschen. Daher bietet PGP die Möglichkeit
an, Schlüssel/Benutzer-Zuordnungen zu unterschreiben. Nehmen
wir an, Sie kennen außer Alice auch noch deren Halbbruder
David. David hat Sie letzten Sommer besucht und bei der
Gelegenheit seinen öffentlichen Schlüssel dagelassen.
Unterschreibt David nun den öffentlichen Schlüssel von Alice,
können Sie - wenn Sie ihm nicht zutrauen, daß er einen falschen
oder zweifelhaften Schlüssel unterschreiben würde - davon
ausgehen, daß der Schlüssel authentisch ist.

David würde also Alices öffentlichen Schlüssel mit Alices ID
unterschreiben, und Alice könnte diesen unterschriebenen
Schlüssel versenden. Charlie kann zwar den Schlüssel abfangen
und durch seinen eigenen ersetzen, er kann aber nicht Davids
Unterschrift unter diesen Schlüssel setzen. Auch wenn er einen
von David signierten Schlüssel hat, den David ihm mit Charlies
echter ID unterschrieben hat, nützt ihm das nichts, da eine
Unterschrift immer eine Zuordnung von ID und Schlüssel
bestätigt.

Es wäre sogar möglich, daß eine weithin bekannte und als
vertrauenswürdig eingestufte Person sich darauf spezialisiert,
derartige Unterschriften zu leisten. [Bei RIPEM ist etwas
derartiges von einer Zentralautorität vorgesehen, wenn ich
nicht irre. d.Ü.] Diese Person könnte also als Keyserver oder
,,Beglaubigungsstelle'' arbeiten. Jeder, der sich an diesem
Konzept beteiligen möchte, braucht nur den öffentlichen
Schlüssel dieser Instanz (der natürlich auf extrem
vertrauenswürdigen Kanälen zu ihm kommen muß) und kann damit
alle Unterschriften überprüfen.

Dieses Konzept ist vor allem für große, zentral gesteuerte
Einrichtungen, wie Betriebe oder staatliche Verwaltungsapparate
interessant. PGP zielt mehr auf ein dezentrales
Beglaubigungssystem, in dem jeder Benutzer die Schlüssel
derjenigen Leute, die er persönlich kennt oder die er auf
Kongressen oder sonstwo trifft (und über deren Identität er
sicher ist), unterschreibt. Das spiegelt eher den natürlichen
Umgang mit Mitmenschen wider und bietet jedem die Möglichkeit,
selbst zu entscheiden, wem er vertraut, wenn es um glaubwürdige
Unterschriften geht.

Auch wenn es unwichtig erscheint: Diese ganze Geschichte ist im
Endeffekt die Achillesverse des ganzen Systems. Für
vertrauliche Nachrichten (und wenn Sie längere Zeit E-Mail
benutzen, werden Sie mit Sicherheit vertrauliche Nachrichten
schreiben) sollten Sie niemals einen Schlüssel verwenden, von
dem Sie nicht sicher sein können, von wem er stammt.

Von der Echtheit eines Schlüssels können Sie überzeugt sein,
wenn Sie ihn direkt von seinem Besitzer bekommen haben, oder
wenn er von einer Person unterschrieben ist, der Sie vertrauen,
und von der Sie einen Schlüssel haben, der mit Sicherheit echt
ist.

Und: Unterschreiben Sie niemals einen Schlüssel, von dem Sie
nicht absolut und 100% sicher sein können, daß er von der
Person stammt, deren ID Sie unterzeichnen. Mit der Unterschrift
bürgen Sie mit Ihrem guten Namen für die Echtheit des
Schlüssels. Unterschreiben Sie keine Schlüssel, weil Sie
jemanden gut kennen, der diese Schlüssel unterschrieben hat,
sondern nur dann, wenn Sie wirklich selber unabhängig sicher
sind und sein können, daß der Schlüssel echt ist. Vorzugsweise
nur Schlüssel, die Sie direkt vom Besitzer erhalten haben.

[Eine weitere Möglichkeit der Echtheitskontrolle ist die
Überprüfung des "Fingerprint" eines Schlüssels. Was es mit dem
Fingerprint auf sich hat, steht im zweiten Teil des Handbuches.
d.Ü.]

Eine Unterschrift unter einen Schlüssel zu setzen, setzt eine
viel größere Sicherheit in punkto Eigentümerschaft voraus als
das Verwenden eines Schlüssels. Weitere Erläuterungen finden
Sie im zweiten Teil dieser Anleitung.

Und denken Sie auch daran, daß eine Unterschrift unter einem
Schlüssel nichts darüber aussagt, wie vertrauenswürdig die
Person ist, deren Schlüssel Sie unterschrieben haben, sondern
daß die Unterschrift nur dafür bürgt, daß dieser Schlüssel
wirklich zu der Person gehört. Einen Schlüssel als echt
anzusehen ist eine Sache, dem Besitzer des Schlüssels zu
vertrauen, eine andere.

Auch ist Vertrauen nicht unbedingt übertragbar: Ich vertraue
einem Freund und bin mir sicher, daß er nicht lügt. Wenn er nun
sicher ist, daß ein Minister nicht lügt, muß ich nicht
notwendigerweise davon ausgehen, daß das stimmt. Wenn ich
Davids Unterschrift unter Alices Schlüssel vertraue, und David
Alices Unterschrift unter Charlies Schlüssel vertraut, brauche
ich noch lange nicht Charlies Schlüssel als echt anzusehen.

Daher ist es sinnvoll, unter seinem eigenen Schlüssel
einigermaßen viele Unterschriften zu sammeln und den so
signierten Schlüssel möglichst öffentlich zu verbreiten. Gute
Methoden zum Verbreiten eines Schlüssels sind z.B.
entsprechende Foren in Computernetzen oder die public keyserver
im Internet. Unterschreiben Sie einen Schlüssel, dann sollten
Sie diesen mit Unterschrift an den Besitzer schicken.

PGP überwacht selbsttätig, welche Schlüssel in Ihrem Bund
ausreichend mit Unterschriften bestätigt sind, die von Leuten
geleistet wurden, die Sie als vertrauenswürdig eingestuft
haben. Alles, was Sie tun müssen ist, PGP mitzuteilen, welche
Leute Sie als vertrauenswürdig einstufen. Haben Sie selbst
diese Schlüssel unterschrieben und somit für Ihr PGP voll
bestätigt, können Sie mit Hilfe einer oder mehrerer
Unterschriften unter einem Schlüssel, den Sie neu kriegen,
diesen direkt als bestätigt einstufen lassen. Wie gesagt
vollautomatisch. Weitere Informationen zum Unterschreiben
fremder Schlüssel finden Sie im nächsten Abschnitt.

Stellen Sie sicher, daß niemand außer Ihnen Zugriff auf Ihr
öffentliches Schlüsselfile hat. PGP berücksichtigt bei der
Überprüfung von Unterschriften, welche öffentlichen Schlüssel
Sie bereits als vertrauenswürdig eingestuft haben. Daher
sollten Sie nicht nur auf Ihren privaten Schlüssel aufpassen,
sondern auch beim Umgang mit Ihrer privaten Sammlung
öffentlicher Schlüssel Vorsicht walten lassen. Das heißt nicht
unbedingt, das File davor zu schützen, daß es gefunden werden
kann, aber auch das kann Sinn machen.

Da der eigene öffentliche Schlüssel als Ausgangspunkt aller
Vertrauensketten derjenige ist, der am besten geschützt sein
muß, bietet PGP die Möglichkeit, diesen mit einer
Sicherheitskopie zu vergleichen, die auf einem
schreibgeschützten Medium (Diskette mit Schreibschutz,
Lochstreifen, CD) gespeichert sein sollte. Für nähere
Informationen, lesen Sie bitte die Beschreibung des Kommandos "-
kc" im zweiten Teil.

PGP geht normalerweise davon aus, daß Sie ihre Schlüssel
sorgsam verwalten und vor herumstreunernden Kindern und
Bösewichten schützen. Wenn jemand an Ihre Schlüsseldateien
herankommt und sie manipulieren kann, wird er aller
Wahrscheinlichkeit nach dasselbe mit dem PGP-Programm tun
können und es so verändern, daß alle Schutzmechanismen
wirkungslos sind.

Eine zugegebenermaßen eher umständliche Methode, die Sammlung
öffentlicher Schlüssel vor Manipulation zu schützen, ist die,
das Schlüsselfile mit dem eigenen (privaten) Schlüssel zu
unterzeichnen. Beispielsweise könnten Sie mit der "-sb" Option
eine abgelöste Unterschrift erzeugen (vgl. Teil 2 des
Handbuchs). Leider müßten Sie dann immer noch eine glaubwürdige
Kopie Ihres eigenen Schlüssels zur Hand haben, um die
Unterschrift prüfen zu können. Dem Schlüssel in der signierten
Datei können Sie nicht vertrauen, da ein Mensch, der diesen
Schlüssel fälscht, ebensogut eine neue Unterschrift erzeugen
kann.


Wie untersucht PGP, welche Schlüssel gültig sind?
-------------------------------------------------

Vor diesem Kapitel lesen Sie bitte das vorige, ,,Öffentliche
Schlüssel vor Manipulation schützen''.

PGP überprüft, welche öffentlichen Schlüssel Ihrer Sammlung als
gültig eingestuft sind. Dazu müssen Sie PGP mitteilen, welchen
Leuten Sie genug Vertrauen entgegenbringen, um ihre
Unterschriften als gültige Verifikationen für neue Schlüssel
einzustufen. Hiervon ausgehend kann PGP neu hinzukommende
Schlüssel direkt auf ihre Gültigkeit hin prüfen. Und natürlich
können Sie selbst auch Schlüssel unterschreiben.

PGP verwendet zwei verschiedene Kriterien, um Schlüssel
einzustufen, bitte bringen Sie sie nicht durcheinander:

 1) Gehört der Schlüssel wirklich zu der in der ID angegebenen
    Person?
 2) Ist diese Person glaubwürdig genug, andere Schlüssel zu
    bestätigen?

Die Antwort auf die erste Frage berechnet PGP, wobei die
Antwort auf die zweite Frage für andere Benutzer zu Rate
gezogen wird. Die Antwort auf die zweite Frage kann PGP nicht
selbständig finden, sondern Sie müssen sie geben. Geben Sie bei
Frage 2 für einige ausgewählte Benutzer als Antwort ,,Ja'' oder
,,Na ja, einigermaßen'', dann kann PGP die Antwort auf Frage 1
für andere Schlüssel finden, die von diesen ausgewählten
Benutzern unterschrieben wurden.

Schlüssel, die von vertrauenswürdigen Personen unterschrieben
wurden, werden von PGP als echt eingestuft. Um als
vertrauenswürdig gelten zu können, muß ein Schlüssel von PGP
als echt angesehen werden, also entweder von Ihnen selbst oder
anderen vertrauenswürdigen Personen signiert sein.

Sie müssen aber nicht allen Leuten gleichweit vertrauen. PGP
bietet die Möglichkeit, verschiedene Stufen des Vertrauens zu
vergeben. Ihre Einstufung einer Person in Bezug auf
Glaubwürdigkeit sollte nicht nur Ihre Einschätzung der
allgemeinen Zuverlässigkeit dieser Person widerspiegeln,
sondern auch Ihre Einschätzung darüber, wie gut die Person das
Prinzip der Unterschriften verstanden hat und wie ernst sie die
damit verbundene Verantwortung nimmt. Sie können einer Person
die Vertrauensstufen ,,ich weiß nicht'', ,,Nein.'', ,,meistens
ja'' oder ,,ja'' geben. Diese Information wird mit dem
Schlüssel zusammen in Ihrer Sammlung gespeichert, aber wenn sie
einen Schlüssel aus Ihrem Schlüsselfile herauskopieren, wird
diese Angabe nicht mitkopiert. Ihre private Meinung geht
schließlich niemanden etwas an, wenn Sie sie nicht ausdrücklich
mitteilen wollen.

Wenn PGP einen Schlüssel auf seine Gültigkeit hin untersucht,
betrachtet es die Vertrauenslevel aller Schlüssel, mit denen
dieser Schlüssel unterschrieben wurde. Sie können einstellen,
wie viele Unterschriften von welcher Glaubwürdigkeit gebraucht
werden, um einen Schlüssel zu bestätigen (vgl. den zweiten Teil
des Handbuches: config.txt, COMPLETES_NEEDED und
MARGINALS_NEEDED). In der Standardeinstellung hält PGP einen
Schlüssel für echt, wenn er von einer mit ,,ja'' eingestellten
Unterschrift geziert wird oder wenn er zwei Unterschriften mit
der Einstellung ,,meistens ja'' trägt.

Der eigene öffentliche Schlüssel gilt als ,,definitionsgemäß''
vertrauenswürdig, seine Unterschrift reicht immer aus, um einen
Schlüssel als echt zu bestätigen. Und sie gilt als
definitionsgemäß echt.

Mit der Zeit werden Sie einige Schlüssel sammeln, die Sie als
mehr oder als weniger vertrauenswürdig einstufen. Andere Leute,
die teilweise dieselben Schlüssel haben werden, werden andere
Einschätzungen vergeben. Und mit der Zeit werden alle Benutzer
ihre Schlüssel mit immer mehr Unterschriften verteilen. Dadurch
ist das so gesponnene Vertrauensnetz auch sehr viel weniger
gefährdet, durch eine doch schwächere Stelle als angenommen zu
zerreißen.

Dieses dezentrale Konzept ist nicht das einzig mögliche. Es
gäbe auch die Möglichkeit, Schlüssel von einer zentralen
Instanz unterschreiben zu lassen, und bei einigen verwandten
Verfahren wird das auch gemacht. (RIPEM, PEM) Dieses Schema
basiert auf einer vorgegeben Hierarchie, in der andere Leute
festlegen, wem Sie zu vertrauen haben. PGP geht den anderen
Weg, bei dem Sie diese Entscheidung selber fällen müssen. PGP
ist für Leute, die ihren Fallschirm selber zusammenlegen.



Private Schlüssel vor Diebstahl schützen
----------------------------------------

Schützen Sie sowohl Ihren privaten Schlüssel als auch Ihr
Mantra sorgfältig. Sollte Ihr privater Schlüssel jemals das
Licht der großen, weiten Welt erblicken oder auch nur mit einem
anderen fremdgehen, dann sollten Sie möglichst schnell
möglichst vielen Leuten davon erzählen, nach Möglichkeit allen,
die den öffentlichen Schlüssel haben. Viel Glück dabei.
Möglichst bevor irgend jemand Unsinn damit anstellt, wie z.B.
Schlüssel damit zu unterschreiben oder in Ihrem Namen auf
Nachrichten zu antworten.

Das Erste, was Sie tun sollten, um Ihren Schlüssel zu schützen
ist, den Schlüssel selbst immer unter Kontrolle zu haben. Das
heißt, Sie sollten ihn nicht auf einem Computer lassen, wo er
dem Zugriff anderer Personen ausgesetzt ist. Wenn Sie keine
Möglichkeit dazu haben, weil sie beispielsweise Ihren gesamten
E-Mail-Verkehr von einer Unix-Maschine im Büro aus abwickeln,
sollten Sie Ihren Schlüssel immer auf einer schreibgeschützten
Diskette mit sich tragen und von da aus arbeiten.
Sicherheitskopie nicht vergessen. Einen privaten Schüssel auf
einem solchen System, insbesondere auf einem vernetzten
Rechner, aufzubewahren, ist nicht gerade sinnvoll. Und Sie
sollten PGP erst recht nicht über ein Netzwerk oder ein Modem
benutzen. Es wäre zu einfach, Ihr Mantra mitzuschneiden.

Und was für Passwörter allgemein gilt. Sie sollten Ihr Mantra
auf gar keinen Fall irgendwo aufschreiben und am Monitor, unter
der Tastatur oder sonst irgendwo an Ihrem Arbeitsplatz, in der
Aktentasche oder wer weiß wo an einem Ort aufbewahren, an den
jeder potentielle Eindringling gelangen kann. Wenn es wirklich
absolut notwendig sein sollte, daß Sie Ihr Mantra irgendwo
niederschreiben, dann tun Sie das bitte so, daß niemand etwas
mit dem Zettel anfangen kann. Schreiben Sie fünfundzwanzig
Zeilen mit Text, der wie das Mantra aussieht, das Sie auch noch
ein klein wenig durcheinanderwürfeln (die ersten sieben Zeichen
rückwärts, dann zwei Zeichen zuviel eingefügt...) Aber das
Sicherste ist immer noch, es einfach im Kopf zu behalten.

Und: Bewahren Sie immer eine Sicherheitskopie Ihres privaten
Schlüssels auf. Wenn Ihre Festplatte einmal den Geist aufgibt
und Sie ohne Ihren secring.pgp dastehen, können Sie die ganze
an Sie geschickte Post nicht mehr lesen.

Hier kommen wir bei einem Problem der dezentralen Methode zur
Schlüsselverifikation an: Da es keine Zentrale gibt, die
Schlüssel bestätigt, gibt es auch keine, die vor unsicher
gewordenen, da möglicherweise in fremde Hände gefallenen,
Schlüsseln warnt. Sie können nur die Meldung, daß Ihr Schlüssel
möglicherweise bekannt wurde, möglichst weit verbreiten und
darauf hoffen, daß diese Nachricht auch bei allen Leuten
ankommt, die davon erfahren sollten.

Sollte der Fall der Fälle eintreten, sollte also sowohl Ihr
privater Schlüssel als auch Ihr Mantra in fremde Hände fallen,
dann müssen Sie ein sogen. "key compromise certificate"
ausstellen. Dies ist eine Urkunde, die besagt, daß Ihr
Schlüssel auf keinen Fall mehr verwendet werden darf. Wenn Sie
eine solche Urkunde ausstellen wollen, rufen Sie PGP mit der
Option -kd und Ihrer eigen Schlüssel-ID auf. PGP macht dann
Ihren öffentlichen Schlüssel unbrauchbar und gibt Ihnen die
Möglichkeit, mit pgp -kxa ID die Urkunde in ein File zu packen,
das Sie an die gesamte Menschheit schicken sollten. Oder
zumindest an den Teil, der Ihren Schlüssel haben könnte. Am
besten schicken Sie Ihren neuen Schlüssel direkt mit. S. auch
das nächste Kapitel.


Einen Schlüssel zurückziehen
----------------------------

Nehmen wir an, Ihr Schlüssel ist mit dem passenden Mantra in
fremde Hände gefallen. Das sollten Sie der ganzen Welt
erzählen. Nicht, um bedauert zu werden, sondern damit niemand
mehr diesem Schlüssel vertraut. Dafür müssen Sie ein "key
compromise certificate", auch bekannt als "key revocation
certificate" ausstellen. Der Befehl hierfür lautet:

pgp -kd Ihre_ID

Diese Urkunde trägt dann auch noch Ihre Unterschrift und kann
wie zuvor der öffentliche Schlüssel verschickt werden.
Natürlich ist der Sicherheitsverlust des Schlüssels nicht der
einzig denkbare Grund dafür, ihn zurückzuziehen. In allen
Fällen ist das Vorgehen dasselbe.


Ich hab meinen privaten Schlüssel verloren, was jetzt?
------------------------------------------------------

Normalerweise lassen sich Schlüssel mit der Option -kd
zurückziehen. Da hierbei aber eine Unterschrift nötig ist, kann
der Befehl nicht mehr aufgerufen werden, wenn der private
Schlüssel verlorengeht.

Also, was dann? Sie können Ihren Schlüssel nicht mehr auf dem
oben genannten Weg zurückziehen, Sie können aber auch keine mit
dem öffentlichen Schlüssel verschlüsselten Nachrichten lesen.
Für zukünftige Versionen von PGP ist geplant, auch in diesem
Fall einen Mechanismus in Gang setzen zu können, der den
Schlüssel mit Hilfe von introducern unbrauchbar macht, aber wir
reden im Moment über jetzt. Und da bleibt Ihnen wohl keine
andere Möglichkeit als die, alle User zu bitten, Ihren
Schlüssel nicht mehr zu verwenden.

Diese Nachricht sollten Sie von denselben Leuten unterschreiben
lassen, die auch Ihren Schlüssel signiert haben.

Die anderen User können dann Ihren Schlüssel mit dem Befehl

pgp -kd Ihre_ID

abschalten. Hierbei wird allerdings kein key revocation
certificate ausgestellt und der Schlüssel kann mit demselben
Befehl auch wieder angeschaltet werden.



PGP für Fortgeschrittene
========================

Das meiste zu diesem Thema steht in Teil II des Handbuch
"Spezielle Themen". Die folgenden Punkte sind aber wichtig
genug, um schon hier angesprochen zu werden.



Versand von Nachrichten im Radix-64-Format
------------------------------------------

In vielen E-Mail-Systemen ist nur der Versand von ASCII-Text
möglich. Binärdaten, wie die von PGP normalerweise erzeugten
verschlüsselten Dateien, können dann nicht versendet werden.
PGP kann deshalb bei Bedarf die verschlüsselten Daten im
Radix-64 Format darstellen, ähnlich dem Privacy-Enhanced-Mail
Format (PEM) im Internet. Radix-64 stellt binäre Daten
ausschließlich unter Verwendung druckbarer 7-Bit-ASCII-Zeichen
dar, so daß eine verschlüsselte Nachricht wie gewöhnlicher E-
Mail-Text verschickt werden kann. Radix-64 ist also eine Art
"Transport-Verpackung", die Schutz vor einer Verstümmelung der
Nachricht auf dem Transportweg bietet. Um Übertragungsfehler
erkennen zu können, wird der Radix-64 Darstellung eine CRC-
Summe hinzugefügt.

Im Radix-64 Format werden jeweils drei 8-Bit-Bytes in vier
druckbaren ASCII-Zeichen dargestellt, so daß die Länge der
Datei um ca. 33 % zunimmt. Das sieht zunächst nach einer
ziemlich großer Aufblähung der Datei aus, berücksichtigt werden
muß aber, daß PGP Klartextdateien häufig um einen größeren
Faktor komprimiert, bevor sie verschlüsselt werden.

Für eine Radix-64 Darstellung der verschlüsselten Datei wird
einfach die Option "a" (für "ASCII") beim Programmaufruf
hinzugefügt:

    pgp -esa brief.txt BenutzerIn_ID

Hier wird brief.txt unterschrieben, komprimiert, verschlüsselt,
und das Ergebnis im Radix-64 Format in eine Datei mit dem Namen
"brief.asc" geschrieben. Diese Datei kann wie gewöhnliche E-
Mail im Internet oder jedem anderen E-Mail-Netzwerk verschickt
werden.

Die Entschlüsselung einer so verschickten Nachricht
unterscheidet sich nicht von der Entschlüsselung einer "*.pgp"
Datei:

    pgp brief

PGP sucht hier zuerst nach einer Datei namens "brief.asc", und
erst danach nach "brief.pgp". PGP erkennt automatisch, daß
"brief.asc" vor der eigentlichen Entschlüsselung erst in
Binärdarstellung umgewandelt werden muß.

Im Internet ist der Versand von Nachricht mit mehr als 50000
Byte normalerweise nicht möglich. Längere Texte müssen in
mehrere Teile gesplittet werden, die einzeln verschickt werden.
Wenn beim Verschlüsseln die Option für Darstellung im Radix-64
Format angegeben wurde, schreibt PGP bei einem langen Text die
verschlüsselten Daten in mehrere Dateien, deren Namen auf
".as1", ".as2", ".as3" usw. enden. Die EmfängerIn einer solchen
Nachricht muß die einzelnen Dateien in der richtigen
Reihenfolge wieder "zusammenkleben", bevor sie von PGP
entschlüsselt werden kann. [Unter MSDOS geht das mit dem Befehl
"copy brief.as1 + brief.as2 + brief.as3 brief.asc" d.Ü.] Bei
der Entschlüsselung ignoriert PGP allen Text aus den
Nachrichtköpfen, der nicht zu den Radix-64-Blöcken gehört.

Möchte man einen öffentlichen Schlüssel im Radix-64-Format
verschicken, kann die Option "a" auch beim Befehl für das
Extrahieren des Schlüssel aus der Datei mit öffentlichen
Schlüsseln angegeben werden. [Befehl "pgp -kxa ..." d.Ü.]

Hat man vergessen, die "a"-Option beim Verschlüsseln einer
Nachricht oder beim Extrahieren eines Schlüssels anzugeben,
kann man die Binärdatei auch nachträglich in das Radix-64-
Format umwandeln, indem man PGP nur mit der Option "a" aufruft,
ohne Angabe der Option für Verschlüsseln oder Unterschreiben:

    pgp -a brief.pgp

[Um keine Mißverständnisse aufkommen zu lassen: Dieses
"Nacharbeiten" MUSS mit der bereits verschlüsselten Datei
erfolgen. also mit "brief.pgp" in obigem Beispiel. FALSCH wäre
die folgende Befehlskombination:

    pgp -es brief.txt BenutzerIn_ID
    pgp -a brief.txt

Der erste Befehl erzeugt eine verschlüsselte Datei "brief.pgp";
der zweite Befehl erzeugt eine Datei "brief.asc" im Radix-64-
Format, jedoch aus der Klartextdatei "brief.txt". Daß
"brief.asc" nicht unmittelbar "für das menschliche Auge lesbar"
ist, bedeutet nicht, daß die Datei verschlüsselt ist! d.Ü.]

Wenn man eine Datei versenden möchte, die zwar unterschrieben,
aber nicht verschlüsselt ist, wandelt PGP normalerweise alle
Daten in das Radix-64-Format. Handelt es sich bei den Daten um
einen Text, ist er folglich nicht unmittelbar lesbar. Für
diesen Fall - "richtiger" Text in ASCII-Darstellung mit
Unterschrift - bietet PGP die Möglichkeit, den Text in seiner
originalen Darstellung zu lassen, und nur die Unterschrift im
Radix-64-Format an den Text anzufügen. EmpfängerInnen einer
solcher Nachricht brauchen also PGP nicht aufzurufen, um den
Text zu lesen. PGP ist hier nur für eine Kontrolle der
Unterschrift erforderlich. Näheres hierzu steht im zweiten Teil
des Handbuchs, bei der Erläuterung der CLEARSIG-Parameters im
Abschnitt über CONFIG.TXT.



Die Umgebungsvariable (environment variable) für das PGP-
---------------------------------------------------------
Verzeichnis
-----------

PGP benötigt beim Ver- und Entschlüsseln mehrere Dateien, unter
anderem die beiden Dateien "pubring.pgp" und "secring.pgp" mit
öffentlichen und geheimen Schlüsseln, "randseed.bin" (enthält
Parameter für den Zufallszahlengenerator), "config.txt"
(Konfigurationsdatei), und "language.txt" (enthält die
Textmeldungen von PGP, u.U. in mehreren Sprachen). Diese
Dateien können (und sollten) in einem eigenen Verzeichnis
stehen, beispielsweise "C:\PGP". Damit PGP diese Dateien auch
dann findet, wenn es aus einem beliebigen anderen Verzeichnis
aufgerufen wird, muß die Umgebungsvariable PGPPATH auf das
Verzeichnis mit den PGP-Dateien gesetzt werden. Unter MSDOS
geschieht das mit dem Befehl:

    SET PGPPATH=C:\PGP

Wenn PGPPATH so gesetzt ist, benutzt PGP die Datei
"C:\PGP\pubring.pgp" als Datei mit den öffentlichen Schlüsseln
(vorausgesetzt, Verzeichnis und Datei existieren). Mit einem
geeigneten Editor kann unter MSDOS der Befehl "SET PGPPATH=.."
in die Datei "AUTOEXEC.BAT" eingetragen werden, so daß PGPPATH
automatisch beim Start des Rechners gesetzt wird. Wenn PGPPATH
nicht definiert ist, sucht PGP die Dateien im aktuellen
Verzeichnis.



Konfigurierbare Parameter: CONFIG.TXT
-------------------------------------

Die Datei "config.txt" enthält eine Reihe von Parametern, mit
denen PGP den individuellen Bedürfnissen angepaßt werden kann.
"config.txt" steht in dem Verzeichnis, das in der
Umgebungsvariablen PGPPATH angegeben ist.

In "config.txt" kann beispielsweise eingestellt werden, in
welchem Verzeichnis PGP temporäre Dateien speichert, in welcher
Sprache PGP seine Meldungen ausgibt, oder wie skeptisch sich
PGP bei der Prüfung von Unterschriften unter öffentliche
Schlüssel verhält.

Näheres über die einstellbaren Parameter steht im zweiten Teil
des Handbuchs.



Schwachstellen
==============

Es gibt keine Sicherheit ohne Schwachstellen. Auch PGP ist
davon nicht ausgenommen und bietet einige Ansatzpunkte, wie der
Schutz umgangen werden könnte. Die wichtigsten, an die Sie
immer denken sollten, sind die, daß Ihr privater Schlüssel
und/oder Ihr geheimes Mantra bekannt werden könnten, daß jemand
öffentliche Schlüssel verfälscht, daß Sie ihre Files nicht
gründlich genug löschen, Viren und trojanische Pferde,
unbefugter Zugriff auf Ihren Rechner, elektromagnetische
Ausstrahlungen, Angriffe anderer Nutzer auf multi-User-
Systemen, Überwachung ihres Datenverkehrs und eventuell auch
Kryptanalyse.

Für eine weitergehende Diskussion ziehen Sie bitte den
Abschnitt Schwachstellen im Teil 2 des PGP-Handbuches zu Rate.



Vertrauen in Placebos und Wundermedikamente?
============================================

Wenn wir ein Verschlüsselungsprogramm betrachten, stellt sich
die Frage: Warum sollte ich diesem Produkt vertrauen? Auch den
Quelltext zu untersuchen, hilft nicht viel weiter, denn die
meisten Menschen kennen sich in den Grundlagen der
Kryptographie nicht genug aus, um die Sicherheit zu beurteilen.
Und selbst wenn, können sie immer noch nicht sicher sein, daß
keine Hintertür eingebaut ist, die sie evtl. übersehen.

In meiner Zeit am College durfte ich eine in dieser Richtung
eine niederschmetternde Erfahrung machen: Ich erfand ein meiner
Meinung nach geniales Verschlüsselungssystem. Es funktionierte
so, daß ein Zufallszahlengenerator Zahlen ausspuckte, die zu
den zu verschlüsselnden Zeichen addiert wurden. Somit wäre eine
Häufigkeitsanalyse des entstehenden Textes ausgeschlossen, was
ein Brechen des Codes unmöglich machen sollte. Einige Jahre
später entdeckte ich eben dieses Schema in einigen
Einführungswerken zur Kryptographie. Die Freude wurde jedoch
schnell getrübt, als ich erkannte, daß es dort als Beispiel für
einen leicht knackbaren Code verwendet wurde. So viel zu diesem
Algorithmus.

Dieses Beispiel zeigt, wie leicht es ist, einer trügerischen
Sicherheit zu verfallen, wenn es um einen neuen
Verschlüsselungsalgorithmus geht. Auch wenn es die meisten
Menschen nicht direkt nachvollziehen können, ist es extrem
schwer, ein Schema zur Verschlüsselung zu entwickeln, das einem
ernstgemeinten und mit entsprechendem Hintergrund
durchgeführten Angriff standhält. Auch viele kommerzielle
Produkte bieten - aufgrund der verwendeten Rechenvorschriften -
keine ernstzunehmende Sicherheit. Gerade in punkto Sicherheit
wird sehr viel minderwertige Ware verkauft.

Stellen Sie sich vor, Sie kaufen ein neues Auto, und eine Woche
später sehen Sie die Aufzeichnung eines Crash-Testes, in dem
die wunderschönen Sicherheitsgurte einfach reißen. Da kann es
besser sein, gar keine Sicherheitsgurte zu haben, da Sie sich
ansonsten in falscher Sicherheit wiegen. Dasselbe gilt für
Software - wenn Sie sich auf schlechte Software verlassen, um
die Vertraulichkeit Ihrer Daten zu gewährleisten, können Sie
eine extrem böse Überraschung erleben. Oder noch schlimmer -
eventuell bemerken Sie nicht einmal, daß Ihre Daten von
Unbefugten gelesen wurden, bis es zu spät ist.

Aber auch die Verwendung bewährter Algorithmen muß keine
Sicherheit bieten, wenn sie nicht konsequent eingesetzt werden.
So empfiehlt beispielsweise die Regierung der USA die
Verwendung des Federal Data Encryption Standard, DES. Zumindest
für kommerzielle Anwendungen - Informationen unter staatlicher
Geheimhaltung dürfen damit nicht verschlüsselt werden... Aber
das ist ein anderes Thema. Bei DES gibt es verschiedene Stufen
von Sicherheit. Die schwächste, von der die Regierung abrät,
ist die sogenannte ECB-Verschlüsselung (Electronic Codebook).
Besser sind Cipher Feedback (CFB) oder auch Cipher Block
Chaining (CBC).

Leider verwenden die meisten kommerziellen Produkte, die DES
benutzen, die ECB-Methode.
In Gesprächen, die ich mit einiger Autoren solcher Software
führte, stellte sich heraus, daß sie nie etwas von CBC oder CFB
gehört haben, nicht einmal von möglichen Schwachstellen des
ECB. Wobei die Programme, auf die Sie sich am wenigsten
verlassen sollten, immer noch die sind, bei denen der
Programmierer verschweigt, wie die Verschlüsselung
funktioniert.

Um fair zu bleiben, muß ich aber betonen, daß diese Produkte
normalerweise nicht von Firmen kommen, die sich auf
Kryptographie spezialisiert haben.

Und falls Sie jetzt immer noch der eingebauten Verschlüsselung
von WordPerfect, Lotus 1-2-3, MS Excel, Symphony, Quattro Pro,
Paradox oder MS Word 2.0 vertrauen - wenden Sie sich an die
Firma AccesData (87 East 600 South, Orem, Utah 84058, USA),
dort können Sie für $158 ein Softwarepaket erhalten, das eben
diese Systeme entschlüsselt. Gekauft wird dies Programm von
Leuten, die ihr Paßwort vergessen haben, und von
Strafverfolgungsbehörden. Der Autor des Programms, Eric
Thompson, sagte übrigens, er habe einige Verzögerungsschleifen
eingebaut, damit das Knacken des Paßwortes nicht so einfach
aussieht, wie es ist. Auch PKZIP-Verschlüsselung ist nach
seiner Aussage einfach zu umgehen.

Verschlüsselungssoftware läßt sich mit Medikamenten
vergleichen. In beiden Fällen kann die Wirksamkeit von größter
Bedeutung sein. Ebenso wie Penicillin sieht man es einer
Verschlüsselungssoftware nicht an, ob sie gut arbeitet. Jeder
kann feststellen, ob sein Textverarbeitungssystem gute Arbeit
leistet, aber woran erkennt der durchschnittliche Anwender, ob
seine kryptographische Software gut verschlüsselte Dateien
liefert? Schlecht verschlüsselte Dateien sehen für einen nicht-
Spezialisten aus wie gut verschlüsselte. Deshalb gibt es auch
so eine Vielzahl schlechter Verschlüsselungssoftware. Von denen
die meisten Programmierer nicht einmal wissen, wie schlecht ihr
Produkt ist. Bei Verschlüsselungsprogrammen gibt es viel
Kurpfuscherei. Aber im Gegensatz zu den Leuten, die
Patentmedizin verhökern, wissen die meisten Programmierer nicht
einmal, daß sie Quacksalberei betreiben. Diese Programmierer
sind meistens trotzdem fähige  Leute, aber die wenigsten haben
aus nur ein einziges wissenschaftliches Buch über Kryptographie
gelesen. Trotzdem glauben sie, sie könnten gute
Verschlüsselungsprogramme schreiben. Und warum auch nicht?
Verschlüsselung scheint zunächst einmal einfach zu
implementieren zu sein. Und die Programme scheinen auch ganz
ordentlich zu arbeiten.

Jeder, der glaubt, er habe ein unknackbares
Verschlüsselungsverfahren entwickelt, ist entweder ein
unglaublich seltenes Genie oder es ist naiv und unerfahren.

Brian Snow, ein hochrangiger Kryptograph der NSA, sagte mir
einmal, er würde keinem Verschlüsselungsalgorithmus über den
Weg trauen, der von jemandem entwickelt sei, der nicht sehr
viel Erfahrung mit dem Knacken von Verschlüsselungen hat. Eine
durchaus sinnvolle Einstellung. Im Bereich der kommerziellen
Softwareentwicklung kenne ich fast niemanden, auf den dies
Kriterium zutrifft. Snow sieht das ähnlich: "Und das macht
unseren Job bei der NSA um einiges einfacher", meinte er.
Gruselige Vorstellung.

Auch die US-Regierung hat Wundermedizin verbreitet. Nach dem
zweiten Weltkrieg verkauften sie beispielsweise Enigma-
Maschinen an Regierungen von Entwicklungsländern, ohne diesen
zu sagen, daß die Verschlüsselung während des Krieges von den
Briten geknackt worden war.

Übrigens wird der Enigma-Algorithmus auch heute noch bei vielen
Unix-Systemen auf der ganzen Welt für die Verschlüsselung von
Dateien verwendet, unter anderem, weil die US-Regierung der
Verwendung besserer Algorithmen gesetzliche Schranken gesetzt
hat. Die US-Regierung hat 1977 sogar versucht, die
Veröffentlichung des RSA-Algorithmus zu verhindern. Auch die
Entwicklung abhörsicherer Telefontechnik für die Allgemeinheit
hat sie verhindert.

In jüngster Zeit macht der Clipper-Chip die Runde, der Standard
für die Verschlüsselung von Telefongesprächen werden soll -
aber unter staatlicher Kontrolle. Der Staat wäre dazu in der
Lage, alle damit verschlüsselten Gespräche, E-Mail-Kontakte und
Files zu lesen.

Die Hauptaufgabe der NSA ist Aufklärung, hauptsächlich durch
das Abhören und Mitlesen von privater Kommunikation (siehe
hierzu James Bamford, The Puzzle Palace). Die NSA hat Unmengen
an Wissen und Technik für das Knacken von Verschlüsselungen
angesammelt. Wenn auch noch die Allgemeinheit keinen Zugang zu
guter Chiffriertechnik hat, wird die Arbeit der NSA um einiges
vereinfacht. Zugleich hat die NSA aber auch die Aufgabe,
Verschlüsselungsalgorithmen zu beurteilen und zu empfehlen.
Hier wird er Bock zum Gärtner gemacht. Die NSA hat die
Verwendung eines vor ihr entworfenen
Verschlüsselungsalgorithmus empfohlen, aber ohne seine
Funktionsweise offenzulegen - weil das geheim bleiben müsse.
Wir sollen einfach so glauben, daß der Algorithmus gut ist, und
ihn verwenden. Dabei weiß jeder Kryptograph, daß ein gut
durchdachtes Verschlüsselungsverfahren in seinen technischen
Details nicht geheim bleiben muß, um sicher zu sein. Nur die
konkreten Schlüssel müssen geheimgehalten werden. Kann
irgendwer mit Sicherheit sagen, daß ein von der NSA
entwickeltes Verfahren wirklich sicher ist? Schwer ist es für
die NSA nicht, ein Verschlüsselungsverfahren zu entwickeln, das
sie allein knacken können, wenn sie niemandem sonst seine
Funktionsweise offenlegen. Vielleicht betreiben die NSA
absichtlich Quacksalberei.

Ich bin von der Sicherheit von PGP nicht so überzeugt, wie
während meines Studiums von der Sicherheit meines "genialen"
Verschlüsselungsverfahrens. Wäre ich von PGP vollkommen
überzeugt, wäre das ein schlechtes Zeichen. Aber ich bin
ziemlich sicher, daß PGP keine ins Auge springenden
Schwachstellen hat. Die Algorithmen, die PGP verwendet, stammen
von zivilen Kryptographen mit sehr gutem Ruf, und sind
eingehend untersucht worden. Selbstverständlich ist der
komplette Sourcecode erhältlich, so daß jeder, der
programmieren kann oder einen  vertrauenswürdigen Bekannten
hat, der dazu in der Lage ist, das System durchleuchten kann.
Der Quellcode ist über Jahre professionell entwickelt worden.
Im übrigen arbeite ich nicht für die NSA. Ich hoffe, daß der
Schritt, Vertrauen in PGP zu gewinnen, nicht zu viel
Überwindung kostet.



PGP zum Nachschlagen
====================

Hier noch einmal eine Kurzaufstellung der Befehle, die PGP
versteht:

User_ID steht für eine eindeutige Identifizierung, z.B. die
E-Mail-Adresse.

Teile, die in eckigen Klammern [] stehen, sind optional, können
also weggelassen werden.

um einen Text für einen Empfänger zu verschlüsseln

    pgp -e textfile User_ID

Um ein File mit dem eigenen privaten Schlüssel zu signieren

    pgp -s file [-u User_ID]

Die Kombination aus beiden: ein File signieren und für einen
Empfänger verschlüsseln:

    pgp -se file User_ID [-u User_ID]

(Mit -u wird die eigene User_ID angegeben) Bei diesen Befehlen
besteht auch die Möglichkeit, mehrere Empfänger anzugeben:

    pgp -se file User_ID1 User_ID2 ... [-u User_ID]

Um eine Datei ohne PGP-Schlüssel, also konventionell zu
verschlüsseln:

    pgp -c file

Um eine mit PGP verschlüsselte Datei zu entschlüsseln und/oder
Signaturen zu überprüfen:

    pgp file [-o Ausgabefile]



Schlüsselverwaltungsbefehle:
----------------------------

Ein eigenes Schlüsselpaar erzeugen:

    pgp -kg

Aus einem file einen neuen Schlüssel zu der eigenen
Schlüsseldatei hinzufügen:

    pgp [-ka] file [Schlüsseldatei]

Aus der Schlüsseldatei einen Key in ein eigenes File kopieren:

    pgp -kx User_ID [File] [Schlüsseldatei]
oder:
    pgp -kxa User_ID [File] [Schlüsseldatei]

Letzteres erzeugt ein File, das auch über 7-bit-Kanäle
verschickt werden kann.

Den Inhalt einer Schlüsseldatei ansehen:

    pgp -kv[v] [User_ID] [Schlüsseldatei]

Den Fingerabdruck eines Schlüssels augeben, um diesen zu
überprüfen:

    pgp -kvc [User_ID] [Schlüsseldatei]

Unterschriften in der Schlüsseldatei überprüfen:

    pgp -kc [User_ID] [Schlüsseldatei]



Rechtsfragen
============

[Hinweis: Der folgende Abschnitt ist - wie der Rest des
Handbuches auch - eine Übersetzung des von Philip Zimmermann
geschriebenen englischen Handbuches. Im Gegensatz zum Rest des
Handbuches, das sprachunabhängig "internationale Gültigkeit"
hat, bezieht sich der folgende Abschnitt im wesentlichen auf
die rechtliche Lage in den USA. Eine deutschsprachige
Ergänzung, die rechtliche Fragen für die BRD, die Schweiz oder
Österreich behandelt, wäre zwar sinnvoll, ist aber z. Zt. nicht
in Sicht. d.Ü.]

Detaillierte Informationen über die Lizensierung von PGP,
Distribution, Copyrights, Patente, Warenzeichen, Garantie,
Exportbeschränkungen enthält der zweite Teil des Handbuchs im
Abschnitt "Rechtsfragen".

PGP verwendet einen Public Key Algorithmus, für den das US-
Patent Nr. 4,405,829 erteilt wurde. Die ausschließlichen
Verwertungsrechte für dieses Patent liegen bei der
kalifornischen Firma Public Key Partners. Die Benutzung von PGP
in den USA kann eine Verletzung dieser Patentrechte darstellen.
Genaueres hierzu steht im zweiten Teil des Handbuchs.

PGP ist "Guerilla"-Freeware, und mich stört es nicht, wenn Sie
es beliebig verbreiten. Bitten Sie mich aber nicht darum, Ihnen
eine Kopie von PGP zu schicken. Sie können sich PGP bei vielen
Mailboxen und FTP-Servern besorgen.



Danksagungen
============

Ich danke den im folgenden genannten Leuten für ihre Mitarbeit
an der Entwicklung von PGP. Wenn ich auch der alleinige Autor
von PGP Version 1.0 bin, so sind große Teile der neueren
Versionen in internationaler Zusammenarbeit entstanden, an der
viele Menschen unter meiner Leitung beteiligt waren.

Branko Lankester, Hal Finney und Peter Gutmann haben sehr viel
Zeit damit verbracht, neue Eigenschaften in  PGP 2.0
einzubauen, und bei der Portierung auf verschiedene Unix-
Varianten. 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.

Übersetzungen von PGP stammen von Jean-Loup Gailly in
Französisch, von Felipe Rodriquez Svensson und Branko Lankester
in den Holländisch, von Miguel Angel Gallardo in Spanisch, von
Hugh Kennedy und Lutz Frank in Deutsch [sie übersetzten
"language.txt". Diese Übersetzung ist schwer aufzutreiben.
Mittlerweile existiert auch eine Übersetzung dieser Datei von
Marc Aurel. d.Ü.], David Vincenzetti in Italienisch, Harry Bush
und Maris Gabalins in Lettisch, von Zygimantas Cepaitis in
Litauisch, von Peter Suchkow und Andrew Chernov in Russisch,
und von Alexander Smishlajev in Esperanto.  Peter Gutmann bot
eine Übersetzung in neuseeländisches Englisch an, aber wir
waren dann doch der Meinung, daß US-Englisch ausreichend ist.

Jean-Loup Gailly, Mark Adler und Richard B. Wales
veröffentlichten die ZIP-Kompressionsroutinen, und erlaubten
ihre Verwendung für PGP. Die MD5 Routinen entwickelte Ron
Rivest, der sie auch für Public Domain Verwendung freigab.
Xuejia Lai und James L. Massey entwickelten an der ETH Zürich
die IDEA-Verschlüsselung. Die Verwendung von IDEA durch PGP
erfolgt mit Genehmigung der Ascom-Tech AG.

Charlie Merritt lehrte mich, wie man professionell Arithmetik
programmiert für große Zahlen, wie sie bei Public Key
Verschlüsselungen üblich sind. Jimmy Upton schrieb eine
schnelle Implementierung des Multiplizieren-Modulo-Algorithmus.
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 vielen,
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. [PGP ist mittlerweile auch für den
Macintosh verfügbar. d.Ü.]

Seit der Veröffentlichung von PGP 2.0 haben mir viele andere
ProgrammierInnen Patches, Bugfixes und Anpassungen für die
Portierung auf andere Computer zugesandt. Es sind zu viele, um
ihnen hier einzeln zu danken.

Die Entwicklung von PGP ist zu einem bemerkenswerten sozialen
Phänomen geworden. Der besondere politische Reiz, der von PGP
ausgeht, hat eine auch heute noch wachsende Zahl freiwilliger
ProgrammierInnen zur gemeinsamen Arbeit angeregt. Wie in dem
Kinderbuch "Stone Soup" beschrieben, wird es für mich immer
schwieriger, durch die dicke Suppe hindurch den Stein auf den
Boden des Topfes zu erkennen, den ich selbst zu Anfang
hineingeworfen habe.



Über den Autor
==============

Philip Zimmermann ist Softwareentwickler mit 19 Jahren
Erfahrung. Er ist spezialisiert auf integrierte
Echtzeitsysteme, Kryptographie und Fragen der Nachrichten-
Authentisierung von Nachrichten, und Datenkommunikation. Er hat
Erfahrungen unter anderem mit dem Entwurf und der
Implementierung von Authentizitätsprüfungssystemen bei Finanz-
Informationsnetzwerken, in der Datensicherheit in Netzwerken,
Protokollen zur Schlüsselverwaltung, Echtzeit-Multitasking-
Systemen, Betriebssystemen und lokalen Netzwerken.

Zimmermann bietet anwenderspezifische Implementierungen von
Kryptographie, von Authentizitätsprüfungen und von Public Key
Systemen an, außerdem allgemeine anwenderspezifische
Entwicklungen. Seine Firmenadresse:


Boulder Software Engineering
3021 Eleventh Street
Boulder, Colorado 80304  USA
Telefon/Fax: [phone] (10:00am - 7:00pm Mountain Time)
Internet:  [e-mail]