Lutz Donnerhacke: Die Comp.security.pgp FAQ

Die Comp.security.pgp FAQ

Übersetzung der Version 1.5

Dies ist die Liste der häufig gestellten Fragen für das Verschlüsselungsprogramm "Pretty Good Privacy" (PGP) von Phillip Zimmermann und anderen. Der englische Originaltext von galactus@stack.nl wird einmal im Monat in allen comp.security.pgp-Newsgruppen veröffentlicht und ist auch im World wide web (www) unter http://www.pgp.net/pgpnet/pgp-faq/ verfügbar.

Siehe "über diese FAQ" für mehr Informationen. Der Abschnitt "Was ist neu" beschreibt Ergänzungen, Änderungen und Löschungen in dieser Version der FAQ.

Inhaltsverzeichnis

Einleitende Fragen
Sehr allgemeine Fragestellungen und Probleme
Sicherheitsfragen
Schlüssel
Signieren von Nachrichten
Schlüssel-Zertifikate
Zurückziehen eines Schlüssels
Öffentliche Schlüsselserver (public key servers)
Fehlfunktionen
1. Wohin sende ich Berichte über Fehlfunktionen?
2. Welche Fehlfunktionen von PGP sind bekannt?
Weiterführende Literatur
Allgemeine Tips
1. Gibt es undokumentierte Einstellungen in PGP?
2. Kann ich PGP in einer Mailbox verwenden?

Einleitende Fragen

Was ist PGP?
Warum sollte ich meine E-Mail verschlüsseln? Ich tue nichts illegales!
Was sind öffentliche und private Schlüssel?
Wieviel kostet PGP?
Ist Kryptographie legal?
Ist PGP legal?
Welche ist die aktuelle Version von PGP?
Gibt es ein Archiv der comp.security.pgp-Gruppen?
Gibt es eine kommerzielle Version von PGP?
Existiert PGP in Form einer Programmbibliothek, so daß ich Programme schreiben kann, die darauf zugreifen?
Auf welchen Plattformen gibt es PGP?
Wo bekomme ich PGP?
Ich will mehr herausfinden!

1.1 Was ist PGP?

PGP ist ein Programm, das Deiner elektronischen Post eine Eigenschaft verleiht, die sie sonst nicht hätte: Vertraulichkeit. Dies wird durch Verschlüsselung Deiner E-Mail erreicht, so daß sie von keiner anderen als der berechtigten Person gelesen werden kann. Im verschlüsselten Zustand sieht die Nachricht aus wie ein bedeutungsloses Durcheinander zufälliger Buchstaben. PGP hat seine Fähigkeit bewiesen, sogar den ausgeklügeltesten Analyseversuchen zu widerstehen. PGP kann auch verwendet werden, um eine digitale Signatur anzubringen, ohne die Nachricht zu verschlüsseln. Diese Funktion wird normalerweise in öffentlichen Newsbeiträgen verwendet, wo Du nicht versteckst, was Du zu sagen hast, sondern vielmehr Anderen erlauben willst, Deine Urheberschaft zu überprüfen. Wenn die digitale Signatur erst einmal erzeugt ist, kann niemand mehr die Nachricht oder die Signatur verändern, ohne daß PGP die Manipulation entdeckt.

Während PGP leicht zu benutzen ist, hat es auch seine Tücken: Du solltest Dich mit den verschiedenen Optionen in PGP gründlich vertraut machen, bevor Du es für den Versand wirklich ernster Nachrichten verwendest. Zum Beispiel würde das Kommando "pgp -sat <dateiname>" eine Nachricht nur unterschreiben, nicht verschlüsseln. Obwohl das Ergebnis aussieht, als sei es verschlüsselt, ist es das in Wirklichkeit nicht. Jeder auf der ganzen Welt könnte den originären Text zurückgewinnen.

1.2 Warum sollte ich meine E-mail verschlüsseln? Ich tue nichts Illegales!

Hindert Dich etwas daran, Deine gesamte Korrespondenz auf der Rückseite einer Postkarte zu erledigen? Aus den gleichen Gründen solltest Du Deine Email verschlüsseln. E-Mail ist tatsächlich weit weniger sicher, als das Postsystem. Im Falle der Briefpost steckst Du zumindest Deinen Brief noch in einen Umschlag, um ihn vor beiläufiger Schnüffelei zu bewahren. Schau Dir einmal den Header-Bereich irgendeiner empfangenen E-mail an und Du wirst sehen, daß sie auf dem Weg zu Dir eine Anzahl von Knotenpunkten durchlaufen hat. Jeder Einzelne dieser Knotenpunkte bietet die Möglichkeit zur Spionage. Verschlüsselung sollte niemals auf illegale Aktivitäten hinauslaufen. Sie ist lediglich dazu gedacht, private Meinungen privat zu vermitteln.

Jemand hat es einmal so ähnlich ausgedrückt:

Verbrechen? Wenn Du kein Politiker bist, kein Grundlagenforscher, Finanzier, Vorstandsvorsitzender, Rechtsanwalt, keine Berühmtheit, kein Freidenker in einer unterdrückenden Gesellschaft oder ein Mensch, der zu viel Spaß hat, und wenn Du keine Email verschickst über Dein privates Sexleben, Deine finanziellen / politischen / rechtlichen / wissenschaftlichen Pläne oder Klatsch, dann vielleicht brauchst Du PGP nicht. Aber erkenne wenigstens, daß Privatsphäre nichts mit Verbrechen zu tun hat, daß sie es ist, die tatsächlich unsere Welt davon abhält, auseinanderzufallen. Davon abgesehen, macht PGP SPAß. Du hattest niemals einen geheimen Decoder-Ring (kleines Kinderspielzeug in amerikanischen Kornflakes-Packungen)? Boo!

1.3 Was sind öffentliche und private Schlüssel?

Bei konventionellen Verschlüsselungsmethoden, müssen Schlüssel auf "anderem" Wege ausgetauscht werden, bei Treffen unter vier Augen oder über vertrauenswürdige Kuriere. Das Problem ist, daß ein sicherer Informationsaustausch schon erfolgen muß, bevor Du einen sicheren Austausch vornehemen kannst! Bei der konventionellen Kryptographie wird entweder der selbe Schlüssel für Ver- und Entschlüsselung benutzt, oder es ist auf einfachem Wege möglich, den einen in den anderen Schlüssel zu konvertieren. Bei der Verschlüsselung mittels "öffentlicher Schlüssel" unterscheiden sich die "Chiffrier-" und "Dechiffrier-Schlüssel", und es ist niemandem möglich, den einen in den anderen umzuwandeln. Darum kann der Chiffrier-Schlüssel öffentlich zugänglich gemacht werden und irgendwo in eine Datenbank geschrieben werden. Jeder, der Dir eine Nachricht senden möchte, würde Deinen Chiffrierschlüssel aus dieser Datenbank oder anderswoher beziehen und seine Nachricht an Dich verschlüsseln. Die Nachricht kann nicht mit dem Chiffrierschlüssel entziffert werden! Daher kann niemand, außer dem dazu berechtigten Empfänger die Nachricht entschlüsseln. Noch nicht einmal die Person, die den Text verschlüsselt hat, kann den Prozeß umkehren. Wenn Du eine Nachricht empfängst, benutzt Du Deinen privaten Dechiffrier-Schlüssel um die Nachricht zu entziffern. Dieser geheime Schlüssel verläßt niemals Deinen Computer. Tatsächlich ist Dein geheimer Schlüssel selbst verschlüsselt um ihn vor jedem, der an Deinem Computer herumschnüffelt, zu schützen.

1.4 Wieviel kostet PGP?

Nichts!

Es sollte dennoch beachtet werden, daß einige Freeware-Versionen von PGP in den USA gegen ein Patent der "Public Key Partners" (PKP) verstoßen. Speziell die MIT- und ViaCrypt-Versionen sind keine ungesetzlichen Programme; solltest Du innerhalb der USA eine andere Version benutzen, tust Du das auf eigenes Risiko. Weitere Informationen bezüglich Patenten siehe unten (1.6). Davon abgesehen sind Freeware-Versionen von PGP nur fur den nicht-kommerziellen Gebrauch kostenlos. Solltest Du PGP in einem kommerziellen Umfeld anwenden (und in den USA oder Kanada wohnen), solltest Du Dir ViaCrypt PGP besorgen. ViaCrypt PGP hat noch andere Vorteile, zu vorderst die beschränkte Lizenz zur Verbreitung in Zweigstellen. Wie Du mit ViaCrypt in Kontakt trittst, steht unten unter Frage 1.9. Solltest Du PGP für kommerzielle Zwecke außerhalb der USA verwenden, solltest Du Dich an die Ascom Systec AG wenden; sie hält das IDEA-Patent und verkauft Lizenzen für die Benutzung der (konventionellen) IDEA-Verschlüsselung in PGP. Kontaktadresse:

Erhard Widmer
Ascom Systec AG
Dep't. CMVV
Gewerbepark
CH-5506 Mägenwil
Switzerland
IDEA@ascom.ch
Tel: ++41 64 56 59 83
FAX: ++4164 56 59 90

1.5 Ist Verschlüsselung legal?

In einem Großteil der zivilisierten Welt ist Verschlüsselung entweder legal, oder sie wird zumindest toleriert. Trotzdem gibt es einige Länder, wo derartige Praktiken Dich vor ein Erschießungskommando bringen können! Mache Dich mit der Gesetzgebung in Deinem eigenen Land vertraut, bevor Du PGP oder irgend eine andere Verschlüsselungssoftware benutzt. Einige der Länder, in denen Verschlüsselung illegal ist, sind Frankreich, der Iran, Rußland und der Irak. Die Rechtslage in vielen Ländern wird im WWW auf http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm dargelegt.

1.6 Ist PGP legal?

Personen, die in den Vereinigten Staaten oder Kanada leben, sollten ergänzend zu den vorher schon gemachten Bemerkungen zur Kryptographie, ein paar zusätzliche Punkte beachten.

Zunächst ist die Frage, ob PGP unter die ITAR-Regelungen fällt oder nicht. ITAR regelt den Export kryptographischer Technologie aus den Vereinigten Staaten. Dies trotz der Tatsache, daß technische Abhandlungen über Verschlüsselungsverfahren seit Jahren schon weltweit verfügbar waren. Jeder kompetente Programmierer wäre fähig gewesen, die Erkenntisse in ein funktionierendes Verschlüsselungsprogramm einfließen zu lassen. Eine Klage der EFF (Electronic Frontier Foundation) gegen die ITAR-Restriktionen könnte zu deren Abschwächung führen und der Erlaubnis, Verschlüsselungstechnologie zu exportieren.

Die Situation in Kanada ist etwas kompliziert; obwohl ITAR hier nicht gilt, respektiert Kanada die US-Exportbeschränkungen. Das bedeutet, der Export von PGP aus Kanada ist ungesetzlich, wenn es vorher aus den USA importiert worden ist.

Außerdem bestand die Ansicht, daß ältere Versionen von PGP (bis Version 2.3a) in den USA die Patentrechte der Public Key Partners (PKP) verletzten. Dies wurde jedoch niemals vor Gericht geklärt und die derzeit gängigen Versionen von PGP sind auf der Basis verschiedener Uebereinkünfte und gültiger Lizenzen entstanden, um den Patentstreit beizulegen. Sogenannte "internationale" und ältere Versionen (vor ViaCrypt 2.4) werden von PKP immernoch als unrechtmässig betrachtet. Wenn Du Dich in den USA befindest, benutzt Du sie auf eigenes Risiko!

1.7 Welche ist die aktuelle Version von PGP?

Im Moment gibt es fünf verschiedene "aktuelle" Versionen von PGP. Alle gehen mehr oder weniger auf eine gemeinsame Urform zurück: PGP 2.3a, der letzten "guerillaware" -Version von PGP. Absprachen, die zum Ziel hatten, PGP zu legalisieren, führten zu den unterschiedlichen Ausführungen. Alle haben im Großen und Ganzen den gleichen Funktionsumfang, und alle arbeiten in der Regel zusammen.

Alle Versionen nach 2.3 erzeugen Formate, die nicht mehr von 2.3 oder älteren Versionen verarbeitet werden können. In den internationalen Versionen gibt es jedoch den Schalter 'legal_kludge=on', der auch das alte Format erzeugen kann.

MIT PGP 5.0

Es gibt zwei veröffentlichte Freeware Version von PGP 5.0: Für Windows'95 und für den Macintosh. Diese Version hat einie Beschränkungen, die über die der bisherigen "offiziellen" Freeware Version 2.6.2 hinausgehen. Beispielsweise:

Keine konventionelle Verschlüsselung.
Kein "sicheres" Überschreiben der Festplatte.

Die Quellen der 5.0 Version gibt es nur in Buchform. Mit internationalen Bemühungen wird momentan dieser Code eingescannt und korrekturgelesen. Die USA Exportgesetze verbieten zwar die Ausfur der elektronischen Form, nicht aber die Ausfuhr der Buchform.

PGP, Inc

verkauft zwei Versionen von PGP:

PGPmail 4.5 für Geschäftsanwendungen (früher Viacrypt PGP Business Edition) und
PGP 5.0 für Privatgebrauch.

Siehe dazu auch Frage 1.9.

PGP 2.6.3i("international")

ist eine PGP-Version, die aus dem illegal exportierten Quellcode von MIT PGP entwickelt worden ist. Im Grundsatz handelt sich um MIT PGP 2.6.2, aber es benutzt die älteren Verschlüsselungsroutinen aus PGP 2.3a; sie arbeiten besser als RSAREF und außerdem unterliegen sie nicht den Beschränkungen der RSAREF-Lizenz. Es enthält außerdem einige Fehlerkorrekturen, die seit dem Erscheinen von MIT PGP 2.6.2 aufgetaucht sind und kleinere Verbesserungen. Für mehr Informationen kannst Du die "internationale PGP-Homepage" heranziehen: http://www.ifi.uio.no/pgp/

PGP 2.6ui ("unofficial international")

ist PGP 2.3a mit einigen kleineren Veränderungen, die es erlauben, Dateien zu entschlüsseln, die mit MIT PGP verschlüsselt worden sind. Es enthält keine der MIT-Neuerungen und -Verbesserungen. Allerdings besitzt es andere neue Eigenschaften, besonders in der Macintosh - Version.

PGP 2.6.3(i)n

ist die Version der Zertifizierungsinstanz des Individual Network e.V.. Sie unterstützt die in der pgformat.doc beschriebenen Fähigkeiten:

Verfall von Schlüsseln
Rückruf von Schlüsselsignaturen und Nutzerkennungen
Angabe der Qualität der Identitäsprüfung bei Schlüsselsignaturen

Es wurden nervige Fehler von PGP behoben:

Schlüsselunterschriften zurückgezogender Schlüssel sind jetzt ungültig

Neue Fähigkeiten wurden hinzugefügt:

Es wird zwischen Unterschriften- und Verschlüsselungsschlüssel unterschieden.
Unterstützung einer seperaten "Encrypt To Self Id"

1.8 Gibt es ein Archiv der comp.security.pgp -Gruppen?

