PGP-FAQ.de


Version v0.9a vom 1. Juni 1994
verwaltet von Marc Aurel <4-tea-2@bong.saar.de>
HTML-Version vom 24. Juni 1995


Wichtiger Hinweis!

Diese FAQ kann und will nicht die PGP-Anleitung ersetzen.

Wer PGP sinnvoll, richtig und verantwortungsvoll einsetzen will, wird nicht um das Durcharbeiten der Anleitung herumkommen. Oder, mit den Worten aus "README.DE":

DIES ZUERST LESEN
Pretty Good Privacy Version 2.3a
Anmerkungen von Perry Metzger
Überarbeitet für Version 2.3a von Colin Plumb
Übersetzt von Abel Deuring
Dies ist die README-Datei für PGP 2.3a. PGP (Pretty Good Privacy - Prima Geschützte Privatsphäre) ist ein Verschlüsselungsprogramm, das mit öffentlichen Schlüsseln arbeitet. Mit PGP können Sie Nachrichten, die Sie mit E-Mail oder Diskette versenden, vor unerlaubtem oder unerwünschtem Mitlesen schützen, und Sie können Nachrichten unterschreiben, so daß die EmpfängerInnen dieser Nachrichten sicher sein können, daß Sie der/die AbsenderIn sind.
Die Dateien "pgpdoc1.doc" und "pgpdoc2.doc" enthalten das englische Original des Handbuches; die Dateien "pgpdoc1.de" und "pgpdoc2.de" die deutsche Übersetzung. Bevor Sie PGP verwenden, LESEN SIE BITTE DIESE HANDBÜCHER! Immer mehr Menschen benutzen ein Programm, ohne vorher das Handbuch zu lesen. Bei Verschlüsselungsprogrammen schleichen sich aber sehr leicht Bedienungsfehler ein, die zu einem hohen Verlust von Sicherheit führen können!
Eine Kette ist nur so stark wie ihr schwächstes Glied. Die bei PGP verwendeten sicherheitsrelevanten Algorithmen gehören zu den sichersten, die öffentlich bekannt sind. Es gibt aber einige Sicherheitsaspekte, die PGP ebensowenig alleine lösen kann, wie auch ein guter Tresor sicher ist, wenn man vergißt, die Tür zu schließen oder zu verriegeln. Auch wenn Sie schon das Prinzip öffentlicher Schlüssel kennen, sollten Sie das Handbuch lesen, um mit den Mechanismen vertraut zu werden, die PGP für die Sicherung des Nachrichtenaustausches bietet.

Die deutsche Übersetzung der Anleitung stammt von Abel Deuring <A.DEURING@BIONIC.zer.de> und Christopher Creutzig <C.CREUTZIG@hot.gun.de>. Zusammen mit der Hilfedatei de.hlp von Helmut Fligge <H.FLIGGE@ASCO.central.de> und dem deutschen language.txt sollte die Anleitung als komplettes "Language-Kit" in Kürze überall dort verfügbar sein, wo auch PGP als solches vorhanden ist. Siehe auch: Wo bekomme ich PGP?


Was ist PGP?

PGP ist ein Verschlüsselungsprogramm, das auf vielen verschiedenen Plattformen (z.B. DOS, verschiedenste Unixe, VAX/VMS, IBM Mainframes, Macintosh, AMIGA, Archimedes) implementiert und auf diversen Computernetzen zum de-facto-Standard geworden ist. Auch im Z-Netz laufen Bestrebungen, PGP zum Standard werden zu lassen.

Die von PGP verwendeten Verschlüsselungsverfahren erlauben einen extrem sicheren Nachrichtenverkehr. So sicher, daß niemand es bisher geschafft hat, ein Verfahren zu entwickeln, mit dem man die Nachrichten entschlüsseln kann, jedenfalls niemand, der davon erzählen dürfte.

Das besondere an PGP ist, daß man den Empfänger der Nachricht niemals getroffen haben muß, um ihm verschlüsselte Nachrichten schicken zu können:

Traditionelle Verschlüsselungstechniken benutzen einen einzigen Schlüssel. Zwei Leute treffen sich und vereinbaren diesen Schlüssel, beide benutzen ihn sowohl zum Kodieren, als auch zum Dekodieren.
PGP beherrscht die konventionelle Verschlüsselung mit einem Paßwort, aber außerdem auch das 'Public Key-Verfahren', bei dem jeder Absender Nachrichten mit dem öffentlich verfügbaren 'Public Key' des Empfängers verschlüsseln, aber nur dieser sie (mit Hilfe seines privaten Schlüssels) wieder entschlüsseln kann. Nur er, niemand sonst. Nicht einmal der Absender.

Die Verwaltung eingehender öffentlicher Schlüssel in einer Schlüsseldatei übernimmt PGP selbständig. Ein kleine Hürde stellt dabei der Teil der Schlüsselpflege dar, den PGP nicht alleine erledigen kann. Darunter fallen Fragen wie:

Warum sollte man überhaupt verschlüsseln?

Aus dem gleichen Grund, aus dem man nicht die ganze Schneckenpost auf Postkarten verschickt, sondern auch mal einen verschlossenen Umschlag benutzt.

"Ich habe nichts zu verbergen."

Wer einige Zeit am Netzleben teilnimmt, stellt oft fest, daß er verblüffend intensive Beziehungen zu Menschen aufnimmt, die er nie gesehen hat. Während einer längeren Unterhaltung per PM entwickelt sich in der Regel eine gewisse Vertrautheit, möglicherweise bis zu einem Grad, wo man dem Gegenüber Informationen geben will, die man nicht 'jedermann' geben würde. Dabei muß es sich nicht um sexuelle oder kriminelle Geständnisse handeln, schon das eigene monatliche Einkommen wird von vielen als 'vertrauliche Information' angesehen.

In vielen Mailboxen ist daher die Verschlüsselung von PMs innerhalb des Systems üblich. Pointpuffer z.B. landen dagegen vollkommen 'ungeschützt' auf der Festplatte des Mailboxbetreibers.

"Mir spioniert doch niemand hinterher!"

Verschlüsselung schützt nicht nur vor dem absichtlichen Ausspähen von Daten, sondern auch vor 'Mißgeschicken'. Der 'böse Sysop', der sich alle privaten Nachrichten, die durch sein System laufen, in eine Extradatei kopiert und diese (masturbierend) nach Intimitäten durchforstet ist hoffentlich nur ein Gedankenspiel.

Nachrichten, die beim falschen Empfänger ankommen oder als 'unzustellbar' in einem Extrabrett landen, von wo aus sie oft vom Sysop manuell weitergeleitet werden, sind dagegen ein alltägliches Phänomen. Denkbar sind Horror-Szenarien wie:

All dies sind Möglichkeiten, wie Daten, die wir bei genauem Nachdenken durchaus als 'vertraulich' einstufen würden, in falsche Hände geraten könnten.

