AMIGA PD 1

home *** CD-ROM | disk | FTP | other *** search

/ AMIGA PD 1 / AMIGA-PD-1.iso / Programme_zum_Heft / Utilities / Workshops / PGP / doc / pgpdoc1.de < prev next >

Wrap

Text File | 1994-03-13 | 87.7 KB | 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 #: 303-444-3885) Ü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 <hmiller@orion.it.luc.edu> 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 <c.creutzig@hun.gun.de> Abel Deuring <a.deuring@bionic.zer.de> [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 <MASTER@random.zer.sub.org> Johanna Wiesmüller <smb4423@rz.uni-sonstwo.de> 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: 303-541-0140 (10:00am - 7:00pm Mountain Time) Internet: prz@acm.org