Eigentlich nicht. Natürlich kannst Du es mit Dejanews (http://www.dejanews.com/) oder Alta Vista (http:/altavista.digital.com/) versuchen, wenn Du Artikel über ein spezielles Thema suchst.

1.9 Gibt es eine kommerzielle Version von PGP?

Ja. Bis vor kurzem vermarktete ViaCrypt die einzige kommerzielle, lizensierte Version von PGP. Die Firma wurde von PGP Inc., einer Gründung Phil Zimmermanns, aufgekauft. Diese Firma verkauft zwei Versionen: PGPmail 4.5 für Geschäftsanwendungen und PGP 5.0 für Privatgebrauch. Es ist unklar, ob die Lizenzen von RSA für ViaCrypt immer noch gelten.

Die PGP 5.0 FAQ diskutiert das aufühlicher.

PGPmail 4.5 ist der Nachfolger von ViaCrypts Business Edition (BE). Zusätzlich zu den Features der Freeware-Versionen bietet dieses Produkt die Installation eines "Corporate Access Key" (eines firmeninternen Generalschlüssels) zu, so daß die Firma Zugriff auf alle verschlüsselten Nachrichten nehmen kann, wenn mal ein privater Schlüssel verlorengeht. Darüberhinaus gibt es einen Enclyptor, der eine Komandoleiste in E-Mail- und Textverarbeitungsprogramme hinzufügt. Weitere Informationen finden sich unter http://www.pgp.com/products/PGPmail-faq.cgi

(Beachte: Die "Corporate Access Key" Funktion von PGPmail 4.5 stellt keine Hintertür zu PGP dar. Die Freeware Versionen haben diese Funktionalität nicht. Auch schwächt diese Funktion nicht die eigentliche Verschlüsselung, sie bietet nur der Firma Zugriff auf die Daten ihrer Mitarbeiter, so diese ihren privaten Schlüssel verloren oder das Mantra vergessen haben.)

1.10 Ist PGP in Form einer Programmbibliothek verfügbar, so daß ich Programme schreiben kann, die darauf zugreifen?

PGP 3.0 wird, wenn es fertig ist, diese Anforderungen voraussichtlich erfüllen. Das PGP-Entwicklungsteam hat sogar eine vorläufige Anwendungsschnittstelle für diese Bibliothek herausgegeben; Du bekommst sie von ftp://ftp.pgp.net/pub/pgp/doc/950212_pgp3spec.txt.gz

Das Entwicklerteam hat klargestellt, daß dies kein endgültiges Exemplar ist; Einiges daran ist bereits veraltet. Dennoch ist es geeignet, sich einen Überblick zu verschaffen. Sende Kommentare an pgp@lsd.com.

Es gibt eine PGP Bibliothek in einem frühen Entwicklungsstadium: ftp://dslab1.cs.uit.no/pub/PGPlib-0.1.tar.gz.

Alternativ kannst Du Deine Programme so schreiben, daß Du PGP aufrufst, wenn es notwendig ist. In C würdest Du bspw. system() oder spawn..() verwenden.

Einige Leute arbeiten an einer DLL-Version (häufig für Windows 3.1 oder NT) von PGP, aber ich habe keinerlei Informationen über den Status dieser Versionen. PGP Inc. (früher ViaCrypt, siehe Frage 1.9) verkauft eine MS Windows DLL, die alternativ verwendet werden kann.

1.11 Mit welchen Betriebssystemen arbeitet PGP?

PGP wurde erfolgreich auf verschiedene Plattformen portiert, darunter DOS, Macintosh, OS/2, Unix (fast alle Geschmacksrichtungen), VMS, Atari ST, Acorn RISC OS (Archimedes) und den Commodore Amiga. Ein Windows NT-Kompilat ist angeblich ebenfalls in Arbeit. Wenn Deine bevorzugte Plattform hier nicht aufgeführt wird, nicht verzweifeln! Es dürfte wahrscheinlich nicht allzu schwierig sein, PGP auf Dein Betriebssystem zu übertragen, wenn man bedenkt, was in dieser Hinsicht schon geleistet worden ist. Frage einfach herum, ob es vielleicht schon eine Version gibt, und wenn nicht, versuche es!

Die VMS-Version von PGP hat übrigens ihre eigene Web-Seite: http://www.tditx.com/~d_north/pgp.html

1.12 Wo bekomme ich PGP?

PGP ist sehr weit verbreitet, so sehr, daß eine eigene FAQ geschrieben worden ist, um diese Frage zu beantworten. Sie heißt:"Where To Get The Pretty Good Privacy Program (PGP)"; sie wird regelmäßig in alt.security.pgp veröffentlicht, steht in den verschiedenen FAQ-Archiven und kann auch von ftp://ftp.csn.net/mpj/getpgp.asc bezogen werden.

Trotzdem werde ich beschreiben, wie man an die verschiedenen Versionen von PGP herankommt. Greife bitte auf das erwähnte Dokument zurück, um an mehr Informationen zu gelangen.

MIT PGP

Wegen der ITAR-Regeln hielt es MIT für notwendig, PGP in einem export-kontrollierten Verzeichnis unterzubringen, um Menschen außerhalb der USA daran zu hindern, die Dateien herunterzuladen.

Wenn Du Dich innerhalb der USA befindest, folge diesen Hinweisen: Telnetverbindung nach net-dist.mit.edu und log-in mit "getpgp". Du wirst eine kurze Erläuterung zur der Regulierung im Export kryptographischer Software erhalten, dann mußt Du eine Reihe von JA/NEIN - Fragen beantworten. Wenn Du korrekt auf alle Fragen antwortest (Es sind größtenteils Einverständniserklärungen bezüglich der RSADSI- und MIT-Lizenzen und Fragen nach möglicher Exportabsicht); man wird Dir einen speziellen Verzeichnisnamen nennen, in dem Du den PGP-Code findest. Jetzt kannst Du die FTP-Verbindung zu net-dist.mit.edu herstellen, in das besagte Verzeichnis wechseln und die Software herunterladen. Der Zugang zu den Verzeichnissen kann Dir verwehrt werden, obwohl Du alle Fragen korrekt beantwortet hast, wenn der MIT-Server nicht bestätigen kann, daß Dein Rechner sich in der Tat in den USA befindet.

Weitere Hinweise, Formulierungen der MIT und RSAREF-Lizenzen, Bemerkungen und die volle Dokumentation sind frei erhälltlich auf ftp://net-dist.mit.edu/pub/PGP/

Ein einfacherer Weg an die PGP-Software zu gelangen, ist die folgende Adresse: http://bs.mit.edu:8001/pgp-form.html

PGPmail und PGP 5.0

Die Freeware Version gibt es beim MIT (siehe oben). Die anderen Versionen sind kommerzielle Software, die von PGP Inc. gekauft werden müssen. Abgesehen davon sind sie außerhalb der USA oder Kanadas nur unter bestimmten Umständen erhältlich (Kontaktadressen siehe oben, Frage 1.9).

PGP 2.6.3i

Weil Norwegen nicht den ITAR-Beschränkungen unterliegt, sind keinerlei Verrenkungen nötig, um an diese Version zu kommen: http://www.ifi.uio.no/pgp/

Du kannst es auch über E-Mail beziehen,indem Du eine E-mail an hypnotech-request@fi.uio.no schickst, mit Deiner Bitte im Subject-Header: GET pgp262i(s).(zip|tar.gz). Wähle den Buchstaben "s", wenn Du den Quellcode haben willst. Mit "zip" am Ende erhälst Du die Dateien im PKZIP/Info-ZIP Archiv-Format, "tar.gz" dagegen bedeutet gzipped tar file. Eine US-kompilierte Fassung von 2.6.3i (was bedeutet, daß der MPILIB RSA-Alrgorithmus nicht benutzt wird, und amerikanische Patente nicht berührt werden) kann von http://www.isc.rit.edu/~pdw5973/downinst.html. bezogen werden.

PGP 2.6ui:

ftp://ftp.mantis.com.uk/pub/cryptography/
http://www.mantis.co.uk/pgp/pgp.html: Dieser Link ist auch eine exzellente Quelle zusätzlicher Informationen über PGP.

PGP 2.6.3(i)n:

ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/pgp/

Bemerkungen über Ftpmail: Leute ohne Zugang zu FTP, jedoch mit E-Mail-Anschluß können FTP-Dateien zugeschickt bekommen. Um Informationen über diesen Dienst zu erhalten, mußt Du "Help" als Nachricht an ftpmail@ftpmail.ramona.vix.com. senden. Man wird Dir eine Anleitung zuschicken.

1.13 Ich will noch mehr wissen!

Sollte diese FAQ Deine Fragen nicht beantworten, gibt es viele Stellen mit Informationen über PGP.

World Wide Web:

http://sun1.bham.ac.uk/N.M.Queen/pgp.html: ein guter Startpunkt, enthält Links zum Herunterladen von PGP.
http://www.stack.nl/~galactus/remailers/bg2pgp.txt: Obwohl die Dokumentation im Lieferumfang von PGP bereits sehr umfassend ist, willst Du vielleicht diese Anleitung lesen. Sie befaßt sich mit den grundlegenden Schritten der Installation und des Gebrauchs von PGP und enthält Tips zur effektiveren Nutzung.
http://www.stack.nl/~galactus/remailers/passphrase-faq.html: Dein Paßphrase (auch: Mantra) wird benutzt, um Deinen geheimen PGP-Schlüssel zu schützen. Hier steht, wie man sichere Paßphrases generiert und handhabt. Das kann auch bei Paßwörtern für andere Zwecke nützlich sein.
http://www.stack.nl/~galactus/remailers/attack-faq.html: Eine sehr detaillierte Analyse der Sicherheit von PGP und möglicher Angriffsszenarien.

FTP-Ressourcen:

ftp://ftp.pgp.net/pub/pgp/
ftp://ftp.ox.ac.uk/pub/crypto/
ftp://ripem.msu.edu/pub/crypt/
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/

Siehe auch Teil 10, "Weiterführende Literatur".

Sehr allgemeine Fragestellungen und Probleme

Warum kann jemand, die Version 2.3 verwendet, meine Version 2.6-Nachrichten nicht lesen?
Wieso beklagt sich PGP so oft über Signaturen?
Wieso dauert das Verschlüsseln und Entschlüsseln von Nachrichten so lange?
Wie erstelle ich eine zweite Schlüsseldatei?
Wie geht PGP mit mehreren Adressen um?
Wo bekomme ich Skripte, die PGP in meine Email- oder News-Programme einbinden?
Wie entschlüssele ich Nachrichten, die ich für Andere verschlüsselt habe?
Warum kann ich mit PGP unter Unix keinen Schlüssel generieren?
Wenn ich ein Dokument mit einer "Klartextunterschrift" versehe, stellt PGP einigen meiner Zeilen Bindestriche voran. Wozu ist das gut?
Wie verschlüssele ich mehrere Dateien auf einmal?
Wie übergebe ich meinen Paßphrase automatisch an PGP?
Kann es sein, daß "randseed.bin" von einem Virus infiziert wird?
Wieso findet MacPGP meinen privaten Schlüssel nicht?
Wie setze ich die TZ-Variable?
Wie erkenne ich, ob das PGP-Kommando korrekt ausgeführt worden ist?
Warum fragt PGP 5.0 nicht mehr nach zufälligen Tastendrücken?
Sind PGP 5.0/5.5 und PGP 2.6.x kompatibel?

2.1 Warum kann jemand, die Version 2.3 verwendet, meine Version 2.6-Nachrichten nicht lesen?

Du benutzt wahrscheinlich MIT PGP, oder vielleicht eine andere PGP-Version mit ausgeschalteter "legal_kludge"-Option. Als Teil der Einverständniserklärung, die die Patentstreitigkeiten beilegen sollte, hat MIT PGP das Format etwas abgeändert, um es PGP 2.4 und älteren Versionen unmöglich zu machen, Nachrichten zu entschlüsseln, die mit MIT PGP verschlüsselt wurden. Diese Änderung wurde in MIT PGP so geschrieben, das sie am 1. September 1994 in Kraft trat. Aufgrund dessen können mit MIT PGP verschlüsselte Nachrichten nicht mehr von 2.4 (und früheren Versionen) gelesen werden. Das Ziel war, daß Leute, die 2.4 und frühere Versionen benutzten, gezwungen wurden, aufzurüsten und somit die patentrechtlich zweifelhafte Version nicht mehr benutzt würde.

Der beste Ausweg ist, auf eine neuere Version aufzurüsten. Wenn Du eine andere Version als MIT PGP benutzt, suche die "legal_kludge"-Option in Deiner Dokumentation: Du solltest in der Lage sein, Deine Ausführung von PGP so zu konfigurieren, daß Nachrichten "im alten Stil" erzeugt werden. In 2.6.2i und 2.6.3i geht das, indem die Zeile "Legal_Kludge=off" in Deiner config.txt-Datei für PGP eingefügt wird. Beachte, daß "alte" Chiffretexte von den neueren Versionen korrekt gelesen werden können, so daß Du in Korrespondenz mit MIT und 2.3-Benutzern bei ausgeschalteter "Legal_Kludge-" Option am Besten dran bist.

2.2 Wieso beklagt sich PGP so oft über Signaturen?

Version 2.3a führte die "pkcs-compat-" Option ein, die es erlaubte, die Signaturen leicht zu modifizieren, um sie an Industrie-Standards anzupassen. MIT PGP versteht aufgrund der benutzten RSAREF-Bibliothek das alte Signaturformat nicht, ignoriert die Signaturen und gibt eine entsprechende Meldung aus. Das Problem taucht meistens im Zusammenhang mit älteren Schlüsselzertifikaten auf. Sollte Dein Schlüssel solche Signaturen enthalten, bringe die Leute, die Deinen Schlüssel unterschrieben haben dazu, das Gleiche mit einer neuen Version von PGP zu wiederholen. Sollte es trotzdem extrem wichtig sein, ein altes Zertifikat zu überprüfen, besorge Dir eine Version von PGP, die RSA anstelle von RSAREF benutzt, z.B. ViaCrypt.

2.3 Wieso dauert das Verschlüsseln und Entschlüsseln von Nachrichten so lange?

Das Problem kann entstehen, wenn Du sämtliche Schlüssel eines Key-Servers in der Datei pubring.pgp untergebracht hast. PGP muß dann wohl unter einigen Tausenden nach dem gewünschten Schlüssel suchen. Der Ausweg aus diesem Dilemma besteht darin, zwei verschiedene öffentliche Schlüsselbunde zu verwenden (siehe Frage 4.2) Der erste Ring, die normale Datei pubring.pgp, sollte nur Empfängern vorbehalten sein, denen Du ziemlich oft Nachrichten schickst. Der zweite Schlüsselbund kann alle anderen Schlüssel enthalten. Du mußt natürlich bei jedem "Kryptiervorhang" den zu benutzenden Schlüsselbund angeben. Von da an wird die Ver-/Entschlüsselung mit Empfängerschlüsseln aus Deinem kürzeren Schlüsselbund viel schneller von statten gehen. Die Ver- und Entschlüsselungszeiten vergrößern sich auch mit der Größe der einzelnen Schlüssel. Ein 2048-Bit Schlüssel wird viel langsamer arbeiten als beispielsweise ein 512-Bit Schlüssel.

2.4 Wie erstelle ich eine zweite Schlüsseldatei?

Laß uns zunächst davon ausgehen, daß Du den gesamten Mammut-Schlüsselbund als Standard in der Datei pubring.pgp untergebracht hast. Du wirst alle häufiger benutzten Schlüssel in separate Schlüsseldateien extrahieren müssen, indem Du das -kx - Kommando benutzt. Dann gib pubring.pgp einen beliebigen neuen Namen. Wir nehmen dafür den Namen "pubring.big" an. Jetzt füge jeden einzelnen der vorher extrahierten Schlüssel in eine neue Datei pubring.pgp ein. Das Kommando dazu ist -ka. Zum Verschlüsseln für einen Empfänger im kurzen Standard-Schlüsselbund benutze das Kommando "pgp -e <Datei> <Empfänger>". Für jemanden im langen Schlüsselbund verschlüsselst Du mit "pgp -e +pubring=c:\pgp\pubring.big <Datei> <Empfänger>". Beachte, daß Du den gesamten Pfad und den Dateinamen des zweiten Schlüsselbundes angeben mußt. Er wird nicht gefunden, wenn Du nur den Dateinamen nennst.

2.5 Wie geht PGP mit Mehrfachadressierungen um?

Beim Verschlüsseln einer Nachricht für mehrere Adressaten wirst Du feststellen, daß die verschlüsselte Datei pro Adressat nur geringfügig länger wird. Der Grund dafür liegt darin, daß der Nachrichtenblock nur ein einziges Mal mit einem zufälligen Schlüssel und IDEA verschlüsselt wird. Es ist dann bloß erforderlich, diesen Schlüssel für jeden Adressaten einmal zu verschlüsseln und ihn im Header der Nachricht unterzubringen. Die komplette Nachricht wächst also um die Größe des Headers für jede zusätzliche Adresse. (Jedesmal wenn er RSA-verschlüsselt wird, wird der IDEA-Schlüssel um verschiedene Zufallsdaten ergänzt. Dies zur Vermeidung einer bekannten Schwäche von RSA beim Verschlüsseln der gleichen Nachricht an mehrere Empfänger.)

2.6 Wo bekomme ich Skripte, die PGP in meine Email oder News-Programme einbinden?

Es sind viele Skripte und Programme erhältlich, um PGP leichter anwenden zu können. Einen Index findest Du auf http://www.primenet.com/~shauert/.

Wenn Du von Oberflächen, Skripten oder Front-Ends weißt, die hier nicht erwähnt werden, übermittle die URL (oder sonstwie brauchbare Informationen darüber) an den Autor dieser Seite (Scott Hauert, shauert@primenet.com), nicht an mich.

2.7 Wie entschlüssele ich Nachrichten, die ich für Andere verschlüsselt habe?

Bei konventioneller Verschlüsselung kannst Du die Nachricht lesen, indem Du PGP auf sie anwendest und das Paßwort eingibst, das Du beim Verschlüsseln gewählt hast.

Bei der Verschlüsselung mit PGP und öffentlichen Schlüsseln ist das unmöglich, es sei denn, Du hast gleichzeitig an Dich selbst verschlüsselt.

Es gibt eine undokumentierte Einstellung: "EncryptToSelf", die Du in Deiner Konfigurationsdatei "Config.txt" oder in der Kommandozeile auf "on" stellen kannst, wenn Du möchtest, daß PGP Nachrichten immer auch an Dich selbst verschlüsselt. Sei jedoch gewarnt: Würde Dein geheimer Schlüssel kompromittiert (einem Unberechtigten zugänglich), würde diese Einstellung bedeuten, daß sowohl Deine versandten als auch Deine empfangenen Nachrichten zu lesen wären.

2.8 Warum kann ich mit PGP unter Unix keinen Schlüssel generieren?

Das liegt wahrscheinlich daran, daß PGP keine Dateien für die öffentlichen und geheimen Schlüsselbunde erstellen kann. Sollte die Umgebungsvariable PGPPATH nicht definiert sein, wird PGP versuchen, die Dateien ins Unterverzeichnis ".pgp" Deines Hauptverzeichnisses zu legen. Es wird nicht versuchen, das Verzeichnis bei Bedarf einzurichten; statt dessen, wenn es nicht schon existiert, wird PGP nach der Schlüsselerzeugung zusammenbrechen. Das passiert auch, wenn PGPPATH auf ein Verzeichnis verweist, in dem Du über keine Schreibberechtigung verfügst.

Es gibt zwei Auswege: Setze die Umgebungsvariable PGPPATH so, daß sie auf das Verzeichnis mit Deinen Schlüsselringen verweist oder starte "mkdir $HOME/pgp; chmod 700 $HOME/.pgp" bevor Du Deine Schlüssel erzeugst.

2.9 Wenn ich ein Dokument mit einer "Klartextunterschrift" versehe, stellt PGP einigen meiner Zeilen Bindestriche voran. Wozu ist das gut?

PGP tut das wegen des "-----BEGIN PGP MESSAGE-----" (und ähnlicher) Header, den es benutzt, um den Anfang von PGP-Nachrichten zu markieren. Um nichts durcheinander zu bringen, wird "- " jeder Zeile vorangestellt, die mit einem Bindestrich beginnt. Der Extra-Bindestrich und die Leerstelle werden wieder entfernt, wenn Du die Signatur überprüfst. Statt dessen wird der Originaltext wieder hergestellt.

Das Gleiche geschieht mit einigen Zeilen, die spezielle Formeln enthalten, so zum Beispiel "From", weil diese Zeilen andernfalls von Mail-Programmen ausgelassen würden, was wiederum die Signatur verfälschen würde.

2.10 Wie verschlüssele ich mehrere Dateien auf einmal?

PGP akzeptiert zur Verschlüsselung normalerweise nur eine Datei in der Kommandozeile. Einige Betriebssysteme erlauben es Dir, Programme in einer "Batch-" Sequenz aufzurufen. Du kannst diesen Umstand ausnutzen, um PGP automatisch auf mehrere Dateien anzuwenden.

Unter MS-DOS und OS/2 geht das folgendermaßen:
for %a in (*.*) do pgp -ea %a userid

Du kannst auf diese Weise auch konventionell verschlüsseln, indem Du die undokumentierte "-z -"Option benutzt, um ein Paßwort (oder einen längeren Paßphrase) für die Verschlüsselung aller Dateien festzulegen:
for %a in (*.*) do pgp -c %a -z"das Paßwort"

In UNIX würde das so aussehen:
for a in *; do pgp -ea $a userid; done

Einige Oberflächen und "Front-Ends" ermöglichen Dir natürlich ebenfalls, mehrere Dateien auf einmal zu verschlüsseln.

2.11 Wie übergebe ich meinen "Paßphrase" automatisch an PGP?

Drei Möglichkeiten: Am einfachsten ist es wohl, die Umgebungsvariable PGPPASS so zu setzen, daß sie Dein Paßwort ("Paßphrase") enthält. Unter DOS könntest Du das mit der Eingabe "set PGPPASS=Mein geheimer Paßphrase" erreichen.

Das ist ein sehr unsicheres Verfahren, da jeder, der Zugang zu Deinem System hat, Deinen Paßphrase sehen kann. Das schließt alle Leute ein, die während Deiner Mittagspause daherkommen und am DOS-PROMPT Deines Computers "set" eingeben. In einigen UNIX-Versionen ist es ebenfalls möglich, die Umgebungsvariablen eines Anderen zu untersuchen.

Einen weiteren Ansatz, besonders gut von grafischen Oberflächen aus zu nutzen, bietet die "z-" Option. Du mußt -z"Mein Paßphrase" der PGP-Kommandozeile zufügen. Setze den Paßphrase in Anführungszeichen, wenn er irgendwelche Sonderzeichen enthält, wie < oder >, die das Programm irreführen könnten.

Das wiederum ist noch unsicherer auf einem Mehrbenutzersystem. Jeder sieht, welche Programme Du benutzt, inklusive aller Optionen, die Du nutzt.

Die beste, aber auch komplizierteste Methode besteht darin, die Umgebungsvariable PGPPASSFD zu benutzen. Sie sollte eine "Dateibeschreibungs-Nummer" enthalten, die auf die Datei mit Deinem Paßphrase hindeutet. So wird Dein Paßphrase vor jedem außer dem Superuser geschützt, vorausgesetzt, Du hast die Zugriffsrechte richtig festgelegt.

Dank an Jack Gostl <gost.@argos.argoscomp.com> für das Folgende:

Man findet Informationen darüber im Anhangtext des PGP262-Paketes. Wenn Du PGPPASSFD auf 0 setzt, wird PGP den Paßphrase beim Start vom Standard-Input (Keyboard) lesen.
PGPPASSFD=0; export PGPPASSFD
echo "PaßPhraseHier" ¦ pgp -east datei empfänger1 empfänger2

Patrick J. LoPresti <patl@lcs.mit.edu> fügt hinzu:

Du kannst auch Eingabeumleitung benutzen, um den Paßphrase aus einer beliebigen Datei zu holen. Der exakte Befehl hängt von der benutzten Oberfläche ab. KSH und ähnliche benutzen "export PGPPASSFD=3", CSH und Verwandte dagegen "setenv PGPPASSFD 3".
setenv PGPPASSFD 3; pgp -eat file recipient 3 < /meine/Paßphrase/Datei

Das letzte Beispiel bietet den zusätzlichen Vorteil, daß der Standard-Input dem Benutzer weiterhin zur Verfügung steht, um beispielsweise JA/NEIN-Fragen zu beantworten.

2.12 Kann es sein, daß "randseed.bin" von einem Virus infiziert wird?

Die Datei 'Randseed.bin' wird von PGP benutzt, um jedesmal, wenn Du etwas verschlüsselst, einen neuen, zufälligen Schlüssel zu erzeugen. Danach wird sie mit neuen Zufallsdaten aufgefüllt. Ein Virus-Checker wird dann natürlich Veränderungen an der Datei feststellen. Da die Datei "bin" als Erweiterung trägt, glauben die meisten Prüfprogramme, es mit einer ausführbaren Datei zu tun zu haben und werden Dich über einen möglichen Virusfund in Kenntnis setzen.

Dennoch ist diese Datei nur Quelle einiger Zufallswerte und wird niemals "ausgeführt". Es ist daher sicher, sie in die Ausschlußliste Deines Virusscanners aufzunehmen, damit sie in Zukunft nicht mehr beachtet wird. Alternativ kann bei 2.6-Versionen die Zeile Randseed=C:\pgp\random.src in Config.txt aufgenommen werden. Das bringt PGP dazu, die Zufallsbits in dieser Datei statt in randseed.bin zu speichern.

Es wird keinen Schaden anrichten, wenn Du Randseed.bin löschst; PGP wird Dich lediglich um einige zufällige Tastaturanschläge bitten und die Datei beim nächsten Kryptiervorgang neu erstellen.

2.13 Wieso findet MacPGP meinen privaten Schlüssel nicht?

Zbigniew fiedorowicz <fiedorow@math.ohio-state.edu> erklaert:

Das ist ein echter Fehler in MIT MacPGP 2.6.2 und sicherlich eine FAQ in den PGP-Newsgroups. MIT Mac PGP 2.6.2 erklärt seltsamerweise, daß es Deinen geheimen Schlüssel nicht findet, obwohl es Deinen geheimen Schlüsselbund findet. Das kann gelegentlich passieren. Der Grund dafür ist ein nicht initialisierter "pointer", der eigentlich auf Deine User-ID deuten soll, wenn Du eine festgelegt hast, andernfalls auf den leeren String.
Leider wird er im letzteren Fall nicht initiallisiert und weist auf irgendeinen zufälligen Speicherbereich. Wenn dieser Bereich mit einem Null-Byte startet, wird alles normal ablaufen, und MacPGP wird den ersten geheimen Schlüssel in secring.pgp benutzen. Anderenfalls aber wird MIT MacPGP annehmen, daß Dein User-ID irgend ein zufälliger Abfall ist und konsequenterweise nicht fähig sein, Deinen geheimen Schlüssel zu finden. Umgehen läßt sich das Problem, indem Du Deine Datei Config.txt editierst und die Zeile "MyName="Name_im_geheimen_Schlüssel" einfügst.

2.14 Wie setze ich die TZ-Variable?

Die Umgebungsvariable TZ wird gebraucht, um die Zeitzone, in der sich Dein Computer befindet, einzustellen. Das erlaubt es PGP, Zeitstempel für UTC-Zeiten (früher GMT) zu erzeugen, so daß es keine Widersprüche gibt, wenn jemand in einer anderen Zeitzone die Signatur nachprüft und herausfindet, daß sie in der Zukunft erstellt worden ist oder zu einem anderen unrichtigen Zeitpunkt. Sie wird in Deiner AUTOEXEC.BAT (in DOS) oder CONFIG.SYS (OS/2) definiert. Für andere Systeme, konsultiere das Handbuch.

In den meisten Fällen, kannst Du die Einstellungen aus der folgenden Liste übernehmen:

Für Los Angeles: SET TZ=PST8PDT
Für Denver: SET TZ=MST7MDT
Für Arizona: SET TZ=MST7 (Arizona wendet niemals Sommerzeit an)
Für Chicago: SET TZ=CST6CDT
Für New York: SET TZ=EST5EDT
Für London: SET TZ=GMT0BST
Für Amsterdam: SET TZ=MET-1DST
Für Moskau: SET TZ=MSK-3MSD
Für Aukland: SET TZ=NZT-12DST

Für andere Länder muß die komplette Darstellung der TZ-Variable benutzt werden. Ausführlicher heißt das: SET TZ=SSS[+|-]nDDD,sm,sw,sd,st,em,ew,ed,et,shift

Wobei "SSS", "n" und DDD" die Werte der vereinfachten Darstellung sind. In der langen Form müssen alle anderen Werte wie folgt spezifiziert werden.

"sm": ist der Anfangsmonat (1-12) der Sommerzeit
"sw": ist die Anfangswoche (1-4, vom Begin gezählt, oder -1 bis -4, vom Ende). 0 zeigt an, daß ein bestimmter Tag des Monats angegeben werden muß.
"sd": ist der Anfangstag (0 bis 6 [wobei 0 der Sonntag ist] wenn "sw" ungleich 0 ist, oder 1 bis 31, wenn "sw" gleich 0 ist)
"st": ist die Startzeit in Sekunden seit Mitternacht (also 3600 für 01:00 Uhr)
"em", "ew", "ed" und "et": definieren das Ende der Sommerzeit und nehmen die gleichen Werte an.
"shift": ist der Zeitunterschied bei der Umstellung auf Sommerzeit, in Sekunden (also 3600 wenn während der Sommerzeit 1 Stunde addiert werden muß).

Zum Beispiel wurde für Großbritannien 1995 die Einstellung SET TZ=GMT0BST,3,0,26,3600,10,0,22,3600,3600 erwartet (26-März-01Uhr-1Std vorstellen-22-Oktober-1Std-zurückstellen).

2.15 Wie erkenne ich, ob das PGP-Kommando korrekt ausgeführt worden ist?

Normalerweise läuft PGP im "interaktiven" Modus, und somit kannst Du immer auf dem Bildschirm lesen, was schief gegangen ist, wo und hoffentlich warum. Aber, solltest Du PGP in einer Batch-Datei benutzen wollen oder im Hintergrund, mußt Du auf andere Weise herausfinden ob die Aktion erfolgreich war. Der gewöhnlich eingeschlagene Weg dazu, ist der Gebrauch des "Beendigungscodes", den PGP zurueckgibt.

Um zu sehen, ob PGP ausführen kann, was Du verlangst, mußt Du die "+batchmode" -Option in der Kommandozeile angeben (Um zu vermeiden, daß Du an Eingabeaufforderungen festhängst, die Dich um "Ja" oder "Nein" bitten, nimm die "+force" -Option hinzu). PGP wird dann 0 zurückgeben, wenn alles in Ordnung ist und 1, wenn etwas schief gelaufen ist.

Der PGP Quellcode enthält eine Liste von Beendigungscodes, deren Ausgabe erwartet wird, wenn die damit verbundenen Ereignisse eintreten. Es scheint dies nicht immer so zu funktionieren, wie erwartet. Zum Beispiel gibt PGP den Beendigungscode 31 zurück, wenn kein Paßphrase festgelegt worden ist um die Datei zu entschlüsseln, aber wenn Du versuchst eine Signatur zu prüfen, wird Beendigungscode 1 benutzt, um jedweden Fehler anzuzeigen, einschließlich "Kein Schlüssel um die Signatur zu prüfen" und "Keine korrekte Signatur".

Warum fragt PGP 5.0 nicht mehr nach zufälligen Tastendrücken?

Die Tastendrücke waren notwendig, um zufällige Ereignisse zu bekommen. PGP 5.0 benutzt Systemereignisse, die die ganze Zeit stattfinden, um ständig die Datei randseed.bin zu füllen. Diese Ereignisse umfassen Festplattenzugriffe, Tastatureingaben, Mausbewegungen und andere Dinge, die zufällig genug sind. Zur Überprüfung kannst Du beobachten, wie randseed.bin auch dann verändert wird, wenn Du nicht PGP benutzt.

Sind PGP 5.0/5.5 und PGP 2.6.x kompatibel?

PGP 5.x ist abwärtskompatibel zu PGP 2.6.x. Das bedeutet, PGP 5.x kann mit den Ausgaben von PGP 2.6.x problemlos arbeiten. Werden nur RSA Schlüssel mit IDEA und MD5 verwendet, so sind auch umgekehrt die Ausgaben von PGP 5.x mit PGP 2.6.x verarbeitbar. Ein wenig problematisch sind ElGamal oder DSS Zertifikate von PGP 5.x unter RSA Schlüsseln. Diese Zertifikate werden von PGP 2.6.x beim Kommando '-kc' fehlerhaft verarbeitet. Die Version PGP 2.6.3in behebt diesen (unwesentlichen) Fehler.

PGP 2.6.x arbeitet mit PGP 5.x zusammen, wenn ausschließlich MD5, RSA und IDEA verwendet werden.

Sicherheitsfragen

Wie sicher ist PGP?
Kann man PGP brechen, indem man sämtliche, denkbaren Schlüssel ausprobiert?
Wie sicher ist die konventionelle Verschlüsselungs-Option (-c)?
Kann die NSA (amerikanischer Geheimdienst "National Security Agency") RSA brechen?
Wurde RSA jemals öffentlich gebrochen? Was ist RSA-129?
Wie sicher ist die "Nur zur Ansicht"- Option (-m)?
Was ist, wenn ich meinen Paßphrase vergesse?
Warum wird der Begriff "Paßphrase" (oder Mantra) anstelle "Paßword" benutzt?
Was ist der beste Weg um PGP zu knacken?
Können meine Nachrichten gelesen werden, wenn mein privater Schlüssel gestohlen wurde?
Wie wähle ich meinen Paßphrase?
Wie merke ich mir meinen Paßphrase?
Wie überpruefe ich, ob mein Exemplar von PGP unverändert ist?
Ich kann die Signatur meiner neuen MIT-PGP-Version nicht mit Hilfe meines alten PGP 2.3a! überprüfen.
Woher weiß ich, daß es im Programm keine "Hintertür" gibt?
Ich habe gehört, daß die NSA eine "Hintertür" in MIT-PGP eingebaut hat, und daß sie nur diese manipulierte Version erlauben.
Gibt es eine "Hintertür" in der internationalen Version?
Kann ich PGP auf einem Mehrbenutzersystem, z. B. einem Netzwerk oder einem Großrechner benutzen?
Kann ich PGP unter einem "auslagernden" Betriebssystem wie Windows oder OS/2 verwenden?
Warum wird nicht ausschließlich RSA, statt der Mischung aus IDEA, MD5 und RSA verwendet?
Sind nicht alle diese Sicherheitsvorkehrungen ein wenig paranoid?
Kann ich auf rechtlichem Wege gezwungen werden, meinen Paßphrase preiszugeben?

3.1 Wie sicher ist PGP?

Die große Unbekannte in jedem Verschüsselungs-Konzept, das auf RSA basiert, ist: Gibt es einen effizienten Weg zur Faktorisierung großer Zahlen, oder: Gibt es eine Art "Hintertür-Algorithmus", der den Code ohne das Faktorisierungsproblem brechen kann? Sogar, wenn kein solcher Algorithmus existiert, glaubt man immernoch, daß RSA das schwächste Glied in der PGP-Kette ist.

Alle möglichen Angriffe gegen-, oder mögliche Fehler in PGP zu besprechen, würde den Rahmen dieser FAQ sprengen. Wenn Du mehr erfahren willst, als hier angeboten wird, schau nach in "infiNity's PGP Attack FAQ": http://www.stack.nl/~galactus/remailers/attack-faq.html

3.2 Kann man PGP brechen, indem man sämtliche, denkbaren Schlüssel ausprobiert?

Das ist eine der ersten Fragen, die Leute stellen, wenn sie zum ersten Mal in die Kryptographie eingeführt werden. Sie verstehen das Ausmaß des Problems nicht. Für das IDEA-Verschlüsselungskonzept ist ein 128-Bit-Schlüssel erforderlich. Jede der 2^128 möglichen Kombinationen wäre als Schlüssel zulässig, und nur der eine Schlüssel würde erfolgreich alle Nachrichtenblöcke entschlüsseln. Laß uns annehmen, daß Du einen Spezialchip entwickelt hättest, der eine Milliarde Schlüssel pro Sekunde ausprobieren könnte. Das ist weit jenseits der heutigen Möglichkeiten. Laß uns ebenfalls sagen, Du könntest es Dir leisten, eine Milliarde solcher Chips zur gleichen Zeit, auf das Problem anzusetzen. Es würde immernoch 10.000.000.000.000 Jahre dauern, all die möglichen 128-Bit-Schlüssel auszuprobieren. Das ist in etwa tausendmal das Alter des bekannten Universums! Obwohl die Geschwindigkeit der Computer weiterhin steigt und ihre Kosten sehr schnell sinken, wird es wahrscheinlich niemals soweit kommen, daß IDEA durch diese "Brute Force Attacke" (etwa: 'Brachialangriff') geknackt werden könnte.

Die einzige Form des Angriffs, die erfolgreich sein könnte, ist eine, die das Problem von einem mathematischen Standpunkt aus löst: Durch das Analysieren der Umformungen, die zwischen Klartextblöcken und ihren Chiffretext-Äquivalenten stattfinden. IDEA ist immernoch ein ziemlich neuer Algorithmus, und es muß noch viel Arbeit daran verrichtet werden, weil er mit der Theorie der komplexen Zahlen in Verbindung steht, aber bislang scheint es keinen Algorithmus zu geben, der sehr viel besser geeignet wäre, eine IDEA-Verschlüsselung aufzulösen als die brute force Attacke, die wir schon als unpraktikabel dargestellt haben. Die nichtlineare Transformation, die in IDEA stattfindet, stuft es in eine Klasse extrem schwierig zu lösender Probleme ein.

3.3 Wie sicher ist die konventionelle Verschlüsselungs-Option (-c)?

Unter der Annahme, daß Du einen guten, starken, zufälligen Paßphrase benutzt, ist sie viel stärker als der normale Verschlüsselungsmodus, weil Du RSA ausläßt, das als das schwächste Glied in der Kette angesehen wird. Natürlich wirst Du in diesem Modus vorab geheime Schlüssel mit jedem der Empfänger austauschen müssen, indem Du eine andere sichere Methode der Kommunikation benutzt, wie zum Beispiel Treffen unter vier Augen oder einen vertrauenswürdigen Kurier.

Diese Option ist besonders nützlich, wenn Du sensible Dateien sichern oder verschlüsselte Dateien zu einem anderen System bringen willst, wo Du sie entschlüsseln wirst. Nun mußt Du nicht Deinen geheimen Schlüssel mitnehmen.

Das wird auch nützlich sein, wenn Du Deinen geheimen Schlüssel verloren hast. Und Du kannst Dir für jede Datei, die Du verschlüsselst, einen anderen Paßphrase aussuchen, so daß ein Angreifer, der es schafft, eine Datei zu entschlüsseln, jetzt nicht auch all die anderen Dateien entziffern kann.

3.4 Kann die NSA (amerikanischer Geheimdienst "National Security Agency") RSA brechen?

Diese Frage ist viele Male gestellt worden. Wäre die NSA fähig, RSA zu brechen, würdest Du von ihr darüber wahrscheinlich niemals etwas hören. Jetzt, wo RSA immer populärer wird, wäre es ein sehr gut gehütetes Geheimnis. Das beste Argument dagegen ist die Tatsache, daß der Algorithmus für RSA weltweit bekannt ist. Es gibt viele gute Mathematiker, und es wäre schwierig, solch eine Entdeckung zu verstecken.

Aus diesem Grunde, wenn Du im USENET Nachrichten liest, die behaupten, daß "jemand ihnen gesagt habe", die NSA sei fähig, PGP zu brechen, glaube es nicht ohne weiteres, und frage nach schriftlichen Unterlagen darüber, von wo die Information stammt. Speziell die Meldung auf http://www.quadralay.com/www/Crypt/NSA/break-pgp.html ist ein Witz.

3.5 Wurde RSA jemals öffentlich gebrochen? Was ist RSA-129?

Zwei RSA-verschlüsselte Nachrichten sind öffentlich geknackt worden.

Zunächst ist da der RSA-129-Schlüssel. Die Erfinder von RSA haben eine Meldung veröffentlicht, die mit einem 129-stelligen (430 Bits), oeffentlichen Schlüssel verschlüsselt worden ist und boten der ersten Person, die die Nachricht entschlüsseln koennte, 100$. 1994 faktorisierte ein internationales Team, das von Paul Leyland, Derek Atkins, Arjen Lenstra und Michael Graff koordiniert wurde, erfolgreich diesen öffentlichen Schlüssel und stellte den Originaltext wieder her. Die Nachricht lautete: THE MAGIC WORDS ARE SQUEMISH OSSIFRAGE

Sie führten eine riesige Freiwilligenaktion an, während derer die Arbeit über E-mail, Fax und reguläre Post an Teilnehmer im Internet verteilt wurde, die ihren Teil verarbeiteten und die Resultate zurückschickten. Etwa 1600 Maschinen nahmen Teil, mit Rechnerleistungen, die vom Faxgerät bis zum Cray Supercomputer reichten. Sie benutzten den damals besten bekannten Faktorisierungsalgorithmus; seither sind bessere Methoden entdeckt worden, aber das Resultat ist immernoch lehrreich hinsichtlich des Arbeitsaufwandes, der benötigt wird, eine RSA-verschlüsselte Nachricht zu brechen.

Die Koordinatoren haben geschätzt, daß das Projekt etwa 8 Monate realer Zeit und nahezu 5000 MIPS-Jahre Rechenzeit gebraucht hat.

Was hat all das mit PGP zu tun? Der RSA-129-Schlüssel ist, was die Sicherheit angeht, etwa dem 426-Bit PGP-Schlüssel ebenbürtig. Daß der leicht zu brechen ist, wurde bei diesem Projekt gezeigt. PGP pflegte 384-Bit-Schlüssel als "casual grade" Sicherheitsstufe zu empfehlen; jüngere Versionen bieten 512 Bits als empfohlene Mindestsicherheitsstufe an.

Beachte, daß die Aktion nur einen einzigen RSA-Schlüssel brach. Nichts wurde im Verlauf des Experimentes entdeckt, das irgendeinen anderen Schlüssel weniger sicher macht, als er es vorher gewesen ist.

Ein Jahr später wurde der erste wirkliche PGP-Schlüssel geknackt. Es war der berühmte Blacknet Schlüssel, ein 384-Bit-Schlüssel der anonymen Existenz, die als "Blacknet" bekannt war. Ein Team, das aus Alec Muffet, Paul Leyland, Arjen Lenstra und Jim Gillogly bestand, schaffte es, genügend Rechenleistung zusammenzubringen (annähernd 1300 MIPS), um den Schlüssel in drei Monaten zu faktorisieren. Er wurde dann benutzt, um eine öffentlich zugängliche Nachricht, die damit verschlüsselt worden war, zu entschlüsseln.

Das Allerwichtigste bei dieser Attacke war, daß sie unter fast kompletter Geheimhaltung stattfand. Anders als beim RSA-129-Angriff, gab es keine Publicity um dieses Projekt, bis es vollendet war. Die meisten Computer arbeiteten nur in der Freizeit daran, und die gesamte Leistung liegt sehr wohl im Bereich der Möglichkeiten einer großen, vielleicht sogar mittelgroßen, Organisation.

3.6 Wie sicher ist die "Nur zur Ansicht"- Option(-m)?

Sie ist überhaupt nicht sicher. Es gibt viele Wege, sie zu überwinden. Der Einfachste ist wahrscheinlich schlicht, Deine Bildschirmausgabe in eine Datei umzuleiten, wie folgt: "pgp [Dateiname] > [neuer Dateiname]"

Die "-m"-Option war nicht als idiotensichere Möglichkeit gedacht, um die Erzeugung von Klartexten zu verhindern, sondern einfach als Warnung an die Person, die die Datei entschlüsselt, daß sie besser keine Kopie des Klartextes auf ihrem System behalten sollte.

3.7 Was ist, wenn ich meinen Paßphrase vergesse?

Kurz: Vergiß ihn nicht. Wenn Du Deinen Paßphrase vergißt, gibt es absolut keinen Weg, irgend eine verschlüsselte Datei zurückzugewinnen. Wenn Du besorgt bist, Deinen Paßphrase zu vergessen, könntest Du eine Kopie Deines geheimen Schlüssels anfertigen, dann den Paßphrase in einen anderen abändern, und schließlich den geheimen Schlüssel mit dem geänderten Paßphrase an einem sicheren Ort aufbewahren.

3.8 Warum wird der Begriff "Paßphrase" (oder Mantra) anstelle "Paßword" benutzt?

Das geschieht, weil die meisten Leute, wenn sie gebeten werden, ein Paßwort zu wählen, ein einfaches gebräuchliches Wort aussuchen. Das kann von einem Programm erraten werden, das ein Wörterbuch benutzt um Paßwörter an einem System auszuprobieren.

Weil die meisten Menschen tatsächlich kein wirklich zufälliges Paßwort auswählen wollen, bei dem die Buchstaben und Ziffern in einem unsinnigen Muster gemischt sind, wird der Ausdruck "Paßphrase" benutzt, um die Leute zu drängen, wenigstens mehrere beziehungslose Worte hintereinander als Paßphrase zu verwenden.

3.9 Was ist der beste Weg um PGP zu knacken?

Zur Zeit ist der beste Angriff gegen PGP selbst eine Wörterbuchattacke gegen den Paßphrase. Dabei entnimmt ein Programm einem Wörterbuch Worte und reiht sie, im Bestreben Deinen Paßphrase zu erraten, auf verschiedene Weise hintereinander.

Deshalb ist es so wichtig, einen starken Paßphrase zu wählen. Viele dieser "Cracker-"Programme sind sehr raffiniert und machen sich Dialekte zu Nutze, populäre Aussprüche und grammatikalische Regeln, um ihre Versuche zusammenzusetzen. "Ein-Wort"-Paßphrases, Eigennamen (speziell berühmte) oder bekannte Zitate sind nahezu immer von einem Programm zu knacken, das überhaupt irgendwelche "Feinheiten" besitzt.

Es ist ein Programm erhältlich, das konventionell verschlüsselte Nachrichten durch Raten der Paßphrases knacken kann. Es wendet keinerlei Kryptoanalyse an, so daß Deine Dateien immernoch sicher sein werden, wenn Du einen starken Paßphrase wählst. Siehe http://www.voicenet.com~/markm/pgpcrack.html für mehr Informationen und das Programm selbst.

Es gibt auch andere Methoden, um an den Inhalt einer verschlüsselten Nachricht zu gelangen, wie Bestechung, Schnüffelei nach der elektronischen Abstrahlung des Computers, der die Nachrichten verarbeitet (oft als "TEMPEST-"Attacke bezeichnet), Erpressung oder "rubber-hose-"Kryptographie- solange mit einem Gummischlauch auf den Kopf schlagen, bis Du den Paßphrase preisgibst.

3.10 Können meine Nachrichten gelesen werden, wenn mein privater Schlüssel gestohlen wurde?

Nein, solange sie nicht auch Deinen geheimen Paßphrase gestohlen haben, oder Dein Paßphrase anfällig für eine brute-force-Attacke ist. Kein Teil ist ohne den anderen brauchbar. Du solltest trotzdem diesen Schlüssel zurückziehen und einen frischen mit einem anderen Paßphrase generieren. Bevor Du Deinen alten Schlüssel zurückziehst, willst Du vielleicht eine neue User-ID anhängen, die feststellt, welche Deine neue Schlüssel-ID ist, so daß Andere von Deiner neuen Adresse erfahren.

3.11 Wie wähle ich meinen Paßphrase?

Die ganze Sicherheit, die in PGP zur Verfügung steht, kann absolut nutzlos gemacht werden, wenn Du keinen guten Paßphrase wählst, um Deinen geheimen Schlüsselbund zu verschlüsseln. Zu viele Leute benutzen ihren Geburtstag, ihre Telefonnummer, den Namen einer/eines Geliebten oder irgendein leicht zu ratendes, gebräuchliches Wort.

Während es eine Anzahl von Vorschlägen zur Erzeugung guter Paßphrases gibt, erhält man das Optimum an Sicherheit, wenn die Zeichen des Paßphrases komplett zufällig ausgesucht werden. Er kann etwas schwieriger zu merken sein, aber die zusätzliche Sicherheit ist es wert. Als absolut minimaler Paßphrase, würde ich eine zufällige Kombination von mindestens 8 Buchstaben und Ziffern vorschlagen, wobei 12 die bessere Wahl sind. Mit einem 12-Buchstaben-Paßphrase, der aus den Kleinbuchstaben von a-z besteht und den Ziffen 0-9, erhälst Du ungefähr 62 Bits eines Schlüssels, was 6 Bits besser ist als die 56-Bit-DES-Schlüssel. Wenn Du möchtest, kannst Du Groß- und Kleinbuchstaben in Deinem Paßphrase mischen, um für die gleiche Sicherheitsstufe die Anzahl der benötigten Buchstaben zu verringern.

Ein Paßphrase, der aus gewöhnlichen Worten ohne Interpunktion oder Sonderzeichen besteht, ist anfällig für eine Wörterbuchattacke.

Umstellung von Buchstaben oder Rechtschreibfehler machen Deinen Paßphrase weniger empfindlich, aber bei einer professionellen Wörterbuchattacke wird für diese Fälle vorgesorgt.

Siehe Randall T. Williams' Paßphrase-FAQ auf http://www.stack.nl/~galactus/remailers/passphrase-faq.html für eine detailliertere Analyse.

3.12 Wie merke ich mir meinen Paßphrase?

Das kann ein Problem sein, besonders, wenn Du wie ich bist, und etwa ein Dutzend verschiedene Paßphrases besitzt, die im täglichen Leben gebraucht werden. Sie irgendwo niederzuschreiben, um sie Dir zu merken, würde den ganzen Zweck der Paßphrases von vornherein unterhöhlen. Es gibt daraus wirklich keinen guten Ausweg. Entweder erinnere Dich, oder schreibe sie irgendwo nieder und riskiere, daß sie kompromittiert werden.

3.13 Wie überpruefe ich, ob mein Exemplar von PGP unverändert ist?

Wenn Du momentan keine Kopie von PGP besitzt, verwende große Umsicht darauf, von wo Du Deine erste Kopie beziehst. Was ich empfehlen würde, ist, daß Du Dir zwei oder mehr Kopien aus verschiedenen Quellen besorgst, bei denen Du das Gefühl hast, daß Du ihnen trauen kannst.

Vergleiche die Kopien, um zu sehen ob sie absolut identisch sind. Das eliminiert nicht die Möglichkeit, daß Du eine beschädigte Kopie bekommst, aber es wird die Wahrscheinlichkeit sehr einschränken.

Wenn Du bereits eine vertrauenswürdige Version von PGP besitzt, ist es leicht, die Gültigkeit jeder zukünftigen Version zu überprüfen. Neuere Binärversionen von MIT PGP werden in gängigen Archivformaten vertrieben; die Archivdatei, die Du erhälst, wird nur eine andere Archivdatei enthalten, eine Datei mit dem gleichen Namen wie die Archivdatei mit der Erweiterung .ASC, und eine "setup.doc"-Datei. Die .ASC-Datei ist eine abgetrennte Signaturdatei für die innere Archivdatei, die vom Entwickler dieser speziellen PGP-Ausgabe angefertigt worden ist. Da niemand anders als der Entwickler Zugang zu seinem/ihrem geheimen Schlüssel hat, kann sich niemand an der Archivdatei zu schaffen machen, ohne daß es entdeckt wird. Natürlich enthält die innere Archivdatei die neuere PGP-Ausgabe.

Eine Randbemerkung: Wenn Du von einer älteren Ausführung (2.3a oder früher) auf MIT PGP aufrüstest, könntest Du Schwierigkeiten beim Überprüfen der Signatur bekommen. Siehe Frage 3.14 für eine ausführlichere Abhandlung dieses Problems.

Um die Signatur zu überprüfen, mußt Du Deine alte PGP-Version benutzen, um die Archivdatei zu testen, die die neue Version enthält. Wenn Deine alte PGP-Version in einem Verzeichnis C:\PGP liegt und Dein neues Archiv und die Signatur in C:\NEW (und wenn Du MIT PGP 2.6.2 besorgt hast), kannst Du das folgende Kommando ausführen: "C:\pgp\pgp c:\new\pgp262i.asc c:\new\pgp262i.zip"

Wenn Du Dir den Quellcode von MIT PGP besorgst, wirst Du zwei weitere Dateien in Deiner Ausgabe finden: eine Archivdatei für die RSAREF-Bibliothek und eine Signaturdatei für RSAREF. Du kannst die RSAREF-Bibliothek auf die gleiche Art überprüfen, wie Du es mit dem Hauptarchiv des PGP-Quellcodes tust.

Andere als MIT-Versionen enthalten typischerweise nur eine Signaturdatei für die PGP.EXE-Programmdatei. Diese Datei wird gewöhnlich PGPSIG.ASC genannt. Du kannst somit die Integrität des Programmes selbst dadurch überprüfen, daß Du Deine ältere PGP-Version auf die Signatur und die Programmdatei der neueren Version anwendest.

Phil Zimmermann selbst hat alle PGP-Versionen bis 2.3a unterzeichnet. Seitdem haben die führenden Entwickler jeder der verschiedenen Versionen von PGP, ihre Ausführungen signiert. Zur Zeit der Entstehung dieses Textes, waren die Entwickler, deren Signaturen in den jeweiligen Ausgaben erscheinen:

MIT PGP 2.6.2: Jeff Schiller<jis@mit.edu>
ViaCrypt PGP 2.7.1: ViaCrypt
PGP 2.6.2i/2.6.3i/2.6.3ia: Stale Schumacher <staalesc@ifi.uio.no>
PGP 2.6ui/2.6.3ui: mathew <mathew@mantis.co.uk>

3.14 Ich kann die Signatur meiner neuen MIT-PGP-Version nicht mit Hilfe meines alten PGP 2.3a überprüfen!

Der Grund dafür liegt natürlich darin, daß die Signaturen, die mit MIT PGP erzeugt werden (Wie die von Jeff Schiller für seine Version), nicht mehr mittels PGP 2.3a zu lesen sind.

Du brauchst zunächst einmal die Signatur nicht zu überprüfen und kannst andere Verfahren anwenden, um klarzustellen, daß Du keine schlechte Kopie erhälst. Das ist dennoch nicht so sicher; wenn Du nicht vorsichtig bist, kannst Du eine defekte Kopie von PGP zugeschoben bekommen.

Willst Du die Signatur dennoch prüfen, kannst Du vorläufig auf MIT 2.6 aufrüsten. Diese ältere Version wurde unterzeichnet, bevor die "Zeitbombe" sich ausgewirkt hatte, so daß ihre Signatur von den älteren PGP-Versionen gelesen werden kann. Wenn Du einmal die Signatur der Zwischenversion nachgeprüft hast, kannst Du dann diese Version benutzen, um die aktuelle Ausgabe zu testen.

Als weitere Alternative kannst Du auf PGP 2.6.2i oder 2.6ui aufrüsten, ihre Signaturen mit 2.3a testen und sie dann benutzen um die neuere Version zu überprüfen. Leute, die in den USA wohnen und dies tun, könnten dabei das RSA-Patent verletzen; andererseits hast Du es möglicherweise bereits mit der Benutzung von 2.3a getan, daher bist Du nicht viel schlimmer dran.

3.15 Woher weiß ich, daß es im Programm keine "Hintertür" gibt?

Der Fakt, daß der gesamte Quellcode für die Freeware-Version erhältlich ist, macht es so gut wie unmöglich, daß darin irgendeine versteckte Hintertür enthalten ist. Der Quellcode ist von zahllosen Einzelpersonen durchsucht worden, und keine solche Hintertür ist gefunden worden. Um sicher zu gehen, daß Deine ausführbare Datei tatsächlich den bekannten Quellcode enthält, ist alles, was Du tun mußt, das ganze Programm zu rekompilieren.

3.16 Ich habe gehört, daß die NSA eine "Hintertür" in MIT-PGP eingebaut hat, und daß sie nur diese manipulierte Version erlauben.

Erstens hatte die NSA überhaupt nichts damit zu tun, daß PGP "legal" wurde. Die Legalitätsprobleme, die mit MIT PGP gelöst worden sind, betrafen das erklärte Patent auf dem in PGP verwendeten RSA-Algorithmus.

Zweitens werden alle Freeware-Versionen von PGP mit dem gesamten Quellcode sowohl von PGP als auch der RSAREF-Bibliothek, die sie verwenden, herausgegeben (so wie auch jede andere Freeware-Version vorher). Damit ist das Thema bereits durch die Zusammenfassung der Prüfungsmethoden bei der vorherigen Frage abgehandelt.

3.17 Gibt es eine "Hintertür" in der internationalen Version?

Nein. Die internationale Version von PGP basiert auf einer illegal exportierten PGP-Version und benutzt eine RSA Ver-/Entschlüsselungsbibliothek (MPILIB), die ein Patent verletzen kann, das nur in den USA Gültigkeit hat. Es gibt keinerlei wie auch immer geartete Hintertüren in der internationalen Version, und auch die Verschlüsselungsfunktionalität ist in keinster Weise eingeschränkt.

3.18 Kann ich PGP auf einem Mehrbenutzersystem, z.B. einem Netzwerk oder einem Großrechner benutzen?

Ja. PGP läßt sich für einige high-end-Betriebssysteme kompilieren, wie z.B. Unix und VMS. Andere Versionen können leicht auf Maschinen verwendet werden, die an ein Netzwerk gekoppelt sind.

Du solltest dennoch sehr vorsichtig sein. Dein Paßphrase kann über das Netzwerk ins Freie gelangen, wo er von Netzwerküberwachungsgeräten abgefangen werden könnte; oder der Betreiber eines Mehrbenutzersystems kann "Tastatur-Schnüffler" installieren, um Deinen Paßphrase aufzuzeichnen, während Du ihn eingibst. Außerdem kann er von einem sogenannten "Trojanischen Pferd" aufgefangen werden. Und auch, wenn Dein geheimer Schlüsselbund verschlüsselt ist, wäre es keine gute Verhaltensweise, ihn für jeden Anderen zum Anschauen herumliegen zu lassen.

Also warum PGP überhaupt mit Anweisungen zur Einrichtung auf Unix- und VMS-Maschinen herausgeben? Die einfache Antwort ist, daß nicht alle Unix und VMS-Maschinen Netzwerkserver oder "Mainframes" sind. Wenn Du Deine Maschine nur von der "Console" aus betreibst (oder wenn Du irgendein Netzwerkverschlüsselungspaket wie Kerberos benutzt), der einzige Nutzer bist, vernünftige Maßnahmen zur Systemsicherheit triffst, um unauthorisierten Zugang zu verhindern, und Dir die oben genannten Risiken bewußt sind, kannst Du PGP zuverlässig auf diesen Systemen betreiben.

Du kannst in Mehrbenutzersystemen oder Netzwerken PGP dann auch ohne geheimen Schlüssel zum Überprüfen von Signaturen und zum Verschlüsseln verwenden. So lange Du keinen privaten Schlüssel bearbeitest, oder einen Paßphrase in Mehrbenutzersystemen eingibst, kannst Du PGP dort sicher verwenden.

Natürlich läuft alles auf die Frage hinaus, wie wichtig Dir Dein geheimer Schlüssel ist. Wenn er nur benutzt wird, um Usenet-Beiträge zu unterzeichnen und nicht für private Korrespondenz, brauchst Du ihn nicht derart argwöhnisch zu bewachen. Wenn Du Deinen Systemüberwachern traust, kannst Du Dich gegen böswillige Anwender schützen, indem Du das Verzeichnis, in dem die Schlüsselbunde liegen nur für Dich zugänglich machst.

3.19 Kann ich PGP unter einem "auslagernden" Betriebssystem wie Windows oder OS/2 verwenden?

Ja. PGP für DOS läuft anstandslos in den meisten DOS-Fenstern für diese Systeme, und PGP kann für viele von ihnen auch frisch kompiliert werden.

Das Problem mit der Nutzung von PGP auf einem System, das auslagert, ist, daß das PGP oft auf die Festplatte ausgelagert wird, während es Deinen Paßphrase verarbeitet. Wenn das zum richtigen Zeitpunkt passiert, kann Dein Paßphrase als Klartext in Deiner Auslagerungsdatei enden. Wie leicht das Auslagern "zum richtigen Zeitpunkt" geschieht, hängt vom Betriebssystem ab; Windows lagert den Paßphrase nachgewiesenermaßen recht häufig auf die Festplatte aus, wobei es auch eines der uneffektivsten Systeme ist. PGP unternimmt jede Anstrengung, den Paßphrase nicht im Speicher zu belassen, indem es den zur Aufnahme des Paßphrases genutzten Speicherplatz "auswischt," bevor er freigegeben wird, aber diese Methode ist nicht perfekt.

Wenn Du Grund hast, darüber besorgt zu sein, solltest Du erwägen, ein Hilfsprogramm zum gründlichen Löschen der Auslagerungsdatei zu erwerben um nachhaltig jede Spur des Paßphrase auszulöschen, wenn Du mit dem System fertig bist. Mehrere solcher Hilfsprogramme gibt es zumindest für Windows und Linux.

3.20 Warum wird nicht ausschließlich RSA, statt der Mischung aus IDEA, MD5 und RSA verwendet?

Zwei Gründe: Erstens ist der IDEA-Verschlüsselungsalgorithmus, der in PGP verwendet wird, bei der gleichen Schlüssellänge viel stärker, als RSA. Sogar beim Vergleich mit 1024-bit-RSA-Schlüsseln geht man davon aus, daß IDEA-Verschlüsselung noch besser ist. Weil eine Kette nicht stärker ist als ihr schwächstes Glied, nimmt man an, daß RSA momentan der schwächste Punkt des RSA-IDEA-Ansatzes ist. Zweitens ist RSA-Verschlüsselung viel langsamer als IDEA. Der einzige Zweck von RSA in den meisten Public-Key-Konzepten ist der Transfer von Sitzungsschlüsseln, die im konventionellen Geheimschlüsselalgorithmus verwendet werden sowie zum Verschlüsseln von Signaturen.

3.21 Sind nicht alle diese Sicherheitsvorkehrungen ein wenig paranoid?

Das hängt alles davon ab, wieviel Deine Privatsphäre Dir bedeutet! Auch ohne die Regierung einzubeziehen, gibt es viele Leute dort draußen, die es einfach lieben würden, Deine private Post zu lesen. Und viele dieser Individuen würden große Mühen auf sich nehmen, Deine Post zu kompromittieren. Schau Dir den Arbeitsaufwand an, der in einige der Virusprogramme gesteckt worden ist, die ihren Weg in die verschiedenen Computersysteme gefunden haben. Sogar wenn kein Geld im Spiel ist, sind einige Menschen davon besessen, in Systeme einzubrechen.

Beachte außerdem, daß geheime Schlüssel zu mehr als Entschlüsselung taugen. Jemand kann mit Deinem geheimen Schlüssel auch Sachen unterschreiben, die zu verleugnen sich später als schwierig erweisen könnte. Deinen geheimen Schlüssel in Sicherheit zu verwahren kann Dir mindestens ein paar Verlegenheiten, im schlimmsten Fall Anklagen wegen Betrugs oder Vertragsbruches ersparen.

Davon abgesehen sind viele der obigen Vorkehrungen brauchbar gegen gewöhnlichere, indirekte Angriffe. Zum Beispiel dient die Signatur auch zum effektiven Testen der Unversehrtheit der unterzeichneten Datei; Daher stellt das Testen der Unterschrift neuer PGP-Ausführungen sicher, daß Dein Computer durch PGP keinen Virus einfängt (solange nicht der Entwickler der PGP-Version selbst das Programm vor dem Unterzeichnen mit einem Virus infiziert hat).

3.22 Kann ich auf rechtlichem Wege gezwungen werden, meinen Paßphrase preiszugeben?

Gary Edstrom meinte folgendes in früheren Ausgaben dieser FAQ:

Die folgende Information betrifft nur Bürger der Vereinigten Staaten vor US-Gerichten. Die Gesetze in anderen Ländern können abweichen.
Es wurden im Internet einige Diskussionen (Threads) darüber geführt, ob oder ob nicht das Recht des fünften Amendment (zu keiner Aussage gegen Dich selbst gezwungen werden zu können), auf den Zwang zur Preisgabe Deines Paßphrases angewandt werden kann. Ohne mich auf eine der vielen gegensätzlichen Meinungen von Sesseljuristen des Usenet einlassen zu wollen, bat ich Qualifiziertere um ihren Beitrag. Die Resultate waren irgendwie durchwachsen. Es gab offensichlich nicht genügend Fallgeschichte um auf diesem Gebiet für Präzedens zu sorgen. Also, wenn Du Dich selbst in dieser Situation wiederfindest, solltest Du auf eine lange und kostspielige juristische Auseinandersetzung vorbereitet sein. Hast Du die Zeit und das Geld für solch einen Kampf? Bedenke auch, daß Richter große Freiheit haben bei der Auslegung der "Mißachtung des Gerichtes". Sie könnten Deine Inhaftierung beschließen, bis Du Dich dazu entschieden hast, Deinen Paßphrase mitzuteilen, und es kann Deinen Rechtsanwalt einige Zeit kosten, Dich herauszuholen (Wenn Du nur einfach ein schwaches Gedächtnis hättest!)

Schlüssel

Welche Schlüsselgröße soll ich benutzen?
Wieso braucht PGP so lange um einen neuen Schlüssel in meinen Schlüsselbund einzufügen?
Wie kann ich mehrere Schlüssel in eine einzige "Versandhülle" extrahieren?
Ich wollte die selbe Nachricht mehrfach für den den gleichen Empfänger verschlüsseln und habe völlig unterschiedliche Endergebnisse erzielt; wieso?
Wie bestimme ich, welcher Schlüssel benutzt werden soll, wenn ein und dieselbe Person zwei oder mehr öffentliche Schlüssel besitzt mit jeweils der gleichen User-ID, oder, wenn zwei verschiedene Personen den gleichen Namen tragen?
Was bedeutet die Meldung "Unterschreibender unbekannt, keine Prüfung" ("Unknown signator, can't be checked")?
Wie bringe ich PGP dazu, die "Vertrauensparameter" eines Schlüssels anzuzeigen?
Wie mache ich meinen Schlüssel über"Finger" bekannt?
Sollte ich meinen Schlüssel im Email-Footer (auch 'Signatur', nicht mit PGP-Signatur verrwechseln!) unterbringen?
Kann ein öffentlicher Schlüssel gefälscht werden?
Wie erkenne ich einen gefälschten Schlüssel?

4.1 Welche Schlüsselgröße soll ich benutzen?

PGP läßt Dir die Wahl zwischen 3 Möglichkeiten der Schlüssellänge: 512, 768 oder 1024 Bits. Du kannst auch eine Anzahl von Bits angeben, falls Dir keine dieser Zahlen gefällt. Je länger der Schlüssel, desto sicherer ist der RSA-Teil der Verschlüsselung. Der einzige Punkt, bei dem die Schlüssellänge für einen großen Unterschied in der Programmgeschwindigkeit sorgt,ist die Schlüsselerzeugung. Die Erzeugung eines 1024-Bit-Schlüssels kann achtmal länger dauern als die eines 384-Bit-Schlüssels. Glücklicherweise ist das ein einmaliger Vorgang, der nicht wiederholt wird, es sei denn, Du wünschst ein anderes Schlüsselpaar zu generieren.

Während der Verschlüsselung wird nur die RSA-Phase des Verschlüsselungsvorganges von der Schlüssellänge beeinflußt. Der RSA-Abschnitt wird nur dazu verwendet, den Sitzungsschlüssel, der von IDEA gebraucht wird, zu verschlüsseln. Der Hauptteil der Nachricht bleibt von der Wahl der RSA-Schlüssellänge völlig unberührt. Also, solange Du keinen sehr guten Grund hast, es anders zu machen, wähle die 1024-Bit-Schlüsselgröße. Unter Verwendung der aktuell verfügbaren Algorithmen zur Faktorisierung sind die 384- und 512-Bit-Schlüssel einfach nicht weit genug außer Reichweite, um gute Wahl zu sein.

Wenn Du MIT PGP 2.6.2, ViaCrypt PGP 2.7.1 oder PGP 2.6.3i benutzt, kannst Du Schlüssellängen über 1024 Bits angeben; die Obergrenze für diese Programme ist 2048 Bits. Vergiß nicht, daß Du PGP sagen mußt, wie groß Du Deinen Schlüssel haben willst, wenn er größer als 1024 Bits sein soll. Einen derart langen Schlüssel zu erzeugen, kann eine ganze Weile dauern; trotzdem, es ist, wie oben angemerkt, ein einmaliger Vorgang. Sei Dir im Klaren darüber, daß Leute, die andere PGP-Versionen verwenden, vielleicht nicht in der Lage sind, mit Deinem großen Schlüssel zu arbeiten.

Es gibt einen kleinen Fehler in manchen Ausgaben von MIT PGP 2.6.2, die tatsächlich einen 2047-Bit-Schlüssel kreieren, wenn Du eine 2048-Bit-Ausführung anweist.

4.2 Wieso braucht PGP so lange um einen neuen Schlüssel in meinen Schlüsselbund einzufügen?

Die Zeit, die benötigt wird, Signaturen zu überprüfen und Schlüssel in Deinen öffentlichen Schlüsselbund einzufügen, wächst beinahe mit dem Quadrat der Größe Deines bisherigen Schlüsselbundes. Das kann extreme Ausmaße annehmen, besonders, wenn Du versuchst, den gesamten Schlüsselbund, den Du von einem "Keyserver"(Schlüsselserver) geladen hast anzuhängen (siehe Frage 8.1).

In diesem Falle ist es vielleicht schneller, Deinen Schlüsselbund umzubenennen, dann den Schlüsselbund des Keyservers pubring.pgp zu nennen und Deinen eigenen Schlüsselbund an diesen großen Schlüsselbund anzuhängen. Darin liegt aber eine Gefahr: Die Vertrauensparameter Deiner alten Schlüssel werden verloren gehen, und Du wirst statt dessen die Vertrauensparameter des großen Schlüsselbundes benutzen.

4.3 Wie kann ich mehrere Schlüssel in eine einzige "Versandhülle" extrahieren?

Eine Anzahl von Menschen besitzen mehr als einen öffentlichen Schlüssel, die sie gerne zur Verfügung stellen wollen. Ein Weg dorthin ist, das Kommando "-kxa" für jeden Schlüssel anzuwenden, den Du aus dem Schlüsselbund in separate ASCII-Dateien extrahieren willst, dann die einzelnen Dateien in einer einzigen Datei mit mehreren ASCII-Blöcken zu vereinigen.

Leider erlaubt Dir die momentane Version von PGP nicht, das direkt zu tun. Glücklicherweise gibt es einen indirekten Weg:
pgp -kx uid1 extract
pgp -kx uid2 extract
pgp -kx uid3 extract

Das legt alle drei Schlüssel in extract.pgp. Um eine ASCII-Datei zu erhalten, starte "pgp -a extract.pgp"

Du erhälst extract.asc. Jemand, der ein "pgp extract" ausführt und eine der beiden Dateien besitzt, verarbeitet alle drei Schlüssel gleichzeitig.

Ein Unix-Skript, um die Extraktion mit einem einzigen Kommando auszuführen, würde folgendermaßen aussehen:
for name in name1 name2 name3 ...; do pgp -kx $name /tmp/keys.pgp <Schlüselbund>; end

Ein gleichwertiges DOS-Kommando wäre:
for %a in (name1 name2 name3 ...) do pgp -kx %a keys.pgp <Schlüsselbund>

4.4 Ich wollte die selbe Nachricht mehrfach für den den gleichen Empfänger verschlüsseln und habe völlig unterschiedliche Endergebnisse erziehlt; wieso?

Jedesmal, wenn Du PGP ausführst, wird ein anderer Sitzungsschlüssel generiert. Dieser Sitzungsschlüssel wird als Schlüssel für IDEA verwendet. Das hat zum Ergebnis, daß sich der ganze Header und Körper der Nachricht verändert. Du wirst niemals die gleiche Ausgabe zweimal sehen, egal wie oft Du die gleiche Nachricht für die gleiche Adresse verschlüsselst. Das trägt zusätzlich zur Gesamtsicherheit von PGP bei.

Um diesen zufälligen Sitzungsschlüssel zu erzeugen, wird PGP versuchen, Informationen aus einer Datei, die sich 'randseed.bin' nennt, zu benutzen. Sollte diese Datei nicht existieren, oder ihr Inhalt aus irgendeinem Grund nicht zufällig genug sein, wirst Du gebeten, ein paar zufällige Tastaturanschläge vorzunehmen, die dann als Startwert für den Zufallszahlengenerator dienen.

4.5 Wie bestimme ich, welcher Schlüssel benutzt werden soll, wenn ein und dieselbe Person zwei oder mehr öffentliche Schlüssel besitzt mit jeweils der gleichen User-ID, oder, wenn zwei verschiedene Personen den gleichen Namen tragen?

Anstatt den Usernamen im ID-Feld des PGP-Kommandos zu nennen, kannst Du die Schlüssel-ID-Nummer verwenden. Das Format ist 0xNNNNNNNN, wobei NNNNNNNN die achtstellige Schlüssel-ID-Nummer des Users ist. Es sollte beachtet werden, daß Du nicht die ganze Nummer eingeben mußt, ein paar aufeinanderfolgende Zeichen von irgendwo in der ID sollten genügen. Die Schlüssel-ID zeigt sich direkt hinter der Schlüsselgröße, wenn Du "pgp -kv UserID" ausführst.

Gib Acht: Wenn Du "0x123" eingibst, wirst Du die Schlüssel-IDs 0x12393764, 0x64931237 oder 0x96412373 treffen. Jede Schlüssel-ID, die "123" irgendwo enthält, wird eine Übereinstimmung liefern. Es müssen nicht die Anfangsziffern der Schlüssel-ID sein. Du wirst erkennen, daß dies das Eingabeformat für hexadezimale Zahlenwerte in der Programmiersprache C ist. Zum Beispiel kann jedes der folgenden Kommandos benutzt werden, um eine Datei mit meinem öffentlichen Schlüssel zu verschlüsseln:
pgp -e <filename> "Arnoud Engelfriet"
pgp -e <filename> galactus@stack.nl
pgp -e <filename> 0x416A1A35

Genau diese Methode der Schlüsselbestimmung kann in der "MyName"-Variablen der Datei CONFIG.TXT dazu verwendet werden, um exakt zu bestimmen, welcher Schlüssel des geheimen Schlüsselbundes für das Verschlüsseln einer Nachricht benutzt werden soll.

4.6 Was bedeutet die Meldung "Unterschreibender unbekannt, keine Prüfung" ("Unknown signator, can't be checked")?

Es bedeutet, daß der Schlüssel, der zur Erzeugung dieser Signatur verwendet wurde, nicht in Deinem öffentlichen Schlüsselbund existiert. Solltest Du irgendwann in der Zukunft diesen Schlüssel in Deinen Schlüsselbund einfügen, wird die Signaturzeile normal aussehen. Es ist absolut ungefährlich, diese nichtprüfbaren Signaturen in Deinem öffentlichen Schlüsselbund zu belassen. Weder tragen sie zur Gültigkeit des betroffenen Schlüssels bei, noch stellen sie sie in Frage.

4.7 Wie bringe ich PGP dazu, die "Vertrauensparameter" eines Schlüssels anzuzeigen

Du kannst das nur dadurch erreichen, daß Du die "-kc"-Option auf die gesamte Datenbank anwendest. Die Parameter werden nicht angezeigt, wenn Du eine bestimmte ID in der Kommandozeile angibst. Das korrekte Kommando ist: "pgp -kc". Das Kommando "pgp -kc smith" wird nicht die Vertrauensparameter für Smith zeigen.

4.8 Wie mache ich meinen Schlüssel über "Finger" bekannt?

Der erste Schritt ist immer, den Schlüssel mit "pgp -kxa" in eine ASCII-Textdatei zu extrahieren. Danach kommt es darauf an, auf welcher Art von Computer Du Deinen Schlüssel verfügbar machen willst. Schaue Dir die Dokumentation für diesen Computer und/oder für die Netzwerksoftware an.

Viele Computer, die unter einer Unix-Version laufen, werden Informationen, die über Finger angezeigt werden sollen, aus einer Datei im Stammverzeichnis des Nutzers lesen, die "plan" heißt. Wenn Dein Computer das unterstützt, kannst Du Deinen öffentlichen Schlüssel in dieser Datei ablegen. Stelle sicher, daß die Datei "world-readable" ist, benutze "chmod 644 .plan", wenn andere Leute nicht auf Dein "plan" zugreifen können. Auch Dein Stammverzeichnis muß zugänglich sein. Benutze "chmod +x ." in Deinem Stammverzeichnis, um das zu bewerkstelligen. Wende Dich an Deinen Systemadministrator, wenn Du damit weiterhin Probleme hast.

4.9 Sollte ich meinen Schlüssel im Email-Footer (auch 'Signatur', nicht mit PGP-Signatur verrwechseln!) unterbringen?

Nein. Obwohl es wichtig ist, Deinen Schlüssel so weit wie möglich zu verbreiten, ist es weit besser, ihn an einen Keyserver zu schicken (siehe 8.1), über Finger zugänglich zu machen (siehe 4.8), oder vielleicht als Link auf Deiner WWW-Homepage. Auf diese Weise werden Menschen, die Deinen Schlüssel benötigen, in die Lage versetzt, ihn sich zu besorgen, und Du sendest ihn nicht an eine Menge uninteressierter Leute, jedesmal, wenn Du etwas mailst oder postest.

Beachte außerdem, daß ein Schnüffler, der Deine abgehende Post liest, mit Leichtigkeit den darin enthaltenen Schlüssel gegen seinen eigenen gefälschten Schlüssel austauschen kann. Dann kann er auch noch die Nachrichten lesen, die an Dich gesendet wurden. Wenn die andere Seite Deinen Schlüssel von anderswo, auf anderem Wege bekommt, ist es schwerer für den Schnüffler, die Schlüssel zu vertauschen (Beachte, daß die Unterschrift unter der Nachricht mit dem Schlüssel Dir nicht weiterhelfen wird; der Schnüffler kann die Nachricht leicht nocheinmal mit seinem eigenen Schlüssel unterschreiben).

4.10 Kann ein öffentlicher Schlüssel gefälscht werden?

Es gibt vier Komponenten in einem öffentlichen Schlüssel und jede von ihnen hat ihre eigenen Schwächen. Die vier Komponenten sind: User-IDs, Schlüssel-IDs, Unterschriften und der Key-Fingerprint(Fingerabdruck).

Die User-ID

Es ist ziemlich einfach, eine gefälschte User-ID zu erstellen. Wenn eine User-ID in einem Schlüssel verändert wird, und der Schlüssel dann in einen anderen Schlüsselbund eingefügt wird, wird die veränderte User-ID als neue User-ID angesehen und den bereits vorhandenen hinzugefügt. Das impliziert, daß einer unsignierten User-ID niemals vertraut werden sollte. Frage 6.3 erläutert das detaillierter.

Die Schlüssel-ID

Es ist möglich, einen Schlüssel mit einer bestimmten Schlüssel-ID zu kreieren. Paul Leyland <pc@sable.ox.ac.uk> erklärt:

Eine PGP-Schlüssel-ID entspricht einfach den unteren 64 Bits des öffentlichen Modules (aber nur die untersten 32 Bits werden mit "pgp -kv" angezeigt). Es ist leicht, zwei Primzahlen auszusuchen, die, wenn sie miteinander multipliziert werden, eine spezielle Anordnung niederwertiger Bits besitzen.

Das macht es möglich, einen gefälschten Schlüssel mit der gleichen Schlüssel-ID wie ein schon existierender zu erzeugen. Der Fingerabdruck wird aber immernoch anders sein.

Übrigens wird diese Attacke manchmal als DEADBEEF-Attacke bezeichnet. Der Ausdruck rührt von einem Beispiel-Schlüssel mit der Schlüssel-ID 0xDEADBEEF her, der erzeugt worden war, um zu demonstrieren, daß dies möglich ist.

Unterschriften

Es gibt derzeit keine Methoden, gefälschte Signaturen für eine User-ID in jemands Schlüssel zu erzeugen. Um eine Signatur für eine User-ID zu kreieren, brauchst Du den geheimen Schlüssel des Unterschreibenden. Eine Signatur unterzeichnet tatsächlich einen Hash der User-ID, auf den er sich bezieht, so daß Du keine Signaturen von einer User-ID zu einer anderen verschieben oder eine unterschriebene User-ID verändern kannst, ohne die Signatur zu entwerten.

Der Key-Fingerprint (Fingerabdruck)

Ja, es ist möglich, einen öffentlichen Schlüssel zu erzeugen, mit dem selben Fingerabdruck wie ein bereits existierender,-dank eines Gestaltungsfehlers in PGP. Der gefälschte Schlüssel wird nicht die gleiche Länge haben, daher sollte er leicht zu entdecken sein. Gewöhnlich besitzen solche Schlüssel ungewöhnliche Schlüssellängen.

Paul Leyland lieferte die folgende technische Erklärung:

Im Inneren eines PGP-Schlüssels werden der öffentliche Modulus und der Verschlüsselungs-Exponent repräsentiert durch die Bit-Laenge der jeweiligen Zahl und die Zahl selbst in Bits. Der Key-Fingerprint, der mit "pgp -kvc" angezeigt wird, ist der MD5-Hash der Bits, aber nicht der Länge. Durch Transfer der niederwertigen Bits des Modulus in den höherwertigen Bereich des Exponenten und entsprechende Abänderung der Längen ist es möglich, einen neuen Schlüssel mit exakt dem gleichen Fingerprint zu erzeugen.

4.11 Wie erkenne ich einen gefälschten Schlüssel?

Wie in Frage 4.10 erklärt, kann jede Komponente des öffentlichen Schlüssels gefälscht werden. Es ist dennoch nicht möglich, einen falschen Schlüssel zu erzeugen, bei dem alle Bestandteile zusammenpassen.

Aus diesem Grunde solltest Du immer nachprüfen, ob Schlüssel-ID, Fingerprint und Schlüsselllänge übereinstimmen, wenn Du dabei bist jemands Schlüssel zu verwenden. Und wenn Du einen Schlüssel unterzeichnest, stelle sicher, daß er vom Schlüsselinhaber unterschrieben ist!

Entsprechend, wenn Du Informationen über Deinen Schlüssel liefern willst, schließe Schlüssel-ID, Fingerprint und Schlüssellänge mit ein.

Signieren von Nachrichten

Was bedeutet Signieren von Nachrichten?
Wie signiere ich eine Nachricht und erhalte ihre Lesbarkeit?
Kann man eine Signatur nicht einfach fälschen, indem man den Signaturblock an eine andere Nachricht anhängt?
Sind PGP-Signaturen rechtsverbindlich?
Ist das Datum einer PGP-Signatur verläßlich?

5.1 Was bedeutet Signieren von Nachrichten?

Laß uns annehmen, daß Du mit der Post einen Brief von jemandem erhälst, den Du als John Smith kennst. Wie weißt Du, daß es wirklich John war, der Dir den Brief gesandt hat und nicht jemand anders, der einfach seinen Namen verfälscht hat?

Mit PGP kann für eine Nachricht eine digitale Signatur erzeugt werden, die unmöglich zu fälschen ist. Wenn Du bereits eine vertrauenswürdige Kopie von Johns öffentlichem Schlüssel besitzt, kannst Du sie verwenden, um die Signatur der Nachricht zu testen. Jedem außer John wäre es unmöglich gewesen, die Signatur zu erzeugen, da er die einzige Person mit Zugang zu seinem geheimen Schlüssel ist, der nötig war, um die Signatur zu erstellen. Außerdem-, sollte sich irgendjemand an einer sonst intakten Nachricht zu schaffen gemacht haben, würde die digitale Signatur das entdecken. Sie schützt die gesamte Nachricht.

5.2 Wie signiere ich eine Nachricht und erhalte ihre Lesbarkeit?

Manchmal bist Du nicht daran interessiert, den Inhalt einer Nachricht geheim zu halten, nur willst Du vermeiden, daß irgend jemand daran herumpfuscht, und anderen erlauben, festzustellen, daß die Nachricht wirklich von Dir kommt. Dazu kannst Du "Clearsigning" (Klartext-Signieren) verwenden. Clearsigning geht nur bei Textdateien, es wird nicht mit Binärdateien funktionieren. Das Kommandozeilenformat ist: "pgp -sat +clearsig=on <Dateiname>"

Die Ausgabedatei wird neben Deinem unveränderten Text Absatzkennungen und eine ASCII-codierte PGP-Signatur enthalten. In diesem Fall ist PGP zum Lesen der Datei nicht erforderlich, nur zur Überprüfung der Signatur.

Du solltest darauf achten, wann Du eine Textdatei auf diese Weise "klartext-signierst". Einige Mail-Programme können Deine Nachricht verändern, wenn sie versendet wird, zum Beispiel, weil in der Nachricht sehr lange Zeilen vorkommen. Das würde die Signatur für die Nachricht wertlos machen. Außerdem kann die Verwendung von 8-bit-Zeichen in Deiner Nachricht Probleme verursachen; einige PGP-Versionen werden glauben, die Datei sei tatsächlich eine Binärdatei und sich weigern, sie zu "clearsign-en".

Aus diesem Grunde wird PGP 2.6.3i Nachrichten die sehr lange Zeilen enthalten, automatisch ASCII-codieren. PGP 2.6.3ia behebt diesen unpraktikablen Fehler.

5.3 Kann man eine Signatur nicht einfach fälschen, indem man den Signaturblock an eine andere Nachricht anhängt?

Nein. Der Grund dafür ist, daß die Signatur Informationen ("message-digest"=Kurze Zusammenfassung oder "one-way-hash" genannt,) über die Nachricht, auf die sie sich bezieht, enthält. Wenn die Signaturprüfung erfolgt, wird der message-digest aus der Nachricht ausgerechnet und mit dem im verschlüsselten Signaturblock gespeicherten verglichen. Sollten sie nicht übereinstimmen, meldet PGP, daß die Unterschrift ungültig ist.

5.4 Sind PGP-Signaturen rechtsverbindlich?

Mittlerweile sind sie vielerorts legal geworden. Mindestens eine Gesellschaft benutzt digitale PGP-Signaturen in Verträgen, um schnelle Abschlüsse über Email zu erzielen, was es erlaubt, die Arbeit aufzunehmen, ohne auf unterschriebene Papiere warten zu müssen.

In den USA faßte der Staat Utah am 27. Februar 1995 seinen Signatur-Beschluß. Er wurde von Michael Leavitt,dem Gouverneur von Utah, am 9. März 1995 unterschrieben und am 1. Mai 1995 in Kraft gesetzt. Utah war weltweit das erste Rechtssystem, das eine umfassende Vorschrift einführte, die elektronischen Handel mittels digitaler Signaturen ermöglichte. Danach wurde das Amendment von 1996, am 29. April 1996, wirksam.

Das Utah-Gesetz kann auf http://www.commerce.state.ut.us/web/commerce/digsig/dsmain.htm eingesehen werden.

Andere US-amerikanische Staaten arbeiten ebenfalls daran, diese Technologie für den Handel zu integrieren, wie Georgia, Washington, Illinois, u.a. Abgesehen von Utah haben momentan auch Kalifornien und Virginia Gesetzesvorlagen oder Gesetze, die die Technik ermöglichen.

Das Georgia-Gesetz findest Du hier: http://www.cc.emory.edu/business/gds.html

Das Washington-Gesetz findest Du auf: http://access.wa.net/sp6423_info/index.html

(In der BRD gibt es eine Vorlage des "Gesetzes zur digitalen Signatur", die vermutlich noch 1997 verabschiedet wird. Sie enthält den die Feststellung: "die Verwendung anderer Verfahren ist freigestellt", was wohl bedeutet, daß grundsätzlich auch PGP-Signaturen verwendet werden können.)

In einigen Rechtsprechungen ist eine vorherige Übereinkunft, indem man schreibt, daß digitale Signaturen als bindend akzeptiert werden, selbst bindend. Wenn Du beabsichtigst, viele digital unterzeichnete Abmachungen mit einer weiteren Partei auszutauschen, könnte dieser Ansatz nützlich sein. Du solltest vielleicht vorher mit einem Rechtsanwalt in Deinem Land abklären, ob die digitalen Signaturen für wichtige oder wertvolle Verträge benutzt werden.

5.5 Ist das Datum einer PGP-Signatur verläßlich?

Nein. Das Datum und die Zeit, die Du siehst, wenn Du die PGP-Signatur einer Datei überprüfst, (oft "timestamp"=Zeitstempel genannt), sind die Zeit und das Datum, auf die der Computer eingestellt war, als die Signatur erzeugt wurde. Bei den meisten Computern ist es extrem einfach, Datum und Zeit auf jeden Zeitpunkt einzustellen, den Du willst, so daß Du Dokumente mit falschen Zeitstempeln kreieren kannst.

Deshalb kannst Du einen sogenannten digitalen Notar oder Zeitstempel-Service in Anspruch nehmen. Dieser Dienst tut nichts anderes, als Dokumente, die Du ihm sendest, zu unterschreiben, nachdem ein Datum und eine Zeit irgendwo im Text untergebracht worden sind. Der Dienst benutzt ein Nummerierungsschema, das es unmöglich macht, Zeitstempel für einen späteren Zeitpunkt einzufügen. Ein solcher Service wird von Matthew Richardson betrieben. Um mehr Informationen darüber zu erhalten, schau Dir http://www.itconsult.co.uk/stamper.htm an.

Schlüssel-Zertifikate

Was bedeutet Schlüsselzertifizierung?
Wie zertifiziere ich einen Schlüssel?
Sollte ich meinen eigenen Schlüssel unterschreiben?
Sollte ich anderer Leute Schlüssel unterschreiben?
Wie stelle ich die Identität einer Person fest?
Woher weiß ich, daß mir jemand nicht einen nachgemachten Schlüssel sendet?
Was ist eine "Schlüsselzertifizierungs-Party"?
Wie organisiere ich eine Schlüsselzertifizierungs-Party?

6.1 Was bedeutet Schlüsselzertifizierung?

Ok, Du hast gerade eine Kopie von John Smith's öffentlichem Schlüssel erhalten. Wie weißt Du, daß der Schlüssel wirklich John Smith und nicht zu irgendeinem Schwindler gehört? Die Antwort darauf sind Schlüsselzertifikate. Sie sind den Nachrichten-Signaturen darin ähnlich, daß sie nicht gefälscht werden können. Laß uns behaupten, Du wüßtest nicht, daß Du John Smiths echten Schlüssel besitzt. Aber laß uns annehmen, daß Du Joe Blo vertraust, and daß er seine Signatur John Smiths Schlüssel zugefügt hat. Folglich kannst Du nun sicher sein, eine echte Kopie von John Smiths Schlüssel zu besitzen. Das ist es, was die ganze Schlüsselzertifizierung ausmacht.

Diese Kette des Vertrauens kann auf verschiedene Niveaus ausgedehnt werden, in etwa: A vertraut B der C vertraut, der D vertraut; daher kann A D trauen. Du hast in der PGP-Konfigurationsdatei die Kontrolle darüber, über wieviele Niveaus Du diese Kette des Vertrauens wirken läßt.

Die Einstellungen (die in der PGP-Konfigurationsdatei Config.txt gesetzt werden können) sind

"Cert_Dept = n": Schachtelungstiefe von Unterschriften Das gibt die maximale Ausdehnung Deines "Web of trust" (Netz des Vertrauens) an. Ein Schlüssel, der n Schlüssel von Deinem eigenen entfernt ist, wird nicht benutzt um andere Schlüssel einzuführen.
"Completes_Needed = n": Anzahl der erforderlichen voll vertrauenswürdigen Unterschriften Dies legt die Anzahl der voll vertrauenswürdigen Schlüssel fest, deren Unterschriften nötig sind, um einen Schlüssel für gültig zu erklären. Ein Schlüssel ist voll vertrauenswürdig, wenn er gültig ist und Du die Auswahlmöglichkeit "4. Yes, always" gewählt hast, sobald PGP danach fragt, ob Du dieser Person genügend vertraust, daß sie andere einführen kann.
"Marginals_Needed = n": Anzahl der erforderlichen teilweise vertrauenswürdigen Unterschriften Hier wird die Anzahl der bedingt vertrauenswürdigen Schlüssel festgelegt, deren Unterschriften einem Schlüssel Gültigkeit verleien. Ein Schlüssel ist bedingt vertrauenswürdig, wenn Du mit "3. Sometimes" auf die obige Frage antwortest. In allen anderen Fällen, wird dem Schlüssel überhaupt nicht vertraut.

Du zeigst die Anzahl der Vertrauensparameter für einen Schlüssel mit "pgp -kc" an. Siehe auch Frage 4.7. Sei vorsichtig mit Schlüsseln, die sich einige Ebenen weit abseits Deines unmittelbaren 'Vertrauens' befinden.

Das PGP-Vertrauensmodell wird detaillierter von Alfarez Abdul-Rahman behandelt, auf http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/docs/.

6.2 Wie zertifiziere ich einen Schlüssel?

Führe das folgende Kommando an der Eingabeaufforderung aus:
"pgp -ks [-u User-ID] <Schlüssel-ID>"

Das ergänzt den Schlüssel, der Durch die Schlüssel-ID identifiziert wird, um Deine Unterschrift (die Unterschrift, die der geheime Schlüssel der User-ID erzeugt, wenn Du sie angibst). Sollte Schlüssel-ID eine User-ID sein, signierst Du genau diese User-ID; andernfalls unterschreibst Du die Standard-User-ID des Schlüssels (die erste, die Du siehst, wenn Du den Schlüssel mit "pgp -kv <Schlüssel-ID>" aufrufst.)

Als Nächstes solltest Du mit der "-kxa"-Option eine Kopie dieses aktualisierten Schlüssels zusammen mit seinen Signaturen erzeugen. Eine ASCII-Textdatei wird erstellt. Gib diese Datei dem Besitzer des Schlüssels, so daß er die neuen Zertifikate verbreiten kann, wo immer er möchte.

Achte auf Deinen geheimen Schlüsselbund. Laß Dich niemals dazu verleiten, eine Kopie davon auf den Computer eines Anderen zu laden, um seinen öffentlichen Schlüssel zu signieren - er könnte PGP modifiziert haben, um Deinen geheimen Schlüssel zu kopieren und Deinen Paßphrase aufzufangen.

6.3 Sollte ich meinen eigenen Schlüssel unterschreiben?

Ja, Du solltest jede persönliche ID an Deinem Schlüssel signieren. Das wird dabei helfen, jedermann davon abzuhalten, eine gefälschte Adresse im ID-Feld des Schlüssels unterzubringen und Deine Post an ihn umzuleiten. Natürlich können sie die verschlüsselte Post nicht lesen, aber Du wirst sie überhaupt nicht zu sehen bekommen.

Sogar schlimmer; eine falsche User-ID, wie: "Bitte benutze ab jetzt Schlüssel 0x416A1A35" kann bedeuten, daß jemand anders eher den Schlüssel des Schwindlers mit Deinem Namen darin, als Deinen eigenen verwendet.

Es ist sehr einfach, in einen fremden Schlüssel User-IDs einzufügen. Alles was nötig ist, ist ein Binäreditor oder gewisse Kenntnisse über das Format der öffentlichen PGP-Schlüssel. Aber weil Du die einzige Person bist, die Deine eigene User-ID unterschreiben kann, werden die vorgetäuschten nicht unterschrieben sein, und somit fallen jedem, der den Schlüssel erhält, die gefälschten IDs auf. Zum Beispiel sieht mein Eintrag im öffentlichen Schlüssel im Moment folgendermaßen aus, wenn Du das "-kvv" -Kommando ausführst:

Type Bits/KeyID  Date    User ID
pub 1024/416A1A35 1994/10/01 Arnoud Engelfriet <galactus@stack.nl>
sig   416A1A35       Arnoud Engelfriet<galactus@stack.nl>
              ***<galactus@stack.urc.tue.nl> now INVALID!
sig   416A1A35      Arnoud Engelfriet <galactus@stack.nl>
              Galactus <galactus@stack.urc.tue.nl>
sig   3602A619      Stephen Hopkins <shopkins@coventry.ac.uk>
sig   DD63EF3D      Frank Castle <Frank_Castle@panther.pphost.nl>
sig   416A1A35      Arnoud Engelfriet <galactus@stack.nl>
              Arnoud Engelfriet <galactus@stack.urc.tue.nl>
sig   390E3FB1      Martijn Heemels <M.A.L.Heemels@stud.tue.nl>
sig   DA87C0C7      Edgar W. Swank  <EdgarSwank@Juno.com>
sig   416A1A35      Arnoud Engelfriet <galactus@stack.nl>

Für eine detailliertere Abhandlung darüber, warum Du Deinen eigenen Schlüssel unterschreiben solltest, siehe "Why you should sign your own key" von Walther Soldier auf http://www.stack.nl/~galactus/remailers/selfsign.html.

Beachte, daß PGP 2.6.3[i] automatisch jede User-ID signiert, um die Du Deinen eigenen Schlüssel erweiterst.

6.4 Sollte ich anderer Leute Schlüssel unterschreiben?

Das Signieren des Schlüssels einer anderen Person ist Deine Erklärung an die Welt, daß Du glaubst, daß der Schlüssel rechtmäßig dieser Person gehört, und sie derjenige ist, der sie zu sein vorgibt. Andere Menschen können auf Deine Unterschrift vertrauen um zu entscheiden, ob ein Schlüssel gültig ist oder nicht; daher solltest Du nicht launenhaft unterschreiben.

Einige Länder benötigen angesehene Berufsstände, wie Ärzte oder Ingenieure zur Beglaubigung von Paßfotos als Beweis der Identität bei einem Ausweisantrag - Du solltest die Zertifizierung der Schlüssel anderer Leute unter dem gleichen Licht betrachten. Oder frage Dich selbst, ob Du darauf vorbereitet wärst, vor einem Gericht die Identität dieser Person zu beschwören.

Merke Dir, daß das Signieren des Schlüssels einer Person nichts darüber aussagt, ob Du diese Person gerne magst, ihr vertraust oder ihre Handlungen billigst. Es ist, als ob jemand auf einer Party auf jemand anderen weist und sagt, "Ja, das ist Joe Blow dort drüben." Joe Blow kann ein Axtmörder sein; dieses Verbrechen wird Dir nicht angelastet, bloß weil Du ihn in einer Menge erkennst.

6.5 Wie stelle ich die Identität einer Person fest?

Das hängt davon ab, wie gut Du sie kennst. Verwandte, Freunde und Kollegen sind einfach. Leute, die Du auf Versammlungen oder Schlüsselzertifizierungsparties triffst, erfordern gewisse Beweise, wie Personalausweis, Fahrerlaubnis oder Kreditkarte.

6.6 Woher weiß ich, daß mir jemand nicht einen nachgemachten Schlüssel sendet?

Es ist sehr einfach für jemanden, einen Schlüssel mit falscher ID zu generieren und Emails mit betrügerischen Headern zu versenden, oder zu einem Knoten, der die Email an Dich leitet um einen anderen Schlüssel zu ersetzen. Finger-Server zu manipulieren ist komplizierter aber nicht unmöglich. Die Schwierigkeit ist, während der Austausch öffentlicher Schlüssel keinen sicheren Kanal braucht (Mithören ist nicht problematisch), bedarf es eines gegen Manipulation geschützten Kanals (Schlüsselaustausch ist ein Problem).

Wenn es ein Schlüssel von Leuten ist, die Du gut kennst und deren Stimme Du erkennst, dann genügt es, sie anzurufen und ihren Fingerprint vorlesen zu lassen (erhält man mit "pgp -kvc <User-ID>"). Um sicher zu sein, frage sie auch nach der Schlüssellänge und Schlüssel-ID. Es gibt Wege, gefälschte Schlüssel mit identischen Fingerprints zu kreieren (siehe Frage 4.10 für Details). Du kannst diese Einzelheiten natürlich auch auf anderem Wege testen, zum Beispiel, wenn sie auf jemands Visitenkarte gedruckt sind.

Wenn Du die Person nicht sehr gut kennst, dann ist der einzige Ausweg, Schlüssel Auge in Auge auszutauschen und um einem Beweis der Identität zu bitten. Laß Dich nicht dazu verleiten, Deine Diskette mit öffentlichen Schlüsseln in anderer Leute Maschine einzulegen, damit sie ihren Schlüssel hinzufügen können - sie könnten gleichzeitig Deinen Schlüssel heimtückisch austauschen. Wenn die User-ID eine Email-Adresse enthält, überprüfe diese Adresse, indem eine vereinbarte, verschlüsselte Nachricht ausgetauscht wird, bevor Du unterschreibst. Zertifiziere keine User-ID in diesem Schlüssel, außer denen, die Du nachgeprüft hast.

6.7 Was ist eine "Schlüsselzertifizierungs-Party"?

Eine Schlüsselzertifizierungs-Party (Key Signing Party) ist das Zusammenkommen mit verschiedenen anderen Benutzern von PGP zum Zwecke der Begegnung und zum Unterschreiben von Schlüsseln. Sie hilft, das Netz des Vertrauens in großem Maße zu erweitern.

6.8 Wie organisiere ich eine Schlüsselzertifizierungs-Party?

Obwohl die Idee simpel ist, ist die Durchführung ein wenig kompliziert, weil Du anderer Leute geheime Schlüssel nicht preisgeben und keine Viren verbreiten möchtest (was wohl oder übel immer ein Risiko ist, wenn Disketten ausgetauscht werden). Normalerweise schließen diese Parties ein, daß man alle auf der Party trifft, ihre Identitäten überprüft, ihre Fingerprints erhält und ihre Schlüssel zu Hause signiert.

Derek Atkins <warlord@mit.edu> hat diese Methode empfohlen:

Es gibt viele Wege eine Schlüsselzertifizierungs-Sitzung abzuhalten. Viele brauchbare Vorschläge wurden gemacht. Und, nur um dieser Newsgroup mehr Signalwirkung zu verleihen, werde ich einen weiteren vorschlagen, der ganz gut zu funktionieren scheint und auch das "N-Quadrat-Problem" der Verteilung und Zertifizierung der Schlüssel löst ("N" Schlüssel müssen an "N" User verteilt werden).
Folgendermaßen ist der Ablauf:

Du kündigst die Schlüsselzertifizierungs-Sitzung an und bittest jeden, der zu kommen plant, Dir (oder einer Einzelperson, die anwesend sein wird) seinen öffentlichen Schlüssel zu schicken. Die Bitte um Bestätigung erlaubt auch die Anzahl der Leute für Schritt 3 zu ermitteln
Du trägst die öffentlichen Schlüssel in einem einzigen Schlüsselbund zusammen, wendest "pgp -kvc" auf diesen Schlüsselbund an und sicherst das Ergebnis in einer Datei.
Fertige N Kopien der "pgp -kvc"-Datei als Hardcopy an und bringe diese, sowie den Schlüsselbund auf Datenträgern zum Treffen mit.
Auf dem Treffen verteile die Ausdrucke und stelle eine Anlaufstelle zum Herunterladen des Schlüsselbundes zur Verfügung. (Eine FTP-Adresse tut es, oder Du kannst Kopien auf Diskette anfertigen oder was auch immer, das ist gleichgültig).
Wenn alle im Raum sind, steht jede Person auf, und andere Leute bürgen für diese Person (z.B.:"Ja, das ist wirklich Derek Atkins - ich bin mit ihm sechs Jahre lang zur Schule gegangen und habe zwei Jahre lang mit ihm zusammengewohnt").
Jede Person erhält gesichert ihren eigenen Fingerprint (falls sie ihn nicht selbst noch einmal mitgebracht hat) und nachdem für sie gebürgt worden ist, liest sie ihn laut vor, damit jeder ihn auf dem Ausdruck, der ihm vorliegt überprüfen kann.
Nachdem alle dieses Protokoll beendet haben, können sie heimgehen, ihren Schlüsselbund empfangen, selbst "pgp -kvc" darauf anwenden, die Bits nocheinmal abgleichen und die Schlüssel unterschreiben, wenn es ihnen paßt.
Um die unterschriebenen Schlüssel sicher auf den Schlüsselserver zu laden, kannst Du optional alle Signaturen an den Initiator senden, der sie wiederum in einem einzigen Schlüsselbund zusammenfaßt und diesen einzelnen Schlüsselbund an den Schlüsselserver und jede Einzelperson verteilen kann.

Zurückziehen eines Schlüssels

Mein privater Schlüssel wurde gestohlen oder ging verloren, was soll ich tun?
Ich habe meinen Paßphrase vergessen. Kann ich meinen Schlüssel zurückziehen?
Wie erzeuge ich ein Key Revocation Certificate?
Wie mache ich publik, daß mein Schlüssel ungültig ist, wenn ich den privaten Schlüssel nicht mehr besitze?

7.1 Mein privater Schlüssel wurde gestohlen oder ging verloren, was soll ich tun?

Vorausgesetzt, daß Du einen guten, soliden und zufälligen Paßphrase ausgesucht hast, um Deinen geheimen Schlüsselbund zu verschlüsseln, bist Du wahrscheinlich immernoch sicher. Es braucht zwei Komponenten, um eine Nachricht zu entschlüsseln, den geheimen Schlüsselbund und seinen Paßphrase. Der geheime Schlüssel wird mit dem Paßphrase verschlüsselt, bevor er im geheimen Schlüsselring gesichert wird.

Angenommen, Du besitzt eine Sicherheitskopie Deines geheimen Schlüsselringes, dann solltest Du ein "Key Revocation Certificate" (Schlüsselwiderrufserklärung) generieren und auf einen der öffentlichen Schlüsselserver laden. Bevor Du das Revocation Certificate hochlädst, könntest Du dem alten Schlüssel eine neue ID hinzufügen, die aussagt, wie Deine neue Schlüssel-ID lauten wird. Solltest Du keine Sicherheitskopie Deines geheimen Schlüsselringes haben, wird es mit der gegenwärtigen Version von PGP unmöglich sein, ein Revocation Certificate zu erzeugen. Das ist ein weiterer, guter Grund, eine Sicherheitskopie Deines geheimen Schlüsselringes aufzubewahren.

7.2 Ich habe meinen Paßphrase vergessen. Kann ich meinen Schlüssel zurückziehen?

In der Art, wie es Phil Zimmermann ausgedrückt hat:" Es tut mir leid, Du bist angeschmiert."

Du kannst es nicht, weil der Paßphrase benötigt wird, um die Widerrufserklärung zu erzeugen. Du mußt den geheimen Schlüssel entschlüsseln, um die Erklärung zu unterzeichnen und dazu brauchst Du den Paßphrase.

Der Weg, dieses Dilemma zu vermeiden besteht darin, zur gleichen Zeit, wie Dein Schlüsselpaar, auch ein Key Revocation Certificate zu erstellen. Lege die Widerrufserklärung an einem sichern Ort ab und sie wird Dir zur Verfügung stehen, sollte die Notwendigkeit entstehen.

7.3 Wie erzeuge ich ein Key Revocation Certificate?

Am einfachsten geht das folgendermaßen:

Erzeuge eine Sicherungskopie Deiner öffentlichen und geheimen Schlüsselringe.
Widerrufe Deinen Schlüssel mit "pgp -kd Deine_Benutzer_ID"
Extrahiere den zurückgezogenen Schlüssel mit "pgp -kxa Deine_Benutzer_ID" in eine Datei.
Speichere die Wiederrufserklärung an einer sicheren Stelle, zum Beispiel auf einer Diskette, die Du andernorts aufbewahren kannst.
Stelle die gesicherten Schlüsselringe wieder her.

7.4 Wie mache ich publik, daß mein Schlüssel ungültig ist, wenn ich den privaten Schlüssel nicht mehr besitze?

Das ist eine ziemlich vertrackte Situation und sollte unter allen Umständen vermieden werden. Am einfachsten bereitest Du ein Key Revocation Certificate vor (Siehe 7.3 für die Details darüber, wie man das macht), bevor Du es brauchst, so daß Du jederzeit Deinen Schlüssel zurückziehen kannst, sogar ohne Deinen geheimen Schlüssel.

Alternativ kannst Du einen Binär-Editor verwenden, um eine der User-IDs im öffentlichen Schlüssel so zu verändern, daß er lautet: "Key invalid; use key 0x12345678" (Schlüssel ungültig; benutze Schlüssel <Schlüssel-ID>) oder etwas mit dem gleichen Effekt. Behalte im Gedächtnis, daß die neue User-ID nicht länger als die alte sein kann, es sei denn, Du weißt, was Du tust. Dann extrahiere den Schlüssel und sende ihn zum Schlüsselserver. Er wird davon ausgehen, es handele sich um eine faktisch neue User-ID und sie Deinem dortigen Schlüssel hinzufügen.

Dennoch, weil jeder wie gerade beschrieben vorgehen kann, werden viele Menschen unzertifizierten User-IDs mit solchen Aussagen nicht trauen. Wie in Frage 6.3 beschrieben, sollten alle User-IDs an Deinem Schlüssel von Dir selbst unterschrieben sein. Also nocheinmal: Fertige vorab ein Key Revocation Certifificate an und benutze es, wenn nötig.

Öffentliche Schlüsselserver (public key servers)

Was sind öffentliche Schlüsselserver?
Welche öffentlichen Schlüsselserver gibt es?
Wie lautet die Syntax der Schlüsselserver-Kommandos?

8.1 Was sind öffentliche Schlüsselserver?

Öffentliche Schlüsselserver existieren zu dem Zweck, Deinen öffentlichen Schlüssel in einer gewöhnlichen Datenbank zugänglich zu machen, wo er für jedermann verfügbar ist, um Nachrichten an Dich zu verschlüsseln. Jeder, der Dir eine Nachricht schicken will, oder die Unterschrift unter einer Nachricht von Dir überprüfen möchte, kann Deinen Schlüssel vom Schlüsselserver bekommen, so daß er Dich damit nicht behelligen muß.

Während eine Reihe von Schlüsselservern existiert, ist es lediglich erforderlich, Deinen Schlüssel an einen von ihnen zu schicken. Der Schlüsselserver wird sich darum kümmern, Deinen Schlüssel an alle anderen, bekannten Server zu senden.

8.2 Welche öffentlichen Schlüsselserver gibt es?

Es gibt jetzt eine einfache Schnittstelle für Schlüsselserver. Die pgp.net-Domäne wurde zu diesem Zwecke geschaffen und bietet eine einfachen und schnellen Weg, um an die öffentlichen Schlüssel von Leuten zu gelangen.

Du kannst über Email auf den Schlüsselserver zugreifen, indem Du eine Email an pgp-public-keys@keys.pgp.net schreibst mit dem Kommando (siehe 8.3 weiter unten) in der Subject-Zeile Deiner Nachricht. Diese Nachricht wird zu einem zufällig ausgewählten Schlüsselserver geleitet, was sicherstellt, daß ein einzelner Server nicht überlastet wird.

Solltest Du Zugang zum WWW haben, kannst Du auch die WWW-Oberfläche auf http://www.uk.pgp.net/pgpnet/pks-commands.html benutzen.

FOUR11 zertifiziert keine Schlüssel mehr. Version 1.3 dieser FAQ behauptete fälschlicherweise, daß Pobox zertifizieren würde, dies ist jedoch nach Aussagen des Kundendienstes falsch.

8.3 Wie lautet die Syntax der Schlüsselserver-Kommandos?

Der Schlüsselserver erwartet eines der folgenden Kommandos im Subject-Feld. Beachte, daß nur das ADD-Kommando den eigentlichen Nachrichtenkörper braucht.

ADD: Dein öffentlicher Schlüssel (Der aufzunehmende Schlüsel ist der Nachrichtenkörper).
INDEX: Liste alle PGP Schlüssel, über die der Server Kenntnis hat. (-kv)
VERBOSE INDEX: Liste alle PGP Schlüssel, ausführliches Format (-kvv)
GET: Sende den gesamten Schlüsselring (-kxa *), in mehreren Teilen
GET <userid>: Sende nur diesen einen Schlüssel (-kxa <userid>)
MGET <userid>: Sende alle Schlüssel, mit Entsprechungen im Ausdruck <userid>
LAST <n>: Sende alle Schlüssel, die während der letzten <n> Tage hochgeladen wurden.

Beachte, daß Du anstelle einer User-ID auch eine Schlüssel-ID nennen kannst. In diesem Falle solltest Du "0x" voranstellen. Bei Verwendung der Schlüssel-ID statt der User-ID, des Namens oder der Email-Adresse, stellst Du sicher, daß Du exakt den Schlüssel erhälst, den Du willst. Bitte siehe Frage 4.5 für mehr Informationen darüber, wie man Schlüssel-IDs benutzt. Beispiele für das MGET-Kommando:

MGET michael: Holt alle Schlüssel, die "michael" enthalten
MGET iastate: Holt alle Schlüssel, die "iastate" enthalten
MGET bill.*@msn.com: Alle Schlüssel von MSN, mit Benutzernamen, die mit "bill" beginnen.
MGET E8F605A5|5F3E38F5: Diese beiden Schlüssel-IDs

Beachte, daß Du im MGET-Kommando den "0x"-Prefix nicht brauchst, wenn Du bestimmte Schlüssel willst.

Ein Wort über regexps: Sie sind nicht das Gleiche wie Wildcards (Stellvertreterzeichen), die Unix-Oberflächen oder MSDOS verwendet.

a* bedeutet nicht "entspricht irgendetwas", es meint "entspricht keinem Mal oder öfter dem vorhergehenden Buchstaben", wie:

a.* entspricht allem, was mit a beginnt
ab*c entspricht ac, abc, abbc, und so weiter.

Wenn Du den gesamten Schlüsselring haben willst und Zugang zu FTP hast, wird es viel effektiver sein, FTP anstelle von Email zu benutzen. Lade einen ganzen Schlüssel von ftp://ftp.pgp.net/pub/pgp/keys/Readme.html

Fehlfunktionen

Wohin sende ich Berichte über Fehlfunktionen?
Welche Fehlfunktionen von PGP sind bekannt?

9.1 Wohin sende ich Berichte über Fehlfunktionen?

<Ü>Fehlfunktionen, die MIT PGP betreffen, sollten an pgp-bugs@mit.edu gemeldet werden. Du solltest in der MIT-PGP-FAQ die komplette Liste der Fehlfunktionen der MIT-PGP-Version einsehen, bevor Du berichtest, um sicherzustellen, daß der Fehler nicht bereits gemeldet worden ist. Sollte es sich um eine ernstzunehmende Fehlfunktion handeln, solltest Du ihn nach comp.security.pgp.announce oder .tech. posten. Ernste Fehler sind solche, die die Sicherheit des Programmes beeinträchtigen, nicht Kompilierfeler oder kleine logische Irrtümer.

Poste alle Deine Fehlermeldungen, die Nicht-MIT-Versionen betreffen nach comp.security.pgp.tech, und leite eine Kopie an mich, um sie eventuell in eine spätere Ausführung dieser FAQ aufzunehmen. Bitte sei Dir im Klaren darüber, daß die Autoren von PGP den Empfang von Berichten, die direkt an sie geschickt wurden, vielleicht nicht bestätigen werden. Sie im Usenet zu veröffentlichen, wird ihnen binnen kürzester Zeit zur größtmöglichen Verbreitung verhelfen.

9.2 Welche Fehlfunktionen von PGP sind bekannt?

Die folgende Liste der Fehlfunktionen beschränkt sich auf die Version 2.4 und spätere, sowie auf die am häufigsten auftretenden und ernsten Mängel. Was Fehler in früheren Versionen angeht, halte Dich an die Dokumentation, die mit dem Programm geliefert wird. Solltest Du einen Fehler entdecken, der nicht in der Liste nicht erscheint, folge dem oben beschriebenen Verfahren, um ihn zu melden.

Der PGP 2.6.2-Quellcode läßt sich unter Linux/ELF nicht kompilieren. Um eine ELF-Binärversion von PGP 2.6.2 herzustellen, sind zwei Änderungen in den Quellcode-Dateien 80386.S und zmatch.S notwendig. Beide Dateien enthalten eine #ifdef-Anweisung, die abgewandelt werden muß. Ändere "#ifndef SYSV" in "#if !defined(SYSV) && !defined(_ELF_)" und ändere "#ifdef SYSV" in "#if defined(SYSV) || defined(_ELF_)".
MIT PGP 2.6 hatte einen Fehler beim Schlüsselerzeugungs-Prozeß, der dazu führte, daß die erzeugten Schlüssel sehr viel weniger zufällig waren. Behoben in Version 2.6.1
Alle Versionen von PGP außer MIT PGP 2.6.2 neigen zu einer kleinen Fehlfunktion beim Klartextsignieren von Nachrichten, die es erlaubt, zu Beginn einer signierten Klartextnachricht Text einzufügen. Der zusätzliche Text erscheint nicht im PGP-Output, nachdem die Signatur geprüft worden ist. MIT PGP 2.6.2 erlaubt keine Headerzeilen vor dem Text einer klartextsignierten Nachricht und erzwingt "RFC 882"-Syntax in den Headerzeilen vor der Signatur. Da der Fehler zum Zeitpunkt der Nachprüfung auftritt, solltest Du darüber Bescheid wissen, auch wenn Du MIT PGP 2.6.2 benutzt - der Leser kann Deine signierte Nachricht mit mit einer anderen Version testen ohne den Output zu lesen.
MIT PGP 2.6.1 sollte Schlüsselnzwischen 1024 und 2048 Bits Länge verwenden, konnte aber nicht. Behoben in Version 2.6.2
MIT PGP 2.6.2 sollte nach dem 25.Dezember 1994 die Erzeugung von Schlüsseln bis 2048 Bits ermöglichen; Ein "One-OFF Bug" setzt dieses obere Limit statt dessen auf 2047 Bits fest. Es wurde berichtet, daß dieses Problem nicht auftaucht, wenn MIT PGP unter gewissen Ausführungen von Unix kompiliert wird. In den Versionen 2.7.1, 2.6.2i und in der Mac-Version ist der Fehler behoben worden.
PGP 2.6ui zeigt weiterhin den Fehler von 2.3a, bei dem konventionell verschlüsselte Nachrichten, wenn sie zweimal mit dem gleichen Paßphrase verschlüsselt wurden, den gleichen Chiffretext ergeben.
MIT MacPGP kann Deinen geheimen Schlüssel nicht finden, wenn Deine User-ID nicht spezifiziert ist, obwohl es sogar Deinen geheimen Schlüsselbund findet. Das liegt an einem nicht initiallisierten 'Pointer', der gedacht war, auf dine User-ID zu verweisen. Das Problem läßt sich leicht umgehen: Editire die Konfigurationsdatei, so daß sie "Myname = "Deine_User-ID" enthält, und MacPGP wird Deinen geheimen Schlüssel finden. Behoben wurde das Problem mit FatMacPGP 2.6.2 und 2.6.3. Siehe auch Frage 2.13.
ViaCrypt hat einen Fehler in den Freeware-Versionen gemeldet, der zumindest PGP 2.3a, MIT PGP 2.6, 2.6.1 und 2.6.2 betrifft. Dieser Fehler zieht Signaturen in Mitleidenschaft, die mit Schlüsseln zwischen 2034 und 2048 Bits Länge erzeugt werden, so daß sie beschädigt werden. Praktisch betrifft dies bloß PGP-Versionen, die größere Schlüssellängen unterstützen. ViaCrypt berichtet, daß es nur beim Betrieb von PGP auf Workstations mit SUN-Sparc-Prozessor problematisch wird. ViaCrypt PGP 2.7.1 und PGP 2.6.2i werden von diesem Fehler nicht beeinträchtigt. Der folgende Patch wird das Problem in MIT PGP 2.6.2 beheben:
```
<===== begin patch (cut here)
--- crypto.c.orig     Mon Mar 20 22:30:29 1995
+++ crypto.c    Mon Mar 20 22:55:32 1995
@@ -685,7 +685,7 @@
    byte class, unitptr e, unitptr d, unitptr p, unitptr q, unitptr u,
                               unitptr n)
 {
-       byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION];
+       byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION+2];
        int i, j, certificate_length, blocksize,bytecount;
        word16 ske_length;
        word32 tstamp; byte *timestamp = (byte *) &tstamp;
<===== end patch (cut here)
```
Wie von Steven Markowitz <Steven-Markowitz@deshaw.com> berichtet, existieren die folgenden Fehlfunktionen in PGP 4.0 Business Edition (der kommerziellen Version):
1. Signaturwiderruf funktioniert nicht. Wenn ich eine Schlüsselsignatur zurückziehe, betrachtet PGP den Schlüssel weiterhin als unterzeichnet. Wenn ich die Signatur aus pubring.pgp entferne, die Widerrufserklärung aber weiterhin im Schlüsselbund belasse, sieht PGP den Schlüssel immernoch als unterzeichnet an.
2. Obwohl reine 'Chiffrier'-Schlüssel nicht zum Unterschreiben von Dokumenten benutzt werden können, erlaubt PGP dennoch, sie zur Herstellung von Schlüsselzertifikaten zu verwenden.
Die internationale Version von PGP kennt ein undokummentiertes "+makerandom"-Kommando, daß eine Datei voller Zufallsdaten erzeugen kann. Leider funktioniert sie nicht, wie beabsichtigt, weil der Zufallszahlengenerator nicht richtig initialisiert wird. Dies beeinträchtigt nicht den normalen PGP-Programmablauf; der Fehler taucht nur auf, wenn "+makerandom" benutzt wird.

Weiterführende Literatur

Bücher über PGP:

Stallings, William, Protect Your Privacy: A Guide for PGP Users, Prentice Hall, 1995, ISBN 0-13-185596-4. (Current errata at ftp://ftp.shore.net/members/ws/Errata-PGP-mmyy.txt)
Garfinkel, Simson, PGP: Pretty Good Privacy, O'Reilly & Associates,1994, ISBN 1-56592-098-8.
Schneier, Bruce, E-Mail Security with PGP and PEM: How To Keep Your Electronic Messages Private, John Wiley & Sons, 1995, ISBN 0-471-05318-X.

Bücher über Kryptographie im Allgemeinen:

Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, 1993
Kahn, David, The Code Breakers, The Story of Secret Writing, The MacMillan Publishing Company (1968), ISBN: 0-02-560460-0.
Dorothy Denning, Cryptography and Data Security, Addison-Wesley, Reading, MA 1982
Dorothy Denning, Protecting Public Keys and Signature Keys, IEEE Computer, Feb 1983
Martin E. Hellman, The Mathematics of Public-Key Cryptography, Scientific American, Aug 1979

PGP- oder kryptographie-bezogene Artikel:

Steven Levy, Crypto Rebels, WIRED, May/Jun 1993, page 54. (Das ist Pflichtlektüre über PGP und andere verwandte Themen.)
Ronald Rivest, The MD5 Message Digest Algorithm, MIT Laboratory for Computer Science, 1991. Im Netz erhältlich als RFC1321.
Xuejia Lai, On the Design and Security of Block Ciphers, Institute for Signal and Information Processing, ETH-Zentrum, Zurich, Switzerland, 1992
Xuejia Lai, James L. Massey, Sean Murphy, Markov Ciphers and Differential Cryptanalysis, Advances in Cryptology- EUROCRYPT'91
Philip Zimmermann, A Proposed Standard Format for RSA Cryptosystems, Advances in Computer Security, Vol III, edited by Rein Turn, Artech House, 1988
Paul Wallich, Electronic Envelopes, Scientific American, Feb 1993, page 30. (Das ist ein Artikel über PGP)

Usenet Newsgruppen:

alt.anonymous
alt.privacy.anon-server: Diskussionen über Anonymität und anonyme Remailer
alt.anonymous.messages: Für anonyme, verschlüsselte Nachrichtenübermittlung
alt.privacy.clipper: Clipper, Capstone, Skipjack, Key Escrow
alt.security: Allgemeine Sicherheitsdiskussionen
comp.security.pgp.announce: Neue PGP-Versionen, Hilfsprogramme, Fehlerberichte und so weiter. (Moderiert)
comp.security.pgp.discuss: PGP und seine Folgen
comp.security.pgp.tech: Verwendung von PGP, Fehlerberichte und Hilfestellungen
comp.security.pgp.resources: PGP betreffende Resourcen, Information und mehr
alt.security.pgp: Allgemeine Diskussion von PGP
alt.security.ripem: Diskussion pber RIPEM
alt.security.keydist: Schlüsselverbreitung über das Usenet
alt.society.civil-liberty: Generelle Bürgerrechte, einschließlich Privatsphäre.
comp.org.eff.news: Neuigkeiten der Electronic Frontier Foundation
comp.org.eff.talk: Diskussion EFF-bezogener Belange
comp.patents: Diskussion von Software-patenten, inklusive RSA
comp.risks: Einige Bezüge auf Kryptographie und Abhören
comp.society.privacy: Allgemeine Punkte zur Privatsphäre
comp.security.announce: Bekanntmachung von Sicherheitslücken
misc.legal.computing: Software Patente, Copyrights, Computer-Gesetze
sci.crypt: Methoden der Datenverschlüsselung/Entschlüsselung
sci.math: Allgemeine mathematische Diskussion
talk.politics.crypto: Allgemeine Unterhaltung über Kryptographiepolitik

Allgemeine Tips

Gibt es undokumentierte Einstellungen in PGP?
Kann ich PGP in einer Mailbox verwenden?

11.1 Gibt es undokumentierte Einstellungen in PGP?

Es gibt einige undokumentierte Kommandozeilen-Parameter. Peter Simons <simons@petium.rhein.de> hat eine umfassende Liste bereitgestellt:

Die "-i"-Option wird PGP dazu bringen, mehr Informationen über die Datei in die verschlüsselte Nachricht zu übernehmen. Mit der "-p"-Option restauriert PGP den originären Dateinamen, wenn Du die Nachricht entschlüsselst; wenn aber auch "-i" verwendet wird, und beide, Sender und Empfänger mit der gleichen Plattform arbeiten, dann werden auch die originären Dateiberechtigungen und Zeitstempel wiederhergestellt.
Mit der "-l"-Option gibt PGP erheblich mehr Informationen darüber aus, was es tut. Während der Schlüsselerzeugung, zum Beispiel, bekommst Du die Ziffern zu sehen, die in Deinem öffentlichen und geheimen Schlüssel verwendet werden.
Die "-km"-Option zeigt das "Netz des Vertrauens" (Siehe Frage 4.7) in Form einer Liste an. Auf diese Weise kannst Du sehen, welcher Schlüssel welchen einführt.
Indem Du "encrypttoself=on" in Deiner Konfigurationsdatei einfügst, werden alle Nachrichten, die Du verschlüsselst, immer auch mit Deinem eigenen öffentlichen Schlüssel verschlüsselt. Dadurch wirst Du stets in der Lage sein, jede Nachricht, die Du verschickst zu entschlüsseln und zu lesen. Das kann nützlich sein, wenn Du PGP so eingestellt hast, daß jede abgehende Nachricht verschlüsselt wird, und Dein "Postausgang" alle verschlüsselten Versionen beinhalten wird. Beachte: Wenn jemand anders es jemals schafft, Deinen geheimen Schlüssel zu bekommen, wird er fähig sein, jede verschlüsselte Nachricht, die Du jemals abgeschickt hast zu lesen, wenn Du diese Option gewählt hast.
Wenn Du eine Datei erzeugen willst, die n Zufallsbytes enthält, benutze "pgp <Dateiname> +makerandom=n". Es existiert ein Fehler in den internationalen, der dazu führt, daß diese Zufallsdaten weit weniger zufällig sind, als normalerweise.

11.2 Kann ich PGP in einer Mailbox verwenden?

Einige Mailbox-Sysops könnten Dir verweigern, verschlüsselte Mail oder Dateien in ihren Brettern zu platzieren. Nur daß sie PGP in ihrem Dateibereich haben, bedeutet nicht notwendigerweise, daß sie es tolerieren, wenn Du verschlüsselte Mail oder Dateien hochlädst - daher erkundige Dich vorher.

FIDO-Netz-Mail ist sogar noch empfindlicher. Du solltest nur verschlüsselte Net-Mail versenden, nachdem Du geprüft hast, daß:

Dein Sysop es erlaubt
Der Sysop des Empfänger es erlaubt
Die Mail durch Knoten geleitet wird, deren Sysops es erlauben

Signiere nicht jemands Schlüssel, bloß weil jemand anders, den Du kennst, ihn unterzeichnet hat. Überprüfe selbst die Identität der Person. Erinnere Dich, daß Du Deinen Ruf aufs Spiel setzt, wenn Du einen Schlüssel unterzeichnest.

Wenn Du einen "UNIX-Shell account" hast, lege eine Kopie Deines Schlüssels in eine Datei, die ".plan" heißt, so daß andere Leute diesen account und dabei Deinen Schlüssel über Finger erreichen. Siehe auch Frage 4.8

Außerdem sende Deinen öffentlichen Schlüssel an einen Keyserver. Siehe Frage 8.1 für die Details.

Welche Methode Du auch immer wählst, um Deinen Schlüssel verfügbar zu machen, stelle sicher, daß allen anderen klar wird, wie sie ihn erhalten. Gewöhnlich fügt man Anweisungen einfach in der Mail- und News-Signatur ein (so ähnlich wie: "PGP public key available from keyservers" oder "Finger me for public key"), oder verweise darauf in Deiner Homepage.

Es ist auch eine gute Verfahrensweise, Schlüssel-ID und Fingerprint in Deine Signatur aufzunehmen. Auf diese Weise können die Leute, die Deinen Schlüssel haben wollen, sicherer sein, daß sie tatsächlich Deinen bekommen, und nicht irgend einen anderen Schlüssel mit Deinem Namen darin. Der Fingerprint wird dabei sogar noch besser helfen.

Aber das ist kein Beweis dafür, daß der Schlüssel tatsächlich Dir gehört. Beachte, daß die Nachricht oder das Posting mit der Signatur eine Fälschung sein kann.

Solltest Du noch andere Tips haben, laß es mich wissen.

Über diese FAQ

Diese comp.security.pgp FAQ geht zum größten Teil auf Jeff Licquias Original der alt.security.pgp FAQ zurück, die auf http://www.prairienet.org/~jalicqui/pgpfaq.txt zur Verfügung gestellt wird. Ich begrüße Kommentare, Vorschläge oder Ergänzungen zu dieser FAQ. Du kannst sie an faq-admin@mail.pgp.net senden.

Was ist neu?

Ergänzungen wegen PGPmail und PGP 5.0 in den Fragen 1.7 und 1.9.
Neue Anhänge und Glossar.
Frage 2.16 ist neu.
pobox.com zertifiziert nicht länger (?) PGP Schlüssel. Abschnitt 8.2 angepaßt.
Jeffrey Schillers Erklärung was es mit PGP 5.0 "schnellerer Schlüsselerzeugung" auf sich hat, ersetzt Viacrypts Erklärung in Anhang IV.

Das englische Original dieser FAQ wird monatlich in allen comp.security.pgp-Newsgruppen gepostet, und die letzte Version wird immer auf den folgenden Seiten zur Verfügung gestellt:

http://www.pgp.net/pgpnet/pgp-faq/: Hypertext-Version, mit Baumstruktur zum einfachen Schmökern.
http://www.pgp.net/pgpnet/pgp-faq/pgp.html (117 kilobytes): Hypertext-Version, ein Dokument zum Offline-Lesen.
http://www.isl.net.tw/~terry/pgp-faq/: Chinesische Fassung dieser FAQ. Übersetzt von Chen Tai-Wei <terry@ms1.hinet.net>
http://www.iks-jena.de/mitarb/lutz/security/pgpfaq.html: Diese deutschsprachige Fassung dieser FAQ. Übersetzt von Michael Uplawski <uplawski@sulla.franken.de>

Weiterverbreitung

Die Verbreitung auf elektronischem Wege ist erlaubt, solange der Copyright-Vermerk am Ende erhalten bleibt. Wenn Du irgendwelche Änderungen vornehmen willst, laß es mich erst wissen.

Da diese FAQ im PGP-Network zur Verfügung gestellt wird, sollte es kein Problem sein, Zugriff darauf zu nehmen. Daher ist es wahrscheinlich nicht nötig, diese FAQ woanders bereitzustellen.

Wenn Du diese FAQ auf einer CD-ROM oder ähnlichem Medium verbreiten willst, nimm bitte zunächst Kontakt mit mir auf (faq-admin@mail.pgp.net). Das selbe gilt für die Offline-Verteilung der reinen Text-Version.

Copyright des Originals

Last updated: 20 Apr 1997.
Copyright (C) 1996 by Arnoud Engelfriet. Comments, additions and suggestions can be sent to <faq-admin@mail.pgp.net>.
Generated by Orb v1.3 for OS/2 (http://www.cinenet.net/users/cberry/orbinfo.html).

Zur Übersetzung

Dieser Übersetzung liegt die Version 1.3 der comp.security.pgp FAQ von Arnoud Engelfriet zu Grunde, sie befindet sich daher auf dem Stand vom 20. April 1997.

Rechtschreibfehler gehen auf mein Konto, genauso Fehler, die in der Übersetzung UNIX-spezifischer- und mit Programmiersprachen im Zusammenhang stehender Sachverhalte auftreten.

Folgende Personen haben mich mit korrekten Übersetzungen von Fachausdrücken, durch die Erläuterung einiger Programmeigenschaften oder beim Korrekturlesen unterstützt:

Andy Feile
Arnoud Engelfriet
Felix Schroeter
Hagen Wollert
Jörg Freichel
Luko Willms
Lutz Donnerhacke
Peter Conrad
Robert Bihlmeyer
Thomas Roessler
Ulf Möller
Wolfgang Stehle

Sollte ich jemanden vergessen haben, lag das sicher an der Uhrzeit, zu der ich seine Mail erhalten und versehentlich gelöscht habe...

Michael Uplawski <uplawski@sulla.franken.de>

zurück

Saturday | 23.Nov.2024