Aber es gibt auch einen politischen Aspekt: in den Vereinigten Staaten ist eine heiße Diskussion über ein staatlich verordnetes Verschlüsselungsverfahren (,Clipper') ausgebrochen, das als besonderes 'Feature' die Entschlüsselung _jeder_ Datei durch Regierungsbehörden zuläßt. Mit PGP haben wir die Möglichkeit, in den Netzen Europas Fakten zu schaffen, bevor die Regierungen auf die Idee kommen, uns mit Restriktionen zu belegen.

Was kostet PGP?

PGP ist Freeware, kostet also keinen Pfennig.

Wenn wir über den großen Teich schauen, stellt sich die Situation etwas anders dar: in den USA (und in Mexiko, evtl. in Kanada, ganz sicher nicht in Europa!) ist ein Teil von PGP, nämlich das RSA-Verfahren, durch nationales Patentrecht geschützt.

Was ist RSA? Was ist ein Public Key-Verfahren?

Beim RSA-Verfahren, benannt nach den Entwicklern Rivest, Shamir und Adleman, wird pro Benutzer ein Schlüsselpaar generiert, bei dem die eine Hälfte praktisch nicht aus der anderen Hälfte errechnet werden kann. Trotzdem kann eine Information, die mit einer Hälfte verschlüsselt wurde, ausschließlich mit der anderen Hälfte wieder entschlüsselt werden.

Der Vorteil dieses Verfahrens liegt darin, daß man eine Hälfte des Schlüssels als Private Key unter Verschluß halten, die andere als Public Key jedoch unter die Leute bringen kann. Jeder, der Deinen Public Key hat, kann Dir eine verschlüsselte Nachricht schicken, ohne vorher mit Dir auf einem abhörsicheren Weg einen gemeinsamen Schlüssel zu vereinbaren.

Wie funktioniert RSA?

Christopher Creutzig <C.CREUTZIG@hot.gun.de>:

Zur Frage ,,wie funktioniert RSA'' kann ich etwas beitragen. :-))
\def\Hinweis{mathematisch und eigentlich unwichtig :-)}
phi(x) sei die Eulersche Phi-Funktion, die die Anzahl der n aus N bezeichnet, die kleiner als x und mit x teilerfremd sind. Ist nicht weiter wichtig, Interessant ist nur, daß für zwei Primzahlen p und q gilt: phi(p*q)=(p-1)*(q-1).
Es gilt
_ _
a^(phi(z)) = 1 (mod z) [ = bedeutet: ,kongruent modulo' ]
(Primzahltheorie, Beweis habe ich nicht da.)
also auch:
_
a^(phi(z)+1) = a (mod z) (a<z)
Über die Umformung zu
_
a^x = b (mod z)
_
b^y = a (mod z)
Was haben wir nun davon? Nun, wenn es nicht gelingt, aus x und z y zu berechnen, dann können wir das Zeichen a mit dieser Rechnung in das Zeichen b verschlüsseln, das nicht ohne weiteres zurückverwandelt werden kann. RSA verwendet für v das Produkt zweier möglichst großer Primzahlen, die Sicherheit des ganzen liegt darin, daß noch kein schneller Algorithmus bekannt ist, um Primfaktorzerlegungen durchzuführen.
Zahlenbeispiel:
Mit x*y = (phi(z)+1) kommen wir zur Verschlüsselung: Mensch nehme zwei Primzahlen (als Beispiel 13 und 11), deren Produkt (143) wird als z veröffentlicht (also nehmen wir besser größere Zahlen, daß 143=13*11 ist, läßt sich recht schnell herausfinden...), weiterhin berechnen wir (phi(z)+1) = 121), einen Teiler hiervon (da kommt wohl nur die 11 in Frage...) veröffentlichen wir als x, y (in diesem Fall auch 11) behalten wir geheim.
Nun nehmen wir das zu verschlüsselnde Zeichen (6) und berechnen b:
_
6^11 = 362797056 = 50 (mod 143)
Unser verschlüsseltes Zeichen ist also 50. Die verschicken wir nun, der Empfänger kann leicht ausrechnen:
__
50^11 = 6 (mod 143)
(mein Rechner kann mit den Zahlen nicht so gut...)
Normalerweise sind x und y natürlich voneinander verschieden, aber gute Zahlen zu finden wird erst bei größeren Zahlen leichter.
Das ganze könnte übrigens eine sehr trügerische Sicherheit sein, die Erfinder wissen selbst nicht genau, wie sicher das System ist, aber es bietet einige Ansatzpunkte, um auch ohne Primfaktorzerlegung ans Ziel zu kommen. :-(( (z.B. Anlegen einer Zuordnungstabelle a/b)

Was ist IDEA?

IDEA ist ein 'konventionelles' Verschlüsselungsverfahren, das sich als sicherer als das bekannte DES erwiesen hat. PGP benutzt eine Kombination von RSA und IDEA, weil eine komplette RSA-Verschlüsselung zu rechenaufwendig, sprich: langsam wäre. Also erzeugt PGP einen zufälligen Schlüssel, den 'Session Key', mit dem die Information IDEA-codiert wird, und packt diesen RSA-codiert zu dem verschlüsselten Text dazu.

Das hat außerdem den Vorteil, daß eine Nachricht mit wenig Aufwand für mehrere Empfänger verschlüsselt werden kann: PGP erweitert den verschlüsselten Text für jeden zusätzlichen Empfänger einfach um eine eigene RSA-codierte Kopie des 'Session Key'.


Wo bekomme ich PGP und die deutsche Dokumentation?

per ftp:

Ich sehe mich nicht dazu in der Lage, hier eine komplette Liste aller PGP-führenden Systeme zu liefern, aber ich hab festgestellt, daß ich alles, was ich brauche von der Uni Hamburg bekommen kann.

per Download:

per Fido-File-Request:

Kann mich jemand mit aktuellen Daten versorgen?

//FoeBuD-Werbefläche:

//padeluun <padeluun@BIONIC.zer.de>:

Zu Philip Zimmermann und PGP noch drei Anmerkungen:
  1. Der FoeBuD e.V. hat eine deutschsprachige PGP-Anleitung verlegt, die als 'Betaversion' für 20 DM zu erhalten ist (bitte angeben ob DOS- oder AMIGA-Diskette gewünscht ist) bei:
    FoeBuD e.V.
    Marktstr. 18
    33602 Bielefeld
    bitte Scheck über 20 DM beilegen (Bargeld geht natürlich auch).
    Übersetzt wurde die Anleitung von PGP von Christopher Creutzig und Abel Deuring.
  2. Der FoeBuD hat auch ein Spendenkonto eingerichtet, auf dem Spenden für den Anwalt Philip Zimmermanns in Deutschland gesammelt werden, die dann in jeweils einer Überweisung in die USA geschickt werden.
    Kontoinhaber : FoeBuD e.V.
    Bank : Sparkasse Bielefeld
    Kontonummer : 2134187
    Bankleitzahl : BLZ 480 501 61
    Ein Zahlungsgrund braucht nicht angegeben werden, weil dieses Konto ausschließlich für diesen Zweck eingerichtet worden ist.
  3. In der BIONIC existiert ein Account namens 'PGP' <kein Paßwort>, über den PGP 'gesaugt' werden kann.
    Telefonnummer: 0521-68000 (ISDN 0521-9680869)
    Einfach im Postfach INHALT * eingeben.
    Es gibt dort auch Zusatzprogramme und Anleitungen, wie PGP einfach in CrossPoint eingebunden werden kann.

Hey! Wieso schrieb //padeluun etwas von einem Spendenkonto?

Abel Deuring <A.DEURING@BIONIC.zer.de> (als Übersetzer):

Spendenaufruf
Am 14. September 1993 erhielt die Firma LEMCOM Systems (ViaCrypt) aus Phoenix, Arizona, eine Vorladung des Distriktsgerichts von Nordkalifornien. LEMCOM Systems wurde darin aufgefordert, vor einer "Grand Jury" eine Zeugenaussage zu machen, und Dokumente herauszugeben, die "ViaCrypt, PGP, Philip Zimmermann, und jede andere Person oder Institution, die im Interesse von Philip Zimmermann in der Zeit von 1. Juni 1991 bis heute arbeiteten herauszugeben."
Philip Zimmermann wurde mitgeteilt, daß er der Hauptverdächtige in einem Ermittlungsverfahren ist, das vom US-Zollamt in San Jose durchgeführt wird. Ob es weitere Verdächtigte gibt, ist nicht bekannt. Die entstehenden Kosten für Philip Zimmermann werden astronomisch sein, unabhängig davon, ob es nun zu eine Anklage kommt oder nicht.
Falls es zu einem Prozeß kommt, wird dies einer der wichtigsten Prozesse sein, die in letzter Zeit um Kryptographie, um den effizienten Schutz des Briefgeheimnisses und um den freien Fluß von Informationen und Ideen im Cyberspace nach Ende des kalten Krieges geführt wurden. Dieser Prozeß wird von großer Bedeutung sein, sowohl für diejenigen von uns, die sich für die Idee des effektiven Schutzes der Privatsphäre im Kommunikationsbereich einsetzen, als auch für Philip, dem eine Haftstrafe droht für seine uneigennützige und erfolgreiche Entwicklung von "Kryptographie für die Allgemeinheit", auch als PGP bekannt.
Exportbeschränkungen müssen dafür herhalten, die Verfügbarkeit von effektiver kryptographischer Technologie zu beschneiden: Der Zoll vertritt die Auffassung, daß die Veröffentlichung eines kryptographischen Programms im Internet mit seinem Export gleichzusetzen ist. Philip hat als erster keine Risiken und Mühen gescheut, wirklich effektive Werkzeuge zu entwickeln, die unserer Kommunikation den Schutz vor neugierigen Augen geben, und das in einer politischen Situation, in der dieser Schutz immer größeren Anfeindungen ausgesetzt ist, in einer Situation, in der die US-Regierung mit Clipper Chips und Gesetzentwürfen zum digitalen Telefon auf unsere Sorgen und Befürchtungen antwortet. [Der Clipper Chip dient der Verschlüsselung von Daten und Telefongesprächen. Er ist so konstruiert, daß Regierungsbehörden in der Lage sind, alle clipper-verschlüsselten Daten zu entschlüsseln. d.Ü.] Die Zeit ist gekommen, daß wir alle die Last mit Philip teilen.
Philip baut ein Verteidigungsteam auf, um sich auf einen Prozeß vorzubereiten, und er braucht dazu Ihre Hilfe. Der Prozeß wird eine teure Angelegenheit werden, und die Zeit läuft schon. Ich rufe alle, in den USA und anderswo, auf, Philips Verteidigung zu unterstützen und vielleicht einen bahnbrechenden Präzedenzfall zu schaffen. Philips Anwalt in Boulder hat einen Verteidigungsfond eingerichtet. Spenden werden in jeder Form (Scheck, Zahlungsanweisung, telegrafischer Transfer) und in jeder Währung angenommen.
Schecks und Zahlungsanweisungen sollten NICHT für Philip Zimmermann ausgestellt werden, sondern für seinen Anwalt, Philip Dubois. Seine Adresse ist:
Philip Dubois
2305 Broadway
Boulder, CO USA 80304
(Phone #: 303-444-3885)
Überweisungen können auf folgendes Konto erfolgen:
Bank: VectraBank
Routing #: 107004365
Account #: 0113830
Account Name: "Philip L. Dubois, Attorney Trust Account"
Falls nach Abschluß des Verfahrens Geld übrig bleibt, wird es an die SpenderInnen entsprechend ihrem Beitrag zum Fond anteilig zurückgezahlt.
Sie können anonym spenden, oder auch aber, aber BITTE - spenden Sie reichlich. Wenn Sie die Ziele, für die PGP steht, und die Ideen, die seine Entwicklung anregten, bewundern, drücken Sie Ihre Unterstützung durch einen Beitrag zu diesem Fond aus.
Hugh Miller <hmiller@orion.it.luc.edu>
Anmerkung der Übersetzer: PGP ist ein hoch professionell geschriebenes Programm, das kostenlos ist. Freeware von vergleichbarer Qualität und vergleichbarem Verbreitungsgrad ist sehr selten. Wir möchten deshalb alle NutzerInnen von PGP auffordern, zu überlegen, was sie für die Registrierung eines Sharewareprogramms vergleichbarer Qualität zahlen würden, oder wieviel Geld sie für ein vergleichbares Produkt, das es nur gegen Geld gibt, zahlen würden. Diesen Betrag sollten sie dann Philips Anwalt überweisen. (Wobei mehr Geld natürlich auch nicht falsch ist...)
[Die Anregung für diese "Bemessungsgrundlage" stand irgendwann mal in /T-NETZ/PGP/ALLGEMEIN. Leider erinnern wir uns nicht mehr, von wem sie stammt...] [von mir, glaub ich ;) ]
Auslandsüberweisungen sind sehr teuer. Der FoeBuD e.V. (Verein zur Förderung des beweglichen und unbeweglichen Datenverkehrs, Bielefeld, Marktstr. 18) hat deshalb ein Spendenkonto zur Unterstützung von Philip Zimmermann eingerichtet. Überweisungen, die auf diesem Konto eingehen, werden in regelmäßigen Abständen auf das oben genannte Konto von Philip Dubois weitergeleitet. Die Daten des Konto:
FoeBuD e.V.
Sparkasse Bielefeld
Kontonummer 2134187
BLZ 48050161

[Man kann's gar nicht oft genug erwähnen...]

Was sollen die kryptischen Datenpakete in Brettern?

Hauke Lampe <Packbart@PEOPLE-S.zer.sub.org>:

Geek-Code. So eine Art einzeilige Personenbeschreibung.

[War nur ein Witz! Aber tatsächlich fragen in /T-NETZ/PGP/ALLGEMEIN überdurchschnittlich viele Leute nach den Geek-Code-Zeilen in den Signatures mancher Autoren, möglicherweise weil sie sie für mutierte Unterschriften oder Fingerabdrücke (s.u.) halten. ;) ]

In allgemein zugänglichen Brettern (newsgroups / areas) machen verschlüsselte Texte wenig Sinn. In diesem Fall handelt es sich in der Regel um öffentliche Schlüssel oder Unterschriften unter Nachrichten.

Ein Schlüssel sieht etwa so aus (ohne '>'-Quotezeichen):

> ----BEGIN PGP PUBLIC KEY BLOCK----
> Version: 2.3a
>
> FQUtPiP9EfSASAPDEKifNIF2UN244R518X264K051G6F8HT/As30Q5rYSB22/tOR 
> ALBcTSNkG4vAgDi5ZzwgurkogiUHm8XwgaroZZniuZSALiWf1EUzj5t9wG23Fq4C 
> SgIP4C42ly/ffbVWwwAFEbQhTWFyYyBBdXJlbCA8NC10ZFuhukBib25nLnNhYXIu 
> ZGU+iQB1AgUQLNzCrzaXL666tVbDAQGUjwL8DyJ32h+Ym4+6L9FEz2t64YaHozna 
> ZT4=
> ----END PGP PUBLIC KEY BLOCK----

Wozu sind 'Unterschriften' gut?

Abel Deuring <A.DEURING@BIONIC.zer.de>:

Der Austausch verschlüsselter Nachrichten soll Sicherheit bieten, insbesondere natürlich Sicherheit davor, daß außer AbsenderIn und EmpfängerIn noch andere die Nachricht lesen können. Ebenso sollte aber auch für die EmpfängerIn sichergestellt sein, daß eine Nachricht wirklich "echt" ist, daß sie also wirklich von der Person stammt, die als AbsenderIn angegeben ist. Bei einer Verschlüsselung, die mit Paßworten arbeitet, ist diese Sicherheit dadurch gegeben, daß (hoffentlich) nur AbsenderIn und EmpfängerIn das vereinbarte Paßwort kennen. Wenn aber ein PGP-Schlüssel öffentlich bekannt gegeben wird, kann (und soll!) er von allen Personen benutzt werden, die der BesitzerIn des Schlüssels Nachrichten schicken möchten. Dann kann es aber passieren, daß jemand eine falsche Absenderangabe erzeugt, und mit dieser gefälschten Angabe eine PGP-verschlüsselte Nachricht verschickt. Die EmpfängerIn einer Nachricht kann die Echtheit einer Nachricht kontrollieren, wenn die Nachricht "unterschrieben" wird:

Eine Unterschrift unter einer Nachricht kann nur vom Besitzer des privaten Schlüssels erzeugt, aber von jedem, der den passenden öffentlichen Schlüssel in seiner Schlüsseldatei hat, überprüft werden. Weil es praktisch unmöglich ist, die digitalen Unterschriften, die PGP erzeugt, zu fälschen, kann damit sichergestellt werden, daß eine Nachricht wirklich von dem angegebenen Absender stammt und nicht manipuliert wurde.

Wie lasse ich den Klartext beim Unterschreiben im Klartext?

Wenn PGP eine Nachricht unterschreibt, packt es sie ganz in eine Versandhülle ein.

Die Lösung: die abgetrennte Unterschrift (,Clearsig'). Unterzeichnete Nachrichten beginnen damit mit einer Zeile, die so aussieht:

----BEGIN PGP SIGNED MESSAGE----

Es folgt der Klartext (für jeden lesbar), die Unterschrift findet man in einem Extraabschnitt unter der Nachricht. Um diese abgesetzte Unterschrift zu erzeugen, sollte im CONFIG.TXT des Absenders

ClearSig = on

erscheinen oder, alternativ, die zum Unterschreiben verwendeten Befehlszeile so lauten:

pgp -sat +clearsig=on blafasel.txt

Warum sind meine abgetrennten Unterschriften immer 'bad'?

Wahrscheinlich benutzt Du PGP v2.3 für DOS. Diese Version hat mehrere Fehler, es wäre sinnvoll, wenn Du Dir eine aktuelle Version besorgen würdest.

Warum stürzt PGP manchmal aus unerklärlichen Gründen ab?

DOS

Dos ist halt so. Besonders gefährdet sind anscheinend die 32bit-Versionen.

AMIGA

Peter Klein <PEK@FLATTER.zer.sub.org>:

Große Programme wie PGP können auf Amigas abstürzen, wenn die Stackgröße für das Programm zu klein gewählt wird. Die Stackgröße sollte mindestens 20000 Byte sein (System-Voreinstellung sind 4096 Bytes). Das geschieht mit dem Befehl "stack 20000" (wer hätte das gedacht :-))

Die Liste der wichtigsten PGP-Befehle:

Schlüsselmanagement:

PGP -kg
Erzeugen eines eigenen Schlüsselpaares
Diesen Befehl braucht man hoffentlich nur ein einziges Mal. Siehe auch: "Wie gehe ich mit Schlüsseln um?"
PGP -ka <Datei>
Öffentlichen Schlüssel aus Datei zur eigenen Schlüsseldatei hinzufügen
PGP -kv <ID>
Anzeigen der öffentlichen Schlüssel, die ID entsprechen
PGP -kv
Anzeigen aller öffentlichen Schlüssel der Schlüsseldatei
PGP -kvv
Anzeigen der Schlüssel samt Unterschriften
PGP -kxa <ID> <Datei>
Extrahieren des öffentlichen Schlüssels von ID in Datei
Dieser Befehl wird benötigt, um einen einzelnen Schlüssel an andere weiterzugeben. Der Schlüssel kann der eigene sein, oder auch ein fremder, den man eventuell mit er eigenen Unterschrift als echt beglaubigt hat.

Ver-/Entschlüsselungsfunktionen:

PGP <Datei>
Datei entschlüsseln und/oder Unterschrift überprüfen
PGP -sta +clearsig=on <Datei>
Klartext-Nachricht unterschreiben
PGP -esa <Datei> <ID>
Datei unterschreiben und an ID verschlüsseln

Für <ID> muß nicht die volle Benutzer-ID angegeben werden. PGP sucht nach Schlüsseln, deren Benutzer-IDs den als <ID> angegebenen Text enthalten. Bei kv und kxa benutzt PGP alle passenden Schlüssel. Beim Verschlüsseln oder Unterschreiben benutzt PGP den ersten passenden Schlüssel, man muß also selbst sicherstellen, daß man den Empfänger eindeutig angibt.

Schlüssel können auch über ihre Schlüssel-ID ausgewählt werden. Dabei gibt man die (hexadezimale) ID (oder einen Teil davon) nach dem Präfix '0x' an. Beispiel:

PGP -kv 0xB556C3

Undokumentierte Funktionen:

PGP [...] -z"<Mantra>"
Angabe des Mantras auf der Befehlszeile
PGP -km
"Maintainance pass"
PGP [...] -l
Ausführliche Ausgabe anschalten (verbose=2)

Was ist bei der Schlüsselerzeugung zu beachten?

Ein eigenes Schlüsselpaar generiert man mit:

PGP -kg

Länge:

Die meisten PGP-Benutzer wählen einen 1024-bit-Schlüssel (military grade), auch wenn die Verschlüsselung abhängig vom verwendeten Rechner spürbar länger dauern kann. Von einem 384-bit-Schlüssel (casual grade) sollte man absehen.

Pass Phrase:

Die 'Pass Phrase', die PGP während der Schlüsselerzeugung abfragt, soll den privaten Schlüssel vor fremdem Zugriff schützen. Wie für die meisten Paßwörter gilt auch für dieses, daß es nicht leicht zu raten sein sollte. Im Gegensatz zu vielen anderen Paßwörtern gibt es bei diesem Paß-*Satz* praktisch keine Längenbeschränkung. Berühmte Zitate eignen sich weniger, statt dessen sollte man eine Mischung aus Sonderzeichen, Ziffern und Text und wählen, z.B.:

$Clark42Kent--Fuppes(FloedelDoe(

Aber selbst bei der aller-aller-sichersten 'Pass Phrase' muß man immer noch darauf achten, daß möglichst niemand auf die Datei Zugriff hat, in der der private Schlüssel steht.

Benutzer-ID:

PGP-Schlüssel werden in der Regel weiterverteilt und landen u.U. auf einem Internet-Keyserver. Man sollte deshalb darauf achten, eine eindeutige Benutzer-ID zu verwenden, die außerdem die Mail-Adresse enthält. Es reicht nicht aus, wenn die Benutzer-ID "Helmut in der LINK-MZ" lautet. In eine Benutzer-ID gehört der Name des Schlüsselinhabers und eine so weit wie möglich erreichbare Mail-Adresse, z.B.:

Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>

Ein weiterer Grund für die Angabe der Mail-Adresse ist die Angewohnheit mancher PGP-Benutzer, ihre Schlüsseldatei als Adreßbuch zu mißbrauchen. ;)

Generierung:

PGP wird voraussichtlich um Eingaben auf der Tastatur bitten. Die Zeitspannen zwischen den Anschlägen werden als Zufallsdaten verwendet. Computer können zwar Pseudo-Zufallszahlen 'errechnen', aber wirklich zufällige Werte sind auf Rechnern sehr schwer zu bekommen. Das Abtippen von Text z.B. aus einem Buch ergibt für diesen Zweck übrigens einen breitere Verteilung der Daten, als das schnelle 'Wegtippen' der Anschläge.

Das Berechnen eines 1024-bit-Schlüssels kann je nach Rechenleistung einige Minuten dauern, in dieser Zeit zeigt PGP mehrmals abwechselnd Gruppen von Punkten '.' und Pluszeichen '+' an.

Rechner / Betriebssystem Beispielzeiten für die Erzeugung eines 1024-bit-Schlüssels:

ms1207@cd4680fs.rrze.uni-erlangen.de:

Die Berechnung eines 9000bitigen Keys hat auf einem 486DX-33 ca. 51 Stunden gedauert. Das Signen mit diesem Key dauert ungefähr 16 Minuten. (PGP unter Linux mit GCC2.5.7 (-O2 -m486) kompiliert.) Das Signen mit einer Borland C++ 3.1 (386, optimize speed) kompilierten Version dauert 45 Minuten.
[...]
Das Decrypten (check signature) geht etwa quadratisch mit der Keygröße, das Encrypten (sign) geht etwa hoch drei und das Keygenerieren etwa hoch vier.

Diese Angaben sind nur ungefähre Werte: PGP braucht zwei große Primzahlen. Um diese zu ermitteln, wählt es zufällig Zahlen aus und überprüft mit Hilfe einiger Tests, ob diese Primzahlen sind; d.h. die ermittelten Zeitangaben sind mehr oder weniger zufällig.

Mit der Geschwindigkeit des eigentlichen Verschlüsselns haben die Zeiten nicht viel zu tun, d.h. auch auf einem A500 ist das Arbeiten mit einem 1024bit-Schlüssel recht bequem möglich.

Wenn das Erzeugen des Schlüsselpaares abgeschlossen ist, liegt im %PGPPATH eine private und eine öffentliche Schlüsseldatei: SECRING.PGP und PUBRING.PGP, jeweils mit der entsprechenden Hälfte des Paares.

Bevor Du irgend etwas anderes machst, solltest Du jetzt unbedingt die Benutzer-ID mit Deiner Unterschrift beglaubigen:

PGP -ks <Benutzer-ID>

Damit ist sie vor Manipulationen geschützt (s.u.: "Warum soll ich meine eigenen Benutzer-IDs unterschreiben?")

Hast Du eine Sicherheitskopie Deines Schlüssels?

Auch wenn man sicherstellen muß, daß kein Fremder Zugriff auf SECRING.PGP, die private Schlüsseldatei, bekommt, muß man auf der anderen Seite darauf achten, daß man selbst nicht durch einen Festplattencrash oder einen simplen Dateifehler plötzlich ohne den eigenen Schlüssel da steht. Wenn der private Schlüssel verloren gegangen ist, kann man Nachrichten, die andere Leute mit dem öffentlichen Schlüssel verschlüsselt haben, nicht mehr entschlüsseln. Und wenn man mit 'PGP -kg' ein neues Schlüsselpaar erzeugt, ist dieses mit Sicherheit nicht mit dem verlorenen identisch. Deshalb sollte man das Schlüsselpaar auf eine Diskette kopieren und diese an einem sicheren Ort verwahren.

Wie kann ich meine Benutzer-ID ändern?

Wenn ein Benutzer unter mehreren Adressen erreichbar ist, sollte er erwägen, zusätzliche Benutzer-IDs zu seinem Schlüssel hinzuzufügen. Wenn er z.B. über sowohl über das PM-Netz als auch über Internet erreichbar ist, wäre folgendes sinnvoll:

Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>
Kanzler Helmut Kohl <birne@kanzler-amt.muftie.de>

Der Text von Benutzer-IDs kann nicht geändert werden. Statt dessen muß man die neue Benutzer-ID mit "PGP -ke" hinzufügen, dann die alte mit "PGP -kr" entfernen. Beglaubigungen der alten Benutzer-ID gehen dabei verloren (wie es sich gehört).

Wenn man eine Mail-Adresse aus irgendwelchen Gründen nicht mehr benutzen kann, kann man die zugehörige Benutzer-ID mit der aktuellen PGP-Version leider nicht 'automatisch' aus dem Verkehr ziehen. Man kann sie zwar aus der eigenen Schlüsseldatei löschen, in den Schlüsseldateien der anderen bleibt sie aber erhalten, weil PGP neue Benutzer-IDs einfach zu bestehenden hinzufügt. Als einzige Lösung ergibt sich zur Zeit das Hinzufügen einer weiteren Benutzer-ID in dieser Form:

Helmut Kohl <H.KOHL@LINK-MZ...> *NICHT mehr gültig*

Gibt es irgendwelche sinnvollen Richtlinien, welche Adressen man in den Key aufnehmen soll?

Von Richtlinien will ich nicht sprechen, eher Orientierungshilfen. Frag Dich für jede Benutzer-ID:

Kim <FIGHTER@PEOPLE-S.zer.sub.org>:

Pro Netzformat/Pollformat nur einen würde ich sagen, und zwar dann den mit dem du die meisten PM's abhandelst, außerdem für jede Box nur eine und zwar die gültige Domain, die von wo aus eh kein PM Verkehr stattfindet kann auch weggelassen werden.

Wie verteile oder bekomme ich öffentliche Schlüssel?

Die private Hälfte des Schlüssels wird benötigt, um Nachrichten zu unterschreiben oder zu entschlüsseln; die öffentliche Hälfte kann mit

PGP -kxa <Benutzer-ID> <Ausgabedatei>

in eine Datei extrahiert und auf beliebige Art und Weise an andere PGP-Benutzer verteilt werden:

Wenn man eine Datei mit einem Schlüssel erhalten hat, kann man ihn mit

PGP -ka <Dateiname>

in die eigene öffentliche Schlüsseldatei übernehmen. Ab diesem Augenblick steht er zum Verschlüsseln von Nachrichten zur Verfügung. Wenn PGP fragt, ob dieser Schlüssel beglaubigt ('certified') werden soll, mußt Du sehr genau prüfen, ob Du die Echtheit dieses Schlüssels wirklich 100%ig bestätigen kannst. Stell Dir dazu folgende Frage:

'Könnte ich vor Gericht unter Eid beschwören, daß dieser Schlüssel wirklich zu einer Person gehört, die diesen Namen trägt und unter dieser Mail-Adresse zu erreichen ist?'

Wo ist der nächste Internet/UUCP-Keyserver?

Der nächste Internet/UUCP-Keyserver ist:

--- <snip> ---
pgp-public-keys@informatik.uni-hamburg.de
Vesselin V. Bontchev <bontchev@fbihh.informatik.uni-hamburg.de> 
FTP: ftp.informatik.uni-hamburg.de:/pub/virus/misc/pubkring.pgp 
Verified: 12/24/93
--- <snap> ---

Diese Keyserver sind keine Institutionen, die Schlüssel vergeben, sondern sie nehmen sie von überall in Empfang und verteilen sie auf Anfrage weiter. Es sollte klar sein, daß Schlüssel, die man von einem Keyserver erhält, von diesem in keiner Weise überprüft wurden.

Es gibt mehrere Keyserver, die ihre Schlüsseldateien regelmäßig austauschen, d.h. es genügt, einen neuen Schlüssel an einen Keyserver zu senden, er wird von dort aus in die Welt verteilt.

Ralf Muschall <prm@rz.uni-jena.de>

Nach jüngsten Äußerungen [auf Usenet in alt.security.pgp] gilt es als unfein, fremde public-keys ohne explizite Erlaubnis des Eigentümers an Keyserver zu senden.

Keyserver bearbeiten Anfragen, die sie als Mail erhalten. Die Befehle werden im Betreff gegeben.

EMP: pgp-public-keys@informatik.uni-hamburg.de
BET: help

Um Deinen Schlüssel über die Keyserver verteilen zu lassen, schickst Du eine Nachricht wie diese an einen Keyserver:

EMP: pgp-public-keys@informatik.uni-hamburg.de
BET: add

<Text:>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a

<blablabla>
-----END PGP PUBLIC KEY BLOCK-----

Gültige Befehle sind:

ADD
Hinzufügen eines öffentlichen PGP-Schlüssels
INDEX
Liste aller Schlüssel in der Keyserver-Schlüsseldatei (pgp -kv)
VERBOSE INDEX
Liste aller Schlüssel im langen Format (pgp -kvv)
GET
Anfordern der vollständigen Keyserver-Schlüsseldatei (evtl. mehrere MB!)
GET <Benutzer-ID>
Anfordern eines bestimmten Schlüssels
MGET <regexp>
Anfordern aller Schlüssel, die auf /regexp/ passen:
MGET michael
Anfordern aller Schlüssel, die "michael" enthalten
MGET F605A5|3A738B
Anfordern dieser beiden Schlüssel-IDs

Wie gehe ich mit Schlüsseln um?

Sehr, sehr sorgfältig. Insbesondere mit der privaten Schlüsseldatei. Man sollte niemals die eigene private Schlüsseldatei auf einem fremden Rechner benutzen, um damit z.B. einen Schlüssel zu beglaubigen. Die verwendete PGP-Version könnte modifiziert sein, den privaten Schlüssel kopieren und das Mantra (die 'Pass Phrase') abfangen!

Man sollte niemals einen Schlüssel beglaubigen, solange man nicht:

Man darf den Schlüssel von X nicht einfach deshalb beglaubigen, weil Y ihn auch beglaubigt hat. DEINE Unterschrift ist DEIN Ehrenwort, daß Du sicher bist, daß dieser Schlüssel gültig ist. Wer zu lässig mit seinen Beglaubigungen umgeht, spielt mit dem Vertrauen in seine Unterschrift.

PGP warnt davor, Schlüssel zu benutzen, die nicht verifiziert sind. In gewissem Maße ist das richtig, weil z.B. jemand einen gefälschten Schlüssel verbreiten könnte. Wenn er zusätzlich noch die Möglichkeit hätte, die eingehenden Nachrichten des betroffenen PGP-Benutzers abzufangen, könnte er sie entschlüsseln, lesen, mit dem gültigen Schlüssel verpacken und an den rechtmäßigen Empfänger weiterschicken. Das ist in der Praxis recht schwierig zu arrangieren, aber nicht unmöglich.

Das bedeutet aber nicht, daß man einen unbeglaubigten Schlüssel nicht für die üblichen Nachrichten verwenden kann (quasi als 'Umschlag' für die Nachricht). Das wäre auf keinen Fall schlechter als Klartext. Andererseits sollte man den Schlüssel nicht zum Transport von Top-Secret-Material verwenden, aber wer Top-Secret-Material austauscht, hat sich vorher vermutlich schon mal persönlich getroffen.

Wenn ich den Key von jemand anders signiere, soll ich auch alle IDs signieren oder nicht?

Du darfst nur die Benutzer-IDs unterschreiben, bei denen Du absolut sicher bist, daß sie zu der betreffenden Person gehören - und das läuft darauf hinaus, daß Du sie selbst getestet und mit dem Inhaber des Schlüssels über diese Adressen erfolgreich PGP-verschlüsselte Nachrichten ausgetauscht hast.

Was ist ein Fingerprint (Fingerabdruck)?

Der Fingerabdruck ist eine mit dem Algorithmus MD5 (s.u.) berechnete "Quersumme" über die einzelnen Bits, aus denen der öffentliche Schlüssel zusammengesetzt ist.

Wenn der Fingerabdruck eines Schlüssels entsprechend weit verbreitet ist, ist der Schlüssel sicher davor, unbemerkt von einem auf dem Nachrichtenweg lauernden Bösewicht ausgetauscht zu werden, weil es praktisch unmöglich ist, einen zu einem vorgegebenen Fingerabdruck passenden Schlüssel zu generieren.

Wenn man eine Person, deren Schlüssel nicht verifiziert ist, gut genug kennt, um ihre Stimme am Telefon zu erkennen, kann man sie anrufen und bitten, den 'Fingerabdruck' des Schlüssels vorzulesen, denn man mit

PGP -kvc <ID>

erhält. Es ist Dir überlassen, ob Du aufgrund dieser Überprüfung einen Schlüssel unterschreibst. Das sollte man IMHO wirklich nur tun, wenn es sich um jemanden handelt, den man gut kennt.

Je mehr öffentliche Schlüssel Deine eigene Schlüsseldatei enthält, desto größer wird die Wahrscheinlichkeit, daß PGP eine 'Beglaubigungskette' von Dir zum beabsichtigten Empfänger ziehen kann.

Was ist MD5?

Abel Deuring <A.DEURING@BIONIC.zer.de>:

MD5 (Message Digest 5) ist ein Algorithmus, der eine Art "Quersumme" über einen Datenblock beliebiger Länge berechnet. Im Gegensatz zu einfachen Quersummen oder CRC-Summen ist aber kein Verfahren bekannt, das es ermöglicht, einen Datenblock gezielt so zu verändern, daß der geänderte Datenblock die gleiche MD5-Summe hat wie der originale Datenblock. MD5 kann deshalb für die Kontrolle der "Echtheit" einen Datenblocks verwendet werden. PGP verwendet MD5 an zwei Stellen: Für die digitale Unterschrift und für den Fingerabdruck eines öffentlichen Schlüssels.

Warum soll ich meine eigenen Benutzer-IDs unterschreiben?

Damit man sicher sein kann, daß sie nicht nachträglich manipuliert wurden. Mit entsprechender Kenntnis des Aufbaus von PGP Schlüsseln läßt sich aus:

Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>

folgendes machen:

Helmut Kohl <H.KOHL@bong.saar.de>

Und schon bekomme ich einen Teil der Post unseres Kanzlers (nämlich den der Leute, die ihre Schlüsseldatei als Adreßbuch verwenden, s.o.). Ich kann sie zwar nicht lesen, dafür fehlt mir ja der private Birnen-Schlüssel, aber er bekommt diese Nachrichten nie zu sehen. Daher bezeichnet man das als 'Denial of Service-Attack'.

Jede Benutzer-ID sollte einzeln unterschrieben werden, eine Schlüssel, der folgendes Bild trägt, ist fast schon verdächtig:

Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>
(beglaubigt von Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>) 
Kanzler Helmut Kohl <birne@bong.saar.de>

und diese Version sollte bei jedem PGP-Benutzer eine Warnlampe aufleuchten lassen:

Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>
  (beglaubigt von Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>) 
Kanzler Helmut Kohl <birne@kanzler-amt.muftie.de>
  (beglaubigt von Helmut Kohl <H.KOHL@LINK-MZ.comlink.de>) 
GEÄNDERTE BENUTZER-ID! BITTE *ALLES* NUR NOCH AN:
Mr Helmuth Kohl <H.KOHL@research.cia.gov>

Was ist pmCrypt?

Vorwort (aus der XPOINT.DOC von Peter Mandrella <P.Mandrella@LDB.han.de>):

pmCrypt
pmCrypt ist ein von Christian Mock entwickeltes Verfahren, um beliebige Codierprogramme in beliebige Z-Netz-kompatible Pointprogramme einzubinden. CrossPoint erweitert die Verwendung von pmCrypt auf sämtliche anderen Netztypen. Sofern die Nachrichten nach dem Codieren ASCII-Format haben, funktioniert es sogar netzübergreifend.

pmCrypt fungiert in CrossPoint, The Answer und anderen Pointprogrammen als Schnittstelle zwischen Pointware und Verschlüsselungsprogramm. Die Nachricht wird ins Netcall-Format Z3.8 umgewandelt, das heutzutage eigentlich niemand mehr benutzen sollte, ;) aber das irgendwie immer noch den kleinsten gemeinsamen Nenner darstellt. Sie besteht dann aus acht Zeilen Z3.8-Header (Empfänger, Betreff, Absender, Datum/Zeit, Pfad, MsgID, Typ, Länge), der Nachrichtentext folgt nach einer Leerzeile:

DUMMY@FUPPES.ZER
Dies ist der Betreff der Nachricht
4-TEA-2@HIT.ZER
9404031458
HIT!FUPPES
5MBWU_E_Q1B@hit68.hit.zer.de
T
172

Text... High there, Dummy!

Diese Datei wird mit dem als pmCrypt-Codierer eingetragenen Befehl verschlüsselt. Das Ergebnis dieser Verschlüsselung erhält einen neuen Header, abhängig vom verwendeten Netztyp, d.h. in der Regel nicht Z3.8, bei dem die Betreffzeile mit "*crypted*" anfängt - der Rest der Zeile kann vom Programmierer der jeweiligen pmCrypt-Routine nach eigenem Belieben zusammengestellt werden.

Per pmCrypt verschlüsselte Nachrichten sind per Definition als Binärnachrichten zu verschicken. "Seit PGP" macht das keinen Sinn mehr, da PGP mit der Option (Befehlszeile:) "-a" oder (Konfigurationsdatei:) "Armor = On" die Nachrichten automatisch so einpackt, daß sie als Textnachricht über alle Gateways hinweg und durch alle Netze hindurch problemlos verschickt werden können.

Peter Mandrella <P.Mandrella@LDB.han.de>:

Wer pmCrypt-Nachrichten mit THE-ANSWER-Usern austauscht, muß weiterhin binäre pmCrypt-Nachrichten erzeugen lassen. Für den Austausch zwischen CrossPoint-Usern empfehle ich dagegen, für PGP den Binärschalter generell zu deaktivieren. Damit läßt sich die PGP-pmCrypt-Codierung dann bequem über alle Gateways hinweg in allen von XP unterstützten Netzen verwenden.

Was ZConnect betrifft, ist pmCrypt ist eine Art 'Übergangslösung' bis zur 'Einsatzreife' (und entsprechenden Verbreitung) von ZC3.1, in dem PGP dann integraler Bestandteil sein wird.

Wie bindet man PGP mit pmCrypt in ein Pointprogramm ein?

pmCrypt braucht drei Angaben, um ein Verschlüsselungsprogramm benutzen zu können: die Bezeichnung, die Befehlszeile zum Verschlüsseln und die zum Entschlüsseln. Für PGP könnten Angaben so lauten:

Bezeichnung
PGP
Codierer
PGP -et <Eingabedatei> "<Benutzer-ID>" -o <Ausgabedatei>
Decodierer
PGP <Eingabedatei> -o <Ausgabedatei>

Die Befehlszeilen für CrossPoint lauten also:

Codierer:
PGP -et $INFILE "$KEY" -o $OUTFILE
Decodierer:
PGP $INFILE -o $OUTFILE

Wenn man die Nachrichten außerdem noch automatisch mit einer Unterschrift versehen möchte, braucht der Codierer den Befehl '-s':

Codierer:
PGP -set <Eingabedatei> "<Benutzer-ID>" -o <Ausgabedatei>

also für XP:

Codierer
PGP -set $INFILE "$KEY" -o $OUTFILE

Wer automatische, unbeaufsichtigte Netcalls durchführt, wird zu schätzen wissen, daß man PGP auch anweisen kann, keine Eingaben von Tastatur zu verlangen, da pmCrypt-Nachrichten in der Regel unmittelbar nach dem Netcall beim Einsortieren der Nachrichten entschlüsselt werden. Dazu gibt man auf der Befehlszeile '+BATCHMODE' an, also:

Decodierer:
PGP +BATCHMODE <Eingabedatei> -o <Ausgabedatei>

also für XP:

Decodierer:
PGP +BATCHMODE $INFILE -o $OUTFILE

Was soll ich bei pmCrypt als 'Paßwort' eintragen?

PGP verwendet das RSA-Public Keys, braucht also kein Paßwort, sondern die Benutzer-ID des Empfängers, mit deren Hilfe es sich den Schlüssel selbständig aus der öffentlichen Schlüsseldatei heraussucht.

Paßwort: Marc

Das reicht sicher nicht aus. Auch wenn es zu Anfang ausreichen mag, eine ID kurz und prägnant anzugeben, so sollte man doch bedenken, daß sie auch eindeutig bleiben muß, wenn weitere Schlüssel zur Schlüsseldatei dazukommen. Sicherer wären:

Paßwort: 4-tea-2@HIT oder: Paßwort: Marc Aurel

Weil in der Benutzer-ID Leerzeichen enthalten sein können, ist sie im o.a. Codierer-Aufruf in Anführungszeichen eingeschlossen. Und schließlich gibt es die Möglichkeit, den Schlüssel direkt über die Schlüssel-ID auszuwählen, was am sichersten und schnellsten ist. Dabei stellt man als Kennung '0x' vor die ID:

Paßwort: 0xB556C3

Was ist in CONFIG.TXT zu ändern?

Auswahl der Sprache

Language = de

Natürlich wird diese Einstellung erst aktiv, wenn auch die entsprechende LANGUAGE.TXT-Datei vorliegt.

Zeichensatz-Einstellung

PGP übernimmt die Konvertierung von Umlauten, Sonderzeichen und Zeilenenden.

Für DOS (und Atari?):

CharSet = cp850

Für AMIGA und andere ISO-Systeme:

CharSet = LATIN1

Da mag es Probleme geben, wenn die Pointprogramme Umlaute vor dem Verschlüsseln in den Z-Netz-üblichen PC-Zeichensatz umwandeln. Müßte man ausprobieren...

Christopher Creutzig <C.CREUTZIG@hot.gun.de>:

Bitte bitte, liebe TA-User: Benutzt einen Aufruf a la "pgp -set +charset=cp850...", sonst kommen Eure Umlaute nur bei den DOS-Usern und bei anderen TA-Usern korrekt an, und das auch eher zufällig.

Vom korrekten Setzen von CharSet ist auch abhängig, ob die Umlaute der Sprachdateien (LANGUAGE.TXT) richtig angezeigt werden können!

ASCII-Versandhülle

Für pmCrypt (und in der Regel auch anderswo):

Armorlines = 0

Diese Einstellung verhindert, daß PGP überlange Nachrichten selbständig in mehrere Happen zerlegt (denn das versteht pmCrypt nicht).

Für pmCrypt (jetzt):

Armor = off

Mit dieser Einstellung enthält die von PGP verschlüsselte Datei Binärdaten, kann also nur als Binärnachricht verschickt werden.

Für pmCrypt (hoffentlich in Zukunft) und andere:

Armor = on

Wo keine Binärnachrichten verschickt werden können, kann PGP den verschlüsselten Text selbst in eine Datei 'verpacken', die nur durch alle Netze transportierbare ASCII-Zeichen enthält und zusätzlich mit einer Start- und Endzeile versehen ist.

Textmodus

TextMode = on

Nur in diesem Modus werden die Umlaute und Zeilenende konvertiert (sofern CharSet richtig gesetzt ist). PGP erkennt trotzdem, wenn eine Binärdatei verschlüsselt werden soll und schaltet den TextMode dann selbständig aus.

Welche Environment-Variablen müssen/sollen gesetzt werden?

(Bitte berücksichtigt die system-üblichen Konventionen der SET-Befehle, benutzt also ggf. "setenv <Variable> <Inhalt>" oder sonstwas statt dem von mir verwendeten DOS-mäßigen "SET <variable>=<inhalt>".)

SET pgppath=<Pfad>

Im angegebenen Verzeichnis befinden sich die Schlüsseldateien und diverse Hilfsdateien, die PGP benötigt.

SET tz=<Zeitzone>

Hagen Kliemann <H.KLIEMANN@LINK-M.muc.de>:

In SETUP.DOC für MSDOS steht:
For Amsterdam: SET TZ=MET-1DST
Ich denke dieser Eintrag ist auch für uns relevant.
Dazu will ich ergänzen:
Der Zeitzoneneintrag bezieht sich auf die Umrechnung der intern von C verwendeten Zeit und hat immer folgenden Aufbau:
TZ=xxx[-]dyyy
wobei xxx der Name der Zeitzone ist, [-]d die Anzahl der Stunden ist, die zur Lokalzeit hinzugerechnet werden müssen, um die GMT zu erhalten, und yyy bezeichnet die optionale Angabe der Sommerzeit.
Nach meinen Erfahrungen werden die Bezeichnungen der Zonen nirgendwo ausgewertet (Vielleicht ist das aber auch vom verwendeten C-Compiler abhängig ??). Deshalb besteht bei der Sommerzeit das Problem, daß angenommen wird (wie in Amerika üblich), daß die Umstellung von Sommer- auf Winterzeit am 1.Sonntag im Oktober und die Umstellung von Sommer- auf Winterzeit am 1. Sonntag im April stattfindet.
Will sagen mit dem Sommerzeiteintrag können wir wahrscheinlich nichts anfangen und müssen statt dessen im Sommer
SET TZ=MES-2
und im Winter
SET TZ=MET-1
benutzen.

Abel Deuring <A.DEURING@BIONIC.zer.de>:

Der einfachste Ausweg ist übrigens: Kümmer Dich einfach nicht um das Problem :) Der einzige Nachteil ist, daß alle PGP-Zeitangaben bei Dir um sechs Stunden (hoffentlich richtig gerechnet :) in die Zukunft verschoben sind. Wenn ich die älteren Diskussionen um falsche Zeitangaben richtig verstanden habe, ist dann das einzige Problem, daß Daten, die Du mit PGP bearbeitet hast, erst sechs Stunden später von der PGP-Implementierung bei anderen Leuten akzeptiert werden, weil PGP Zeitangaben "aus der Zukunft" nicht mag. Aber wenn Deine KorrespondenzpartnerInnen dies Problem kennen, sollten sie auch damit umgehen können.

SET pgppass=<Mantra/Paßsatz/Pass Phrase>

Das Zugangspaßwort zum privaten Schlüssel in die AUTOEXEC.BAT zu setzen - um das automatische Entschlüsseln von pmCrypt-Nachrichten bei automatisierten Schaltuhr-Netcalls zu ermöglichen - sollte man nur riskieren, wenn man hundertprozentige Kontrolle über den verwendeten Rechner hat.

Unter Umständen mag es in diesem Zusammenhang besser sein, ganz auf eine 'Pass Phrase' für den geheimen Schlüssel zu verzichten, um keine Unnötige Aufmerksamkeit zu erregen.

Für alle, die das Pollen von Hand starten, bietet sich an, XP mit einer kleinen Batchdatei zu starten, die das Mantra mit Hilfe eines Tools wie 'ASK' oder 'INPUT' abfrägt, etwa:

--- <snip> --- [ Beispiel für XP.BAT ] ---
INPUT "Mantra? " %%PGPPASS
c:\xp\xp %1 %2 %3 %4 %5 %6 %7 %8 %9
SET PGPPASS=
--- <snap> ---

(4DOS/NDOS - Keine Ahnung, wie 'INPUT' mit DOS geht...)

Wie kann ich eingehende PGP-Schlüssel automatisch übernehmen?

[CrossPoint-Version]

Nicht ganz automatisch, aber halbautomatisch:

Das Hinzufügen von Schlüsseln zu Deiner PGP-Schlüsseldatei ('Key Ring') läßt sich z.B. mit folgendem F-Tasten- oder Zusatz-Menü-Makro 'halbautomatisieren':

Menüanzeige  PGP-Schlüssel
Programmname PGP -ka +BATCHMODE $FILE
$FILE-Nachr. ohne Kopf [ ] aus Betreff
[ ] Warten
[ ] Vollbild Speicher: 500 KByte
[x] Ausgabe an Lister
[ ] AUTOEXEC-Verzeichnis bearbeiten

Die einfachste Methode, alle Schlüssel automatisch einzulesen, ist folgender Befehl als Eingangsfilter:

PGP -ka +batchmode $PUFFER

Was mache ich, wenn mir das alles zu kompliziert ist?

[CrossPoint-Version]

Du besorgst Dir das Programm XP-PGP von Matthias Jordan <MICROBODY@WIREPOOL.gun.de>, das die Installation von PGP im CrossPoint automagisch vornimmt.

[AMIGA-Version]

Du besorgst Dir das Installations-Script von Christopher Creutzig <C.CREUTZIG@HOT.gun.de>.

Wie muß man beim Zurückziehen eines PGP-Schlüssels vorgehen?

Henning Hucke <H_HUCKE@DARKNESS.gun.de>:

Einfach mit '-kd' Deinen Key revoken. Wenn Du Deinen Key dann mit '-kx' extrahierst, dann ist dies das sogenannte Revokation-Zertifikat. Jeder der dieses 'Ding' zu seinem Keyring hinzufügt, bekommt Deinen Key als ungültig markiert. Also:
PGP -kd <UserID)
pgp -kx <UserID> revokation
und beim Empfänger Deines Keys dann
PGP -ka revokation.pgp
und fertig.
Wenn Du Deinen neuen Key gleich mit rein packen willst, dann kannst Du einen neuen generieren und dann mit
pgp -kx <UserID> revokation
dem File hinzufügen. Der Empfänger bekommt dann Revokation und neuen Key in einem Rutsch. Wenn Du das ganze als ASCII-armored haben willst, kannst Du das mit folgenden Kommandos machen:
pgp -fkx <UserID> >revokation.asc
pgp -kg
pgp -fkx <UserID> >>revokation.asc

Disclaimer

ZConnect gehört der Zerberus GmbH. Sorry an die LINK-MZ, der ich den Beispiel-Benutzer angedichtet habe. Bis jetzt hat sich noch niemand bei mir beschwert; ich nehme an, die LINK-MZ bekommt /T-NETZ/PGP/ALLGEMEIN gar nicht. ;)

Credits

Ein großer Teil der FAQ basiert auf der Archimedes-PGP-FAQ von Paul L. Allen <pla@sktb.demon.co.uk>.

Weitere Beiträge stammen von:

Ansgar Spiertz <A.SPIERTZ@AWORLD.aworld.de>, Boris Mogwitz <B.MOGWITZ@BHT-BOX.zer.de>, Garry Glendown <SYSOP@INSIDER.zer.sub.org>, Hagen Kliemann <H.KLIEMANN@LINK-M.muc.de>, Henning Hucke <H_HUCKE@DARKNESS.gun.de>, Jan Groth <J.GROTH@TBX.berlinet.in-berlin.de>, Jürgen Gebneda <WHISTLER@IUS.gun.de>, Hauke Lampe <Packbart@PEOPLE-S.zer.sub.org>, Kim <FIGHTER@PEOPLE-S.zer.sub.org>, Martin Emmerich <me@grmbl.saar.de>, ms1207@cd4680fs.rrze.uni-erlangen.de, //padeluun <padeluun@BIONIC.zer.de>, Peter Simons <simons@peti.gun.de>, Peter Klein <PEK@FLATTER.zer.sub.org>, Ralf Muschall <prm@rz.uni-jena.de>, Robin Wöhler <ROBIN_WOEHLER@EUROPE.ZER.sub.org>, Rolf-Dieter Lucius <R.-D.LUCIUS@BIONIC.zer.de>, Toni <WEGAR@AMC.zer.sub.org>, YOOBOO@SUNBURN.zer.sub.org

...und aus /T-NETZ/PGP/ALLGEMEIN.

Und ein besonderer Dank an:

Nachwort

Ich weiß, ich hab die Hälfte der Änderungsvorschläge, die seit dem letzten Posting bei mir eintrafen, verschlampt. Habt Geduld mit mir, danke. ;)