Pretty Good Privacy - PGP

Version 2.6.3i(a) mit Anmerkungen zu PGP Versionen 5/6

Installation und Anwendung von PGP
im Amateurfunk

Aufbauend auf einem Text von Perry Metzger, Colin Plumb, Derek Atkins, Jeffrey I. Schiller und anderen
Angepasst für PGP 2.6.3i durch Stale Schumacher

Übersetzt und angepasst
für den Amateurfunkbereich durch DG9EP

Mit Beiträgen von DH1DAE, DC8YH und GW6ZUS

Version 1.13
8. November 1999

INHALT

Vorbemerkungen:

Schnellstart

Möchte man PGP verwenden, so geht man am besten folgendermassen vor:

Was ist PGP ?

von Ulf, DH1DAE@DB0SGL

Mit PGP kann man Texte und Dateien elektronisch unterschreiben, und so gegen Fälschung schützen.

Die prinzipielle Funktionsweise von PGP ist ganz einfach. Da für den Amateurfunk nur die Signaturfunktion interessant ist, werde ich in der folgenden Beschreibung (die im uebrigen keinen Anspruch auf wissenschaftlichen Wert erhebt, hi) ausschliesslich auf diese eingehen.

Was ist ueberhaupt eine digitale Signatur?

Eine digitale Signatur (oder auch digitale Unterschrift) erlaubt einen eindeutigen Rueckschluss auf den Absender einer Nachricht. Sie steht in direktem Zusammenhang mit der zugehoerigen Nachricht (Pruefsumme), daher wird sie sofort ungueltig, sobald der Originaltext veraendert wird.

Wie wurde die digitale Signatur in PGP realisiert?

Eine digitale Signatur muß sicher vor Manipulation sein, sonst macht sie keinen Sinn. Aus diesem Grund wird sie verschluesselt uebertragen, d.h. sie wird mit einem bestimmten Schluessel codiert und kann nur mit einem bestimmten Schluessel wieder decodiert werden.

Man erzeugt zunaechst also zwei Schluessel; Einer davon (der "private key") verbleibt bei seinem Erzeuger und darf nicht in fremde Haende gelangen. Der andere (public key) hingegen wird oeffentlich bekanntgegeben.

Der "private key" dient nun zur Erzeugung von digitalen Signaturen, waehrend der "public key" ausschliesslich zur Ueberpruefung der Unterschriften verwendet werden kann. Das Ergebnis der Ueberpruefung wird dann auf dem Bildschirm angezeigt.

Ein positives Ergebnis wird nur dann erreicht, wenn folgende Bedingungen erfuellt sind:
1. Die Nachricht wurde nach ihrer Unterzeichnung nicht veraendert
2. Die Signatur wurde mit dem passenden "private key" erstellt
Um Punkt 2 braucht man sich nicht selbst zu kuemmern, PGP verwaltet alle Schluessel selbst und sucht den passenden selbststaendig aus, sofern er vorhanden ist.

Wie erkenne ich nun, wer der Eigentuemer des jeweiligen Schluessels ist?

Jeder Schluessel beinhaltet eine Art Schluesselanhaenger (einen sogenannten "User-Identifier"), auf dem der Name des Besitzers steht. Dieser Name wird bei einer positiven Signaturpruefung angezeigt.

Im Amateurfunk ist es sinnvoll, zusätzlich sein Rufzeichen anzugeben:

Walter Koch <dg9ep>
Leider hat es sich eingebuergert zusätzlich zum Rufzeichen die Heimatbox anzugeben. Das hat den Nachteil, dass beim Wechsel der Box die User-ID geändert werden müsste. Ein Beispiel: 
  xxxxx schrieb:
  > Nachfolgend mein Key mit einer neuen ID für AFU, da sich das Call
  > meiner Heimat-Mailbox geändert hat.

  Aus diesem Grund ist es nicht unbedingt empfehlenswert, seine Mail-Adresse in 
  die User-ID aufzunehmen. Fuer eine Benutzung im Internet ist die Angabe einer 
  e-mail-Adresse noch nachvollziehbar, da der Name allein nicht eindeutig genug 
  ist. (Zertifizierungsstellen weigern sich eventuell, solche nicht-eindeutigen 
  User-IDs zu beglaubigen)
  Wir Funkamateure haben jedoch unser Rufzeichen, was bekanntlich weltweit nur 
  ein einziges Mal vergeben wird, wodurch die alleinige Angabe des Rufzeichens 
  fuer eine eindeutige User-ID schon vollkommen ausreicht. Der Name sollte 
  allerdings ebenfalls enthalten sein.

  (dh1dae 11/98)
Wobei noch zu erwähnen ist, daß das Rufzeichen zusammen mit dem Erstellungsdatum des Schlüssels absolut eindeutig ist: So gab es am 29.8.1995 (Erstellungsdatum meines Schlüssels) nur einen Funker mit dem Rufzeichen DG9EP: nämlich mich, Walter Koch :-)

Wie kann ich denn sicher sein, dass die Informationen im "User-Identifier" auch stimmen?

Natuerlich muß man sich erst einmal davon überzeugen, ob ein bestimmter Schluessel auch wirklich von der Person stammt, deren Name auf dem "Schluesselanhaenger" steht. Dies kann man entweder selbst tun, indem man sich mit dieser Person auf direktem Wege in Verbindung setzt (nicht via Packet Radio!), oder man vertraut den Beglaubigungen dritter.

Diese Thematik ist das einzig "komplizierte" an PGP. Darauf will ich an dieser Stelle auch nicht weiter eingehen, da es in der PGP-Dokumentation beschrieben wird. Es ist zwar nicht wirklich kompliziert, doch hat sich in der Vergangenheit gezeigt, dass sich einige Leute gerade mit diesen (eigentlich sehr einfachen) grundsaetzlichen Zusammenhaengen etwas schwer tun. Informationen zur Beglaubigung von fremden Schluessen findet man auch in der Rubrik PGP, sofern sie eine entsprechende Lifetime besitzt.

Warum braucht man denn ueberhaupt zwei Schluessel?

Die Aufteilung in einen geheimen und einen oeffentlichen Schluessel hat einen ganz einfachen Grund:
Stellen wir uns einfach einmal vor, man haette nur einen einzigen Schluessel, der für beides zustaendig waere; Also sowohl für die Erzeugung als auch für die Ueberpruefung einer Signatur. Na, Frage beantwortet? ;-)

Kann PGP Rechtschreibfehler erkennen und korrigieren?

Nein.

Kann PGP Kaffee kochen?

;-)

Entnommen aus

re: Was ist PGP
Bulletin-ID: 234702DB0SGL
PGP @DL de:DH1DAE 23.04.97 13:18  4287 Bytes

PGP besorgen

In den AFu Mailboxen wurden Versionen eingespielt (z.B. von DL1ALL im April 96). Sie befinden sich entweder in der Rubrik PGP (z.B. in DB0IZ-0 oder bei DB0AAB), oder auf einem EL Server (z.B. bei DB0GV: EL S PGP ).

In anderen Boxen wird es wohl ähnlich sein.

Auf der ADACOM - CD-ROM von April 97 sind Versionen für OS/2, DOS, Windows 3.1 und Windows 95 enthalten.

Im Internet z.B. auf dem Server des Heise-Verlags und auf der internationalen PGP-Homepage.

Wie installiert man PGP?

PGP wird als Archiv verteilt. Die Versionen 5.0i und 2.6.3i wurden mit ZIP gepackt, Version 5.5.3i ist eine selbstentpackende EXE-Datei. Dadurch hat man alle Dateien am Stück zusammen und man spart Platz auf der Platte und Übertragungszeit.

Beispielsweise heißen die Datein der Version 2.6.3i:

  PGP263I.ZIP      (MSDOS 16-bit)
  PGP263IX.ZIP     (MSDOS 32-bit)
  PGP263I2.ZIP     (OS/2 FAT)
  pgp263i-os2.zip  (OS/2 HPFS)
Diese Archive enthalten die ausführbaren Dateien, die Dokumentation (in englisch) und einige Schlüssel (keys) und Unterschriften (signatures). Deutsche Hilfetexte gibt es in extra Dateien auf den meisten Servern. Den aktuellen Stand der deutschen Übersetzung der Dokumentation für die neuesten PGP-Versionen kann man auf den internationalen PGP-Seiten nachschauen ("language support, German").

Der Quellcode (C und Assmbler) ist ebenfalls erhältlich (PGP263IS.ZIP). Man sollte ihn am selben Ort finden, wo man auch die anderen Archive her hat. Falls nicht, sendet eine E-Mail an pgp@hypnotech.com mit dem Titel (subject field): "INFO PGP" [oder per PR an dg9ep@db0iz].

Man benötigt PKUNZIP version 2.0 (oder höher) um das Archiv auszupacken. PKUNZIP ist Shareware und ist im allgemeinen auf DOS und OS/2 Rechnern bereits vorhanden [Ebenso ist i.a. auch der kostenlose Klon UNZIP.EXE einsetzbar]. Das Auspackprogramm muß natürlich im Pfad liegen.

Nun muß ein Verzeichniss für die PGP Dateien erstellt werden. In dieser Doku verwenden wir C:\PGP als Beispiel, aber man kann das natürlich auf seine eigenen Verhältnisse anpassen. [So liegt PGP bei mir z.B. auf F:\AFU\PGP].

Man gebe also auf der Kommandozeile folgende Kommandos ein [in Windows erreichbar in der Hauptgruppe als "MSDOS-Eingabeaufforderung"]:

   c:
   md \pgp
   cd \pgp
Nun packen wir das Archiv in diesem Verzeichnis aus. Wir gehen mal davon aus, daß dieses ZIP-Archiv auf Diskette im Laufwerk A: liegt:
   pkunzip -d a:pgp263i
Das erzeugt dann die Dateien PGP263II.ZIP und PGP263II.ASC. PGP263II.ZIP muß nochmals ausgepackt werden, mit dem Kommando:
   pkunzip -d pgp263ii
Wenn man hier das "-d" nicht angibt, werden die Dateien, die normalerweise in einem DOC-Unterverzeichnis gelandet wären, im C:\PGP gelandet. Das ist dann m.E. etwas unübersichtlich.

PGP263II.ZIP sollte aber nicht gelöscht werden. Wenn PGP gleich läuft, kann man mittels PGP263II.ASC die digitale Unterschrift unter PGP263II.ZIP prüfen. Es sollte die von Stale Schumacher sein (dessen Schlüssel in KEYS.ASC drin ist).

Die Umgebung einrichten

Als nächstes kann man eine Umgebungsvariable des Betriebssystems ("environment variable") setzen, damit PGP weiss, wo es seine Hilfsdateien findet, falls man PGP aus einen anderen als dem PGP-Verzeichnis ausführen will.

Mit jedem beliebigen Editor (z.B. EDIT unter DOS; NotePad/Editor unter Windows) kann man folgenden Zeile in die Datei AUTOEXEC.BAT (DOS) oder CONFIG.SYS (OS/2) (üblicherweise sind die auf der C: Platte) einfügen:

   SET PGPPATH=C:\PGP
   SET PATH=C:\PGP;%PATH%
Wenn man ein anderes Verzeichnis als C:\PGP verwendet, muß man dann dieses im obigen Beispiel einsetzen.

Die CONFIG.TXT Datei enthält einige Voreinstellungen. Man kann damit die Sprache änderen, in denen PGP sich äussert, und den Zeichensatz der in den Texten verwendet wird.

Auf IBM-kompatiblen PCs nennt man den normalen Zeichensatz "Code Page 850" und dieser wird benutzt indem man die Zeile

 charset = cp850
in die Datei CONFIG.TXT einfügt. Da dies fast immer passend ist, sollte man diese Zeile in die Datei CONFIG.TXT einfügen.

Als Deutschsprachiger sollte man in der Datei CONFIG.TXT die Zeile

  Language = en
durch
  Language = de
ersetzen. Dann spricht PGP auch deutsch.

Eine andere Variable, die man setzen sollte, heisst "TZ". Diese sagt dem Betriebssystem, in welcher Zeitzone man sich befindet. Dadurch kann PGP die Uhrzeit für Schlüssel und Unterschriften in GMT speichern ("create GMT timestamps").

Wenn man TZ in der AUTOEXEC.BAT (bzw. CONFIG.SYS) richtig einstellt, wird MSDOS (bzw. OS/2) brauchbare GMT-Uhrzeiten erzeugen und automatisch Sommer- und Winterzeit berücksichtigen.

Ein paar Beispieleinstellungen: 

Los Angeles:  SET TZ=PST8PDT
Arizona:      SET TZ=MST7                     (Arizona hat keine Sommerzeit!)
New York:     SET TZ=EST5EDT
London:       SET TZ=GMT0BST
Düsseldorf:   SET TZ=MET-1DST
      oder:   SET TZ=CET-1DST
Moscow:       SET TZ=MSK-3MSD
Aukland:      SET TZ=NZT-12DST
[Da sind unsere Freunde etwas zu optimistisch. Im Dunstkreis von Win95 und TZ habe ich schon einige graue Haare gekriegt.... Man sollte TZ unter DOS und Windows 9x - sofern es nicht schon eingetellt ist - gar nicht einstellen sondern in der CONFIG.TXT die Einstellung TZFIX auf -8 (MEZ-Winterzeit) oder -9 (MESZ) stellen. ]

So. Nun muß man wieder booten, damit PGPPATH und TZ wirksam werden [furchtbar wg. jedem Mist muß man diese Rechner booten]

Wenn man nach dem Booten in das Verzeichniss C:\PGP (oder wie auch immer es bei dir heisst) geht, und dort PGP eingibt, sollte sich PGP melden und höflich vorstellen

Den eigenen Schlüssel erzeugen

Eine der ersten Sachen, die man wirklich mit PGP machen will (ausser es einfach nur zu testen) ist die Erzeugung eines eigenen Schlüssels. Dies ist detaillierter im Kapitel "RSA Key Generation" des PGP-Handbuchs beschrieben.

Man sollte sich klarmachen, daß der Schlüssel so etwas wie eine geschriebe Unterschrift, die PIN der Scheckkarte oder der Generalschlüssel eines Hauses ist - Also muß man ihn geheim und verschlossen halten.

Also: PGP -kg eingeben, und schon geht die Fragerei los.

Als erstes wird nach der Schlüssellänge gefragt. 1024 ist m.E. empfehlenswert und wird zur Zeit am häufigsten verwendet. Je höher die Schlüssellänge ist, desto "sicherer" ist der Schlüssel, aber um so länger dauern die damit verbundenen Operationen.

Anschliessend wird nach der BenutzerID (UserID) gefragt. M.E. sollte diese für den AFu Bereich etwa so aussehen: 

   Vorname Nachname <Rufzeichen>
also z.B. 
   Walter Koch <dg9ep>
Man kann die UserID zwar später jederzeit ändern, doch damit werden auf diese UserID gemüntzte Beglaubigungen des Schlüssels wertlos.

Wie bereits erwähnt, sollte die Heimatmailbox nicht in die ID mit aufgenommen werden.

Möchte man PGP auch im nicht-AFu-Bereich einsetzten, so gibt es für die UserID 2 Möglichkeiten:
Entweder man waehlt dafür eine zweite zusätzliche, andere UserID (z.B. 

   Walter Koch <koch@hsp.de>
oder man kombiniert beide Angaben: 
   Walter Koch, DG9EP <koch@hsp.de>
Ich bevorzuge die zweite Methode, da mehrere UserIDs auch mehrere Beglaubigungen erfordern wuerden. Ausserdem kann man bei PGP leider nicht festlegen, welche UserID beim Ueberpruefenden bevorzugt angezeigt wird.

Jetzt wird man nach dem "Mantra", einer Folge von Wörtern gefragt. Mit diesem Mantra wird die Datei SECRING.PGP vor Ausspähung geschützt. SECRING.PGP enthält den geheimen Schlüssel und ist nur mit Hilfe des Mantras zugreifbar.

Verwende ein langes, nicht zu erratendes und nicht triviales Mantra. Vergiss dieses Mantra nicht!

Warum wird der Begriff "Mantra" anstelle "Paßwort" 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 "Mantra" benutzt, um die Leute zu drängen, wenigstens mehrere beziehungslose Worte hintereinander als Mantra zu verwenden.

(Nach der deutschen Übersetzung der Usenet-FAQ von comp.security.pgp, http://www.iks-jena.de/mitarb/lutz/security/pgpfaq.html)

Jetzt wird es scheinbar etwas seltsam bis magisch. PGP bittet einen nämlich irgendwelchen Text auf der Tastatur zu schreiben (und bei den Windows Versionen von PGP die Maus zu bewegen), um aus der Zeit zwischen den Tastendrücken einen zufälliges Schlüsselpaar zu bestimmen. Die genaue Erklärung und Begründung dafür ist etwas aufwendiger. Deswegen spare ich sie mir hier.

Tut einfach das, was PGP Euch sagt :-)

Anschliessend rödelt der Rechner eine ganze Weile, und wenn er dann fertig ist, gibt es zwei neue Dateien (Schlüsselbund/Keyring):

Beide Dateien nun sofort auf eine Diskette kopieren, die anschliessend schreibgeschützt wird (den kleinen Schieber schieben). Denn nichts ist peinlicher als wenn der Schlüssel durch Plattencrash verloren geht und man Nachrichten erhält, die man nicht mehr entschlüsseln kann.

Noch besser: Hier steht, wie man direkt nach der Schlüsselerzeugung den Widerruf auf Vorrat erzeugen kann.

Jetzt kann man auch einige andere öffentliche Schlüssel in den Schlüsselbund reintun. Als Beispiel sind ein paar Beispielschlüssel in der Datei KEYS.ASC zu finden.

Man fügt sie hinzu in dem man einfach 

  PGP -ka KEYS.ASC
eingibt.

Hinweis

Mit dem so erzeugten Schluessel sollte man nur SIGNIEREN und nicht auch noch (in anderen Netzen) VERSCHLUESSELN. Die Begruendung dafür ist etwas umfangreicher und in [Wobst] beschrieben. Will man auch verschluesseln (natuerlich nicht für AFu-Zwecke), so sollte man sich dafür extra einen eigenen Schluessel erzeugen. In diesem Fall wuerde man dann auch in den BenutzerIDs beider Schluessel deren Zweck kennzeichnen, etwa mittels angehaengtem (sig) und (cryp)
Ab PGP5 werden automatisch verschiedene Schlüsselpaare zum Signieren und Verschlüsseln erzeugt, da braucht sich der Benutzer also nicht drum zu kümmern.

Überprüfung der PGP Auslieferung

So, da PGP läuft und einige öffentlich Schlüssel (z.B. aus KEYS.ASC) drin sind, kann man die Seriösität der benutzen Auslieferung ("distribution") überprüfen.

Das geht so: 

   pgp pgp263ii.asc
PGP sagt dann, daß pgp263ii.asc eine Unterschrift, aber keinen Text enthält. Es fordert einen dann wohl auf einen Dateinamen einzugeben der zu der Unterschrift gehört.

Man gebe nun "pgp263ii.zip" ein [ man könnte auch direkt

    pgp pgp263ii.asc pgp263ii.zip
eingeben] PGP sollte einem dann sagen:
   BESTÄTIGTE Unterschrift von Stale Schumacher
Ausserdem sagt er dann noch was davon daß er diesem Schlüssel nicht traut ("
WARNUNG: Da dieser öffentliche Schlüssel nicht mit einer vertrauenswürdigen
Unterschrift beglaubigt ist, ist nicht sicher, daß er wirklich zu
"Stale Schumacher " gehört.
"). Das liegt daran, dass PGP nicht wissen kann, daß der Key in KEYS.ASC wirklich zu Herrn Schumacher gehört [Das wird in der Rubrik PGP des öfteren mal gefragt und erklärt].

Man lese deshalb den Abschnitt "How to Protect Public Keys from Tampering" in Band 1 des PGP Handbunch.

Lies die Dokumentation!

Lies die Dokumentation! Zumindest Band I des PGP-Handbuchs ("PGP User's Guide", den es wohl auch auf deutsch gibt).

Signatur Software kann man leicht falsch verwenden/bedienen. Und wenn man sie nicht richtig benutzt, geht viel von der Sicherheit, die sie einem bieten kann, verloren!

Vielfach sind einem auch die Konzepe der asymetrischen Verschlüsselung und Signatur nicht vertraut, das Handbuch erläutert sie. Auch wenn man diese Konzepte schon kennt, ist es wichtig, wie diese Konzepte in PGP verwirklicht wurden.

PGP mag ein unknackbares Schloss sein, aber man muß es richtig an der Tür anbringen, oder es ist nutzlos.

Einen fremden öff.Schlüssel finden

Wo findet man einen fremden Schlüssel?

 Aber: Egal woher der Key dann ist - immer dran denken, daß ein Key ohne richtige Beglaubigung nicht viel wert ist.

Fremde Schlüssel in den eigenen Schlüsselbund aufnehmen

Findet man in der Box neue Schlüssel (meist in der Rubrik PGP, erkennbar am Text: ---BEGIN PUBLIC KEY BLOCK ---), so kann man sie dem eigenen Schlüsselbund hinzufügen, um Texte des Einspielers verifizieren zu können.

Hat man ein PGP-fähiges PR-Programm so geht das hinzufügen vollautomatisch.

Ansonsten schreibt man am besten die ganze Mailbox-Session mit ("SAVE") und ruft amschliessend PGP mit dem Filename auf 

   PGP -ka <filename>
z.B. 
   PGP -ka save0001.txt
Daraufhin untersucht PGP den Text nach neuen Schlüsseln, prüft sie und fügt sie dem Schlüsselbund hinzu.

PGP findet dabei auch mehrere im Text vorkommenden neue Schlüssel.

Man wird während des Vorgangs u.U. gefragt, ob man jemanden vertrauen will bzw. ob man sich sicher ist, ob ein Schlüssel wirklich zu demjenigen gehört, der in der UserID steht. Ist man sich irgendwie unsicher sollte man immer "Nein" bzw. "Ich weiss nicht" wählen.

Den öff.Schlüssel anderer beglaubigen

Ist man sich absolut sicher, daß ein Schlüssel wirklich der behaupteten Benutzerin gehört, und diese bittet einem, ihren Schlüssel zu beglaubigen oder zu unterschreiben (was dasselbe ist), geht man folgendermassen vor.

Man besorgt sich den Schlüssel der Anderen (z.B. aus der Rubrik PGP, er aus einem DirektQSO, von einem Keyserver etc.), überprüft dessen Echtheit der Anderen (NICHT über AFu!, sondern auf einem anderen Weg UND aus erster Hand! - Bester Weg: Auf einem Afu-Treffen o.ä).

Diesen fügt man seinem Schlüsselbund hinzu (s.o.)

Danach gibt man ein: 

      pgp -ks <FremdCall>
Danach fragt PGP normalerweise nochmal nach, ob man wirklich den fremden Schlüssel beglaubigen will. Danach schreibt PGP das Ergebnis dann in die Datei PUBRING.PGP mit hinein.

Nun kann man sich mit 

      PGP -kvv <FremdCall>
ansehen, ob man es richtig gem8 hat.

Nun kann man mit 

      PGP -kxa <FremdCall>
eine versendbare Datei <FremdCall>.ASC erzeugen, die den nunmehr beglaubigten Schlüssel enthält und an <FremdCall> per BBS verschicken.

Man sollte den beglaubigten Schlüssel NICHT in die Rubrik PGP (oder sonstwo öffentlich) einspielen, da für die Verbreitung eines Schlüssels und seiner Unterschriften m.E. nach nur die Eigentümerin verantwortlich ist.

Achtung: Mit so einer Unterschrift BÜRGT man mit seinem guten Ruf für die ECHTHEIT des Schlüssel des anderen, entsprechend vorsichtig sollte man sein!

Aber: Man haftet natürlich nicht für den INHALT von Texten, die jemand mit diesem Key unterschreibt.

Es hat keinen besonders grossen Sinn, wenn man einen anderen Schluessel beglaubigt, aber den eigenen Schlüssel nicht verteilt.

Wo bekomme ich neue Beglaubigungen her?

Am einfachsten von Leuten, die man kennt & regelmässig auch sieht.

Auf Messen und Tagungen etc. Da sollte man sich für vorbereiten:

Wieder zu Hause besorge man sich irgendwie (z.B. aus der Rubrik PGP) den Key der Schlüsselbesitzerin. Den füge man seinem Schlüsselbund hinzu, testet ihn wiederum mit 
    pgp -kvc <IhrCall>
Sind die Zahlen (Anzahl der Bits, Schlüssel-ID und Schlüssel-Fingerabdruck) auf dem Zettel nun gleich denen, die PGP jetzt anzeigt, kann man davon ausgehen, daß dies der echte Schluessel ist. Diesen kann man nun - wenn man möchte - beglaubigen ( PGP -ks <IhrCall> ) und ihm der Schlüsselbesitzerin z.B. per PR schicken.

Den eigenen öffentlichen Schlüssel bekannt machen

Man muß natürlich ein Schlüsselpaar erzeugt haben (s.o.).

Den eigenen Key auch selber unterschreiben (warum steht im PGP - FAQ).
Das geht mit

   pgp -ks <deinCall> -u <deinCall>
also z.B. 
   pgp -ks dg9ep -u dg9ep
Nun muß man jemanden finden, der einem den Public Key beglaubigt - möglichst jemanden der schon "bekannter" ist, oder dessen Schlüssel von einem "Bekannteren" unterzeichnet wurde.

Wie das geht, ist unter Den öff.Schlüssel anderer beglaubigen aus der Sicht des bekannteren beschrieben.

Einen nicht unterzeichneten Schlüssel ins Netz zu spielen macht nicht allzuviel Sinn...

Den eigenen nunmehr beglaubigten *K*ey aus dem Schluesslbund e*X*trahieren und in eine *A*scii-Datei schreiben. Das geht mit:

  PGP -kxa
Dann wird im Dialog (oder auf modischdeutsch:"interaktiv") nach der BenutzerID gefragt. Normalerweise reicht es dann das eigene Rufzeichen einzugeben.

Dann wird nach dem Dateiname gefragt, wo der Schlüssel rein soll. Da kann man was beliebiges eintragen - man sollte sich nur daran erinnern, denn dieser File wird nachher zur Box hochgeladen.

Man kann auch:

   pgp -kxa  <DeinCall>  <Ausgabedateiname>
machen, also z.B. 
   pgp -kxa   dg9ep     c:\tmp\dg9ep.txt
So, nun ab in die Box damit. Ein 
   S PGP @ DL Public Key  <DeinCall>
abgeschickt, und die gerade erzeugte Datei als TEXT abschicken (Aber vorher die Umlautwandlung des Terminalprogramms abschalten, falls dies nicht automatisch passiert).

Dieser Text braucht - und sollte - nicht signiert werden. Dies macht an dieser Stelle keinen Sinn und macht beim Empfänger u.U. einige zusätzliche Handgriffe nötig.

Einen anderen Verteiler als DL ist zur Zeit nicht nötig.

Fertig.

Übrigens: Nie den PUBRING.PGP selber versenden (warum steht im Handbuch), und niemals, niemals, niemals SECRING.PGP per Remote zugreifbar machen oder gar versenden!

Wie man einen Text unterschreibt

Hat man eine PGP-fähiges PR-Programm ist es sehr einfach. Bei GP/2 ruft man den Maileditor auf, schreibt seinen Text, und kreuzt vor dem Senden das entsprechende Feld ("Signatur") und gibt im Feld daneben das Passwort an. Fertig.

Ansonsten:
Mit einem Texteditor (EDIT, NotePad oder dem Editor von GP-DOS...) den Text schreiben und abspeichern.
Verwendet man ein Textverarbeitung, so muß man es als "MSDOS-Text" abspeichern.

Den Text signieren: 

    PGP -sat <textdateiname>
anschliessend wird nach dem Passwort gefragt. Danach rödelt der Rechner ein bischen und erzeugt eine Datei mit der Endung .ASC. Diese versendet man dann mit Texttransfer o.ä in die BBS. ACHTUNG: Beim Senden darf keine Umlautwandlung oder ähnliches eingeschaltet sein (z.B. in GP/DOS nimmt der Texteditor Wandlungen vor).

Kleiner Exkurs: Nachrichten im Klartext

Bei der üblichen, nicht AFu-mässigen Anwendung von PGP liegen mit PGP unterschriebene Nachrichten komprimiert in einem Binärform vor. Auch die Unterschrift wird in Binärform an die unterschriebenen Daten angehängt.
Um eine solche unterschriebene Nachricht z.B: über eine AFu-BBS zu verschicken muß man sie umwandeln. Dazu verwendet PGP die ASCII-Darstellung im Radix-64-Format (ähnlich dem 7Plus-Format, nur ohne Fehlerkorrektur). Dies erreicht man mit der Kommandozeilenoption -a .

Die Daten bestehen dann zwar aus druckbaren ASCII-Zeichen, der originale Text ist aber mit bloßem Auge trotzdem nicht mehr zu erkennen, obwohl die Nachricht nicht verschlüsselt ist. Die Empfängerin einer solchen Nachricht muß die "ASCII-Transportverpackung" mit Hilfe von PGP wieder "entfernen", bevor sie die Nachricht lesen kann.

Das ist im Amateurfunk nun nicht unbedingt so gewollt.

Da die originale Nachricht in AFu-BBS immer ein ASCII-Text ist (zu Binärdaten siehe unten), besteht die Möglichkeit, eine Unterschrift so an den Text anzufügen, daß er nicht in seiner Darstellung geändert wird. Dies passiert durch die Option +clearsig . Diese Option ist bei PGP aber die Voreinstellung, so daß sie nicht angegeben werden braucht.

In diesem Fall wird nur die Unterschrift im Radix-64-Format dargestellt. Der Text bleibt also auch ohne Hilfe von PGP für die Empfängerin lesbar. Für die Prüfung der Unterschrift ist PGP natürlich trotzdem erforderlich.

Wichtiger Hinweis: Eine solche Nachricht wird als Textnachricht versandt und unterliegt dadurch möglichen Änderungen auf dem Versandweg. So nehmen PR-Terminalprogramme bei Sendung und Empfang unter Umständen Zeichensatzkonvertierungen vor; verschiedene Betriebssystem verwenden unterschiedliche Zeilenendezeichen (Mac und PR: CR, Unix: LF, DOS und Windows: CR+LF); es können Leerzeichen oder Tabulatoren eingefügt oder gelöscht werden.
Durch die Option -t wird zwar ein Mechanismus in Gang gesetzt, der hilft einige dieser Fehler zu vermeiden, aber er ist nicht ganz perfekt.

Wenn auf dem Transportweg (Terminalprogramm, BBS, S&F) eine solche ungewollte Änderung passiert, wird PGP die Nachricht als verändert erkennen, was zu einem in diesem Fall unberechtigten Verdacht einer echten, inhaltlichen Fälschung führt.

Wie überprüft man die Unterschrift unter fremden Texten?

Hat man ein PGP-fähiges PR-Programm so geht dies vollautomatisch.

Ansonsten schreibt man am besten die ganze Mailbox-Session mit ("SAVE") und ruft amschliessend PGP mit dem Filename auf 

   PGP <filename>
z.B. 
   PGP save0001.txt
Daraufhin untersucht PGP den Text nach unterschriebenen Texten, prüft sie und gibt seinen Kommentar dazu aus (PGP findet bei einem Aufruf lediglich mit einem Filenamen als Argument alle in dieser Datei vorkommenden Unterschriften und erkennt auch neue PublicKeys und neue Unterschriften unter bereits vorhandenen Schlüsseln, die er nach Nachfrage auch automatisch in den Schlüsselbund aufnimmt. Man braucht also - ausser beim Unterschreiben selber - fast nie irgendwelche Optionen anzugeben).

Die möglichen Antworten von PGP:

BESTÄTIGTE Unterschrift von "Ulf Saran, DH1DAE",
Unterschrift erzeugt am 1996/11/25 15:48 GMT mit 768-Bit-Schlüssel 0xB496469D.
Text & Unterschrift stimmt, und stammt von DH1DAE. Alles in Ordnung. Prima. Problemlos. Hurra. 
WARNUNG: Die Unterschrift stimmt nicht mit dem Datei-Inhalt überein!
FEHLERHAFTE Unterschrift von "Ulf Saran, DH1DAE",
Unterschrift erzeugt am 1996/11/25 15:48 GMT mit 768-Bit-Schlüssel 0xB496469D.
Ups. Das ist eindeutig. Im AFu Bereich passiert sowas aber nicht nur durch einen bewussten Fälschungs-Versuch, sondern auch durch Übertragungsfehler oder vorhanden Umlautkonvertierungen der PR-Terminalprogramms [ich habe diese Meldung erzeugt, indem ich den signierten Text änderte - also einen Fälschungsversuch vornahm...].

Also ganz schnell die Einspielbox (erkennbar im Kopf der Nachricht) connecten und nochmals den Text auslesen. Ist dieser auch falsch, dann sofort Sysops und den Rufzeicheninhaber verständigen (möglichst nicht per PR...). Und eine kleine Mail in die gleiche Rubrik setzen.

Und - natürlich - bis zur Klärung des Sachverhalts den Inhalt der Mail ignorieren.

BESTÄTIGTE Unterschrift von "G.Marconi ",
Unterschrift erzeugt am 1999/07/22 19:01 GMT mit 1024-Bit-Schlüssel 0xDB78CB51.

Schlüssel für Benutzer-ID "G.Marconi ",
1024-Bit-Schlüssel, Schlüssel-ID: DB78CB51, erzeugt am: 1999/07/22.
Der Schlüssel wurde zurückgezogen.

WARNUNG: Dieser Schlüssel wurde von seinem Besitzer zurückgezogen,
möglicherweise, weil sein privater Schlüssel nicht mehr sicher ist.
Dies könnte bedeuten, daß diese Unterschrift eine Fälschung ist.
Der Schlüssel, mit dem die Mail unterschrieben war, wurde von dem Besitzer zurückgezogen (widerrufen) oder er ist zwischenzeitlich verfallen (seit PGP 5 kann man für Schlüssel Verfallsdaten angeben). Das heißt der Besitzer hatte öffentlich erklärt, daß der Schlüssel ungültig ist - z.B. weil jemand anderes Zugang zu dem geheimen Teil des Schlüssels erhalten hatte.

Wenn eine Mail trotzdem mit einem ungültigen Schlüssel unterschrieben ist, so spricht viel für eine gefälschte Mail - auch wenn die Unterschrift "bestätigt" ist. Denn warum sollte der richtige Besitzer des ungültigen Schlüssels seine Mail mit dem ungültigen Schlüssel signieren?

Also so verfahren wie bei einer gefälschten Mail (s.o.)

Der zur erwarteten Schlüssel-ID F5780045 passende Schlüssel
ist nicht in der Datei 'pubring.pgp' enthalten.
Dateiname des öffentlichen Schlüssels: 
WARNUNG: Ich kann den passenden öffentlichen Schlüssel nicht finden.
Eine Überprüfung der Unterschrift ist nicht möglich.
Spricht (hoffentlich) für sich selber. S.a. Einen fremden öff.Schlüssel finden"

FEHLER: Falsche Prüfsumme der Versandhülle
FEHLER beim Entfernen der Versandhülle von Datei 'xyz'.
Da ist was fürchterlich schief gegangen. Offenbar ist die Signatur (das ist dieses Buchstaben und Zahlengewirr unter dem Text: 
 -----BEGIN PGP SIGNATURE----
 Version: 2.6.3i
 Charset: noconv

 iQB1AwUBMpm/wQ3Vofu0lkadAQG9wgL9FAYbQVf+II3ByfpD6k6+c5LSypas0On2
 t2kLkzNoa9ho6Xjk0d4xA3TJnlWXfHn5seFAcspmrPaDGdilSWp+Hzh8zUv+hsZ/
 4cXoIo4JOkxnLP13djRE547UhJGRv8Ff
 =Yjpr
 -----END PGP SIGNATURE----
) formal nicht korrekt. Ursache wie oben, oder mal wieder ein plumper Versuch PGP zu veralbern (durch nachgeäffte Buchstaben und Zahlenkombinationen). 
FEHLER: Die Datei 'xyz' ist nicht verschlüsselt
und enthält weder eine Unterschrift noch einen oder mehrere Schlüssel.
Da wurde wohl versucht eine Datei zu überprüfen, in der nix von PGP bearbeitbares drin ist.

Und dann gibt es noch die Variante: 
BESTÄTIGTE Unterschrift von "Stale Schumacher ",
Unterschrift erzeugt am 1996/01/18 13:56 GMT mit 1024-Bit-Schlüssel 0xCCEF447D.

WARNUNG: Da dieser öffentliche Schlüssel nicht mit einer vertrauenswürdigen
Unterschrift beglaubigt ist, ist nicht sicher, daß er wirklich zu
"Stale Schumacher " gehört.
D.h. daß die in der Datei vorhandene Unterschrift zu dem Text passt, und daß der Schlüssel mit dem diese Unterschrift erzeugt wurde, wirklich die ID 0xCCEF447D hat. Aber es ist eben nicht sicher, daß dieser Schlüssel wirklich von Herrn Schumacher eingespielt und benutzt wurde. Denn niemand (oder niemand, den wir vertrauenswürdig finden) hat diese Tatsache beglaubigt.

Das ist übrigens eins der beiden zentralen Verständnissschwierigkeiten gewesen, als PGP sich im AFu breitmachte (das andere war die Sache mit der offenen Sprache).

Den eigenen Schlüssel widerrufen

Es kann vorkommen, daß man den eigenen Schlüssel nicht mehr verwenden will. Vielleicht ist einem die Schlüssellänge nicht mehr ausreichend, das eigene Rufzeichen hat sich geändert oder es ist gar ein Fremder in den Besitz das Mantra dieses Schlüssels gekommen.

Man könnte nun einfach den Schlüssel aus dem eigenen Schlüsselbund löschen (pgp -kr). Doch dies reicht nicht. Denn der öffentliche Teil des Schlüssel ist ja verbreitet worden, und ruht nun auch in den Schlüsselbunden vieler anderer PGP-Verwender. Und die ahnen ja nicht mal, daß dieser Schlüssel nicht mehr benutzt werden soll und damit unterschriebene Dokumente nicht mehr als korrekt anerkannt werden sollen.

Auch hier hat PGP wieder ein Lösungsmöglichkeit anzubieten. Mit dem Befehl 

  pgp -kd
kann man ein sog. "Widerrufszertifikat" erzeugen. Damit ist der Schlüssel als ungültig erklärt. Man sollte nun ganz normal mit
  pgp -kxa
eine per PR versandfähige Datei mit diesem Widerrufszertifikat erzeugen und auf dem gleichen Weg verteilen, wie man öffentliche Schüssel verteilt. Geschickterweise erzeugt man direkt auch einen neuen PGP-Schüssel und verteilt ihn gleich mit.

Unter www.iks-jena.de/mitarb/lutz/security/pgpfaq.html ist beschrieben, wie man gleichzeitig mit der Erzeugung eines Schüssel, direkt ein Widerrufszertifikat erzeugt. Dies speichert man für den Fall, daß das Mantra vergessen worden ist (der Autor spricht hier aus eigener Erfahrung) auf einer Diskette. Denn ohne das Mantra für den Schüssel kann man auch kein Widerrufszertifikat erzeugen...

Was man beim Umgang mit PGP unbedingt beachten muß

Ich habe zwar gesagt, ich will auf Sicherheitsaspekte nicht eingehen, aber trotzdem: 
 1) Gib niemals Deinen privaten Schluessel in fremde Hände!
 2) Schuetze Deinen privaten Schluessel immer mit einem nicht trivialen Passwort!
 3) Fertige eine Sicherheitskopie Deines privaten Schluessels an und
    verwahre Sie an einem sicheren Ort. Wenn Du den Schluessel verlierst
    und einen neuen anfertigen mußt, ist Dein frueherer oeffentlicher
    Schluessel nicht mehr gueltig und muß gegen den neuen ausgetauscht
    werden!
 4) Akzeptiere niemals blind einen oeffentlichen Schluessel, dessen
    Herkunft Du nicht kennst und von keiner Person unterschrieben ist, der
    Du uneingeschraenkt vertrauen kannst!
 5) Beglaubige niemals einen fremden Schluessel, ohne Dich vorher selbst
    ueber dessen Authentizitaet ueberzeugt zu haben (z.B. durch Erfragen
    des Fingerabdrucks beim Besitzer des Schluessels). Mit Deiner
    Unterschrift verbuergst Du Dich für die Echtheit des Schluessels!
    Selbst, wenn der Schluessel bereits von einer anderen Person signiert
    ist, vertraue in diesem Fall der Signatur nicht blind! Sei besonders
    vorsichtig, wenn Du um die Beglaubigung eines Schluessels gebeten
    wirst. Stellt sich ein von Dir beglaubigter Schluessel spaeter als
    gefaelscht heraus, hat dies negative Auswirkungen auf Deine
    Glaubwuerdigkeit!
(Hemmungslos kopiert bei DH1DAE)

PGP Versionen 5.x

Seit Mitte 1997 gibt es für Unix, Windows 95 und Macintosh neue Versionen PGP 5.x. Dies umfasst die Versionen PGP 5.0, PGP5.0i, PGP5.5x und weitere.

Es ist inzwischen einigermassen verwirrend, was es da alles gibt. Für aktuelle Informationen verweise ich auf die Internetseiten des Heise-Verlags.

Die Version 5.0 verwenden neue Verfahren für die Schluessel- und Hasherzeugung. Ausserdem werden getrennte Schluessel fuer Unterschreiben und Verschluesseln unterstuetzt. Diese Aenderungen haben zwar gute Gruende, aber sie ist damit nur noch teilkompatibel mit der Version 2.6.x, die zur Zeit wohl noch am haeufigsten eingesetzt wird. Unterschriebene Mails, deren Schluessel mit PGP 5.0 erzeugte wurde lassen sich mit PGP 2.6.x NICHT verifizieren. Der umgekehrte Weg funktioniert allerdings.

Erst diee Version 5.5.3i ("PGP for Personal Privacy, Version 5.5.3i") ist kompatibel zu den PGP 2.6. Versionen.

Bestehende (Versionen 2.6.x) Schluesselbunde koennen importiert werden, so dass sich wenn man PGP 5 benutzen möchte z.Zt. folgendes Vorgehen empfielt:

  1. Neuen eigenen Schluessel mittels Version 2.6.3i erzeugen.
  2. Danach - wenn man möchte - PGP 5.0 installieren. Dabei wird nach existierenden Schluesselbunden (keyrings) gefragt. Dabei gibt man die unter 1. erzeugten an.
Die 5er Version (ich habe nur die 5.0 fü Win95 Version ausprobiert) ist komplett fensterorientiert und enthält eine übersichtliche Möglichkeit der Schluesselverwaltung. Ausserdem hängt es sich in das Clipboard und bekanntere E-Mailprogramme ein, und ist deswegen recht bequem zu bedienen.
Batchfaehige Versionen und solche für andere Betriebssysteme sind ebenfalls verfügbar.

Die PGP Version 5.0i ist mit zusätzlichen rechtlichen Einschränkungen versehen ("...permission to allow you or others to reproduce and distribute any such Derivative Works or any compiled version of the source code of this Source Code Package (i.e., anything except the unmodified version of the Source Code Package), will generally NOT be given.").
Dies hat zwar zum Teil verständliche Gründe ("Most important, PGP expressly forbids the creation of any Derivative Works that may compromise the privacy or security of the users of the Software Product or the Source Code Package"), hat aber eben auch den Nachteil, effektiv keine Änderungen mehr vornehmen zu können.

Deswegen hat sich - in bester GNU - Tradition bereits eine Initiative gebildet, die eine wirklich freie Software erstellt, die den vollen PGP-Funktionsumfang enthält und gleichzeitig auch weitere, sichere Verfahren implementiert hat: GNUPG - The GNU Privacy Guard (GPG). Das Ganze ist allerdings noch nicht im beta-fähigen Zustand. Der Hauptautor dieses Programms ist übrigens ein Funkamateur aus DL :-) .

Näheres zu PGP 5.x in einem c't Artikel, auf den Seiten des Herstellers und auf der internationalen PGP-Homepage

Inzwischen gibt es weitere Versionen PGP 6.0 und PGP 6.5. Ich habe keine konkreten Erfahrungen hiermit, aber im Grunde dürfte hier das gleiche gelten wie für die 5er Versionen.

Soll man PGP 5/6 verwenden?

Hier hat sich meine Meinung inzwischen gewandelt:
Meines Erachtens gibt es nur noch einen Grund die 5er und 6er Versionen von PGP nicht zu verwenden: Allerdings sind die in PGP 5.x verwendeten Verfahren die bessere Lösung, da sie mehr Sicherheit bieten und die rechtliche Patentsituation eindeutiger ist.

Für Windows-Benutzer sind die PGP 5-Versionen sicherlich benutzerfreundlicher. Denn selbst wenn PGP-fähige Programme verwendet werden, so ist die Keyverwaltung auf Kommandozeile nicht jedermanns Sache.

Desweiteren gibt es mit GNUPG ("Gnu Privacy Guard") eine freie (GPL) Alternative, die sich wie einst PGP 2.x auf vielen Systemen übersetzen lässt. Darüberhinaus enthält sie viele Hash- und Chiffrierverfahren, wird aktuell weiterentwickelt - und zwar komplett in Europa, was bei den restriktiven US-Gesetzen ein großer Vorteil ist -, die Quelltexte sind verfügbar und nicht zuletzt ist der Hauptautor auch noch Funkamateur (DD9JN) :-)

Einer Verwendung von "PGP 5"-Schlüsseln (D/H und DSS, die eigentlich ElGamal und DSA heissen) steht also eigentlich nichts mehr entgegen.

Wer "alte PGP 2"-Schlüssel noch hat, sollte diese aber weiterbenutzen.

PGP-fähige PR-Programme

GP85 für Windows 9x von DH1DAE.
Wenn ich mich recht erinnere (hab kein Windows greifbar) unterstützt dieses Programm PGP, sofern PGP installiert ist.

GP/2 für OS/2 von DH1DAE.
Dieses kann automatisch alle für AFu relevante PGP-Funktionen ausführen (ueberpruefen, signieren, Keys hinzufuegen) wenn eine funktionsfähige PGP Installation vorhanden ist.

MCuT (DOS und Linux) von DG4IAD enthaelt PGP-Unterstuetzung. Signaturen werden automatisch ueberprueft und Nachrichten, die im internen Editor geschrieben wurden, können signiert werden. MCuT ist schon mehrmals in die Rubriken SOFTWARE und MCUT eingespielt worden.

Seit der Version 1.4 hat TNT (Unix/Linux) PGP-Unterstuetzung. Signaturen werden automatisch überprueft und Keyblocks automatisch dem Schlüsselbund hinzugefuegt. Dabei kann beliebig zwischen PGP und GnuPG gewählt werden.

In dem Win32 Program Paxon (www.paxon.de) ist PGP-Unterstützung ebenfalls eingebaut. Paxon erlaubt es, wie die meisten anderen hier erwähnten Programme, signierte Texte zu versenden, überprüft automatisch empfangene Mails und fügt empfangene öffentliche Schlüssel automatisch zum Schlüsselbund hinzu.

Gerd-Michael, DL5FBD@DB0GV hat ein Programm BOXPGP geschrieben, was in Mailboxen (z.B. DB0GV) läuft. Es ueberprueft die PGP-Signatur von Mails in PR-Mailboxen.
Diese Sache ist eigentlich nicht sinnvoll. Denn man muss die Vertrauenseinstellungen des jeweiligen Sysops akzeptieren, die man aber gar nicht abfragen kann. Ausserdem schreibt der Autor, dass man die Warnung, dass keine vertrauenswuerdige Zertifizierung vorhanden ist ignorieren kann!
Aber für C64 Besitzer ist es wohl die einzige Möglichkeit, eine Unterschrift zu begucken...

Von Andreas (DG1KFA @ DK0MWX.#NRW.DEU.EU) gibt es ein Program namens PGPSERV. Auszug aus der Ankündigung:

PGPSERV ist ein in (soweit getestet) jeder PR-Software einsetzbares Remote-Programm, um einen fernsteuerbaren PGP-Keyserver aufzubauen. Es eignet sich sowohl für den Einsatz im Mailboxen (getestet nur mit BayBox) als auch in herkömmlichen Terminal-Programmen wie GP, SP, BayCom, Air-TE und wahrscheinlich auch den meisten anderen (nicht getestet).

Am 13.08.98 schrieb DC2SF:

Es gibt bei DB0ULM und DB0ZWI einen sogenannten "PUBLIC KEYSERVER".
Man kann damit per Mail einen Schluessel vom Server zugesandt bekommen oder den eigenen (mit neuer/zusaetzlicher Signatur) per Mail dort ablegen. Das ganze ist auf jedem Linux-System mit POP3/SMTP-Server lauffaehig (Sysops die Interesse haben koennen die Soft dazu jederzeit bekommen). Die Server tauschen ihre Keys untereinander auch aus. Es reicht also,wenn man diesen bei einem ablegt.

Es gibt diverse Oberflächen ("Shells") für PGP, die einen menügesteurten Zugriff auf alle PGP-Funktionen erlauben. Welche Programme es alles gibt weiss ich nicht, aber eine Suche in den diversen Suchmaschinen mit den Schlagworten 

    PGP Shell Menu
sollte zu einem ausreichenden Ergebniss führen.

Seltsames und Kurioses beim Amateurfunk - PGP

In einigen Laendern ist der Einsatz von PGP im Amateurfunk komplett verboten - also auch die Signierfunktion.

Deutschland gehört nicht dazu. Zwar gibt es nirgendwo eine eindeutige Aussage der Behörden dazu, aber ein klartextsignierte Mail ist sicherlich offene Sprache. Der Block am Ende solcher Mails ist auch keine Verschlüsselung, sondern eine Kodierung - genau wie die Prüfsumme am Beginn einer #Autobin -Übertragung, am Ende einer jeden 7Plus-Zeile oder die in jedem AX.25 / HDLC - Paket.

Und zumindestens die BAPT-Aussenstelle Krefeld scheint PGP-signierte AFu-BBS-Mail zu versenden. Allerdings habe zumindestens ich noch keine für mich vertrauenswürdige Beglaubigung dieses Schlüssels (Key-ID EC906B51 vom 21.4.1999) gefunden.

Eines der Länder mit Verbot ist Grossbritanien.
John, GW6ZUS schreibt:

"Egal ob wir es hier im Vereinigten Königreich (UK/GBR) mögen oder nicht, die UK-Lizenz-Behörde "The Radiocommunications Agency" (RA), die ein ausführendes Organ des "Department of Trade and Industry" (Industrie- und Handlesministerium [? A.d.Ü.]) ist, hat bestimmt, dass PGP (Pretty Good Privacy) eine Geheimschrift (cipher) ist.

Die RA hat die UK-Funkamateur-Gemeinde desweiteren daran erinnert, dass Geheimschriften bei der Übertragung über das UK-Funkamateur-Netz nicht hinnehmbar (not acceptable) sind.

Deswegen hat JEDE Mailbox in UK Filter aktiviert, um öffentliche Builletins und privaten Verkehr, die Hinweise auf die Verwendung von PGP oder eine blosse Erwähnung von PGP enthält (which include such script or 'three letter' abbreviated references) entweder zur Kontrolle zurückzuhalten oder ganz zu verwerfen.

[..]

Wenn Mail in UK verbreitet werden soll ..DARF SIE KEINE.. solchen Hinweise oder Erwähnungen enthalten.

Wir machen diese Regel nicht, aber wir haben uns daran zu halten."

[...]

"Richtig! Die "drei-Buchstaben-Abk." sind genau das, was du denkst was sie sind. Diese drei Buchstaben sind (oder sollten) in der Filter-Datei jeder britischen (UK) Mailbox enthalten sein. Je nachdem wie raffiniert die Filter/Suchprogramme der Boxen sind, werden auch verschiedene andere Formate entdeckt, wie z.B. ### und # # # und #*#*# [also PGP und P G P und P*G*P].

Dadurch kann 1) der Sysop diese Mail kontrolieren und sie weiterleiten (oder auch löschen) oder 2) ohne Kontrolle durch den Sysop die Mail zurückgewiesen werden - je nachdem wie der jeweilige Sysop es möchte.

"Script" ist dieser eindeutige Block von Tastendrücken, Buchstaben, Symbolen, oder wie immer man es auch nennen möchte, der das Markenzeichen eines ### - Signatur-Blockes ist.

Soweit ich weiss, löschen VIELE britische (UK) - Sysops solche Mails ohne sie vorher anzuschauen! Das wird glaube ich deshalb so gemacht, weil die meisten Sysops von BBS mit viel externen Verkehr [import/ export BBS Sysops] schon so viel damit zu tun haben, andere Mails mit verbotenen Inhalten (von solchen Verboten haben wir einige!) zu finden, dass sie gerade solche, leicht zu erkennende ..... "PLONK" und ab damit in das grosse Byte-Endlager."

Absolut erstaunlich: Man darf PGP nicht mal erwähnen...

In Frankreich, im Iran, in Rußland, der Ukraine und im Irak ist m.W. Krypotgraphie und damit PGP auch im "normalen" Leben verboten.
Unter http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm gibtes auf Englisch aktuelle Aussagen zur Politik vieler Länder.

Auch in Deutschland gibt es derartige Bestrebungen! Offenbar soll von der DDR mehr als nur der grüne Pfeil übernommen werden...

Allerdings darf man es z.B. in Frankreich innerhalb von Firmen und Vereinen verwenden [Wobst]. Nun dürften aber die meisten Funkamateure dort in einem gemeinsamen Verein sein, also wäre das - in Frankreich - nicht das Hindernis.

Aber wir sollten wir es den OMs dort nicht zu schwer machen, und Mails (auch private) in diese Laender (oder die durch diese Lander geforwardet werden) nicht signieren. Man kann aber eine signierte Version in seiner eigenen Box hinterlegen, und in der Mail darauf hinweisen.

Hee! Das ist doch nur *Amateur*funk - das ist ja alles übertrieben!

Oder wie z.B. DL7QG formulierte:
WER? hat WARUM? ein so vehementes Interesse an der Durchsetzung von PGP im Hobby "Amateurfunk"?

Worauf DH1DAE u.anderem antwortete:
WER? hat WARUM? ein so vehements Interesse GEGEN die Anwendung von PGP im Hobby "Amateurfunk"?

Amateurfunkinhalte sind per Definition unwichtig. Also weshalb stört PGP dann? Es ist halt so, dass im AFu manchmal Sachen gemacht werden, die unnötigt erscheinen. Aber das ist doch in Ordnung... Ansonsten könnte man auch sagen: Wozu funken? Ruf doch einfach mit Telefon an.

Installation auf einem Amiga

(A500+, 2MB RAM, keine HD)
von Rainer, dc8yh @ db0ea

Auch PGP für den Amiga wird als Archiv verteilt. Man kann es sich als Funkamateur entweder vom EL-Fileserver DB0NOS-8, Verzeichnis C:\EL\AMIGA\UTILS, von der CD 2/95 der Zeitschrift AMIGA plus oder vom einem FTP-Server des AMINET bzw. einer entsprechenden AMINET-CD, Pfad util/crypt, herunterladen.

Ich habe die Version 2.6.3i von DB0NOS. Nach dem Extrahieren und Dekodieren mit 7Plus erhaelt man das Archiv PGPAmiga-2.6.3is.lha .

Zum Auspacken benötigt man LhA, ich benutze die Version 1.38 . Das Archiv ist nach dem Auspacken 955164 Byte gross und passt somit nicht mehr auf eine DD-Diskette. Besitzer eines Amigas ohne Festplatte sollten aber dennoch weiterlesen.

Zuerst werden in der Shell die Befehle copy, delete, list und rename mit 

    resident c:....
speicherresident gemacht.

Dann habe ich LhA auf die RAM-Disk (2MB) kopiert und das PGP-Archiv mit 

    lha x DF0:PGPAmiga-2.6.3is.lha RAM:
in das RAM ausgepackt. Man erhaelt im Verzeichnis RAM:PGPAmiga- 2.6.3i die Dateien PGPAmiga-263i.asc und PGPAmiga-263i.lzh sowie den File ReadMe.1st.

Als Nächstes legt man eine vorformatierte und PGP genannte Dis- kette in das Laufwerk ein und wechselt das aktuelle Verzeichnis: 

    cd RAM:PGPAmiga-2.6.3i
Danach: 
    copy ReadMe.1st PGP:ReadMe_by_Peter_Simons clone
Aus Platzgruenden werden nur die benötigten Files aus dem Archiv ausgepackt und auf die Diskette geschrieben: 
    lha x PGPAmiga-263i.lzh bin/#? RAM:
Das Verzeichnis RAM:bin enthaelt nun zwei PGP-Versionen, die für die beiden Motorola CPUs 68000 und 68020 uebersetzt wurden. Eine Version - bei mir ist es die für die CPU 68020 - kann gelöscht werden, die andere wird umbenannt: 
    delete RAM:bin/PGP263i-020
    rename RAM:bin/PGP263i-000 RAM:bin/PGP
Dann wird das komplette Verzeichnis auf die Diskette kopiert: 
    copy RAM:bin/#? PGP: clone
Und weiter: 
    lha x PGPAmiga-263i.lzh doc/#? PGP:
    lha x PGPAmiga-263i.lzh src/#? PGP:
    lha x PGPAmiga-263i.lzh keys.asc PGP:
    lha x PGPAmiga-263i.lzh readme.#? PGP:
    lha x PGPAmiga-263i.lzh setup.doc PGP:
Nach dem Sichern der Originalversion der Konfiguration ist diese mit dem betriebssystemeigenen Editor anzupassen: 
    cd PGP:
    copy config.txt config.bak clone
    ed config.txt
Im Wesentlichen gilt die Beschreibung für den PC von Walter, DG9EP. Amiga-spezifisch sind jedoch die Eintraege: 
    CharSet = noconv
    TMP = "RAM:T"
    TZFix = -7
Mit TZFix = -7 zeigt mein Amiga die systeminterne Uhrzeit in GMT an.

Bei der Benutzung von PGP sollte man mit 

    cd PGP:
in das Verzeichnis der Diskette PGP: wechseln. Files, die man unterschreiben will oder deren Unterschrift ueberprueft werden soll, werden entweder vorher in die RAM-Disk kopiert (verhindert haeufigen Diskettenwechsel) oder mit vollem Pfadnamen eingegeben.

Die Amiga-Version der PGP-Auslieferung traegt uebrigens die Unterschrift von Peter Simons <simons@peti.rhein.de>.

Besitzer eines Amiga mit Festplatte haben es bei der Installation und Benutzung von PGP etwas leichter und können meine Anleitung sicher entsprechend anpassen.

Wo kriegt man die neueste Version dieses Textes her?

Die aktuellste Version ist immer per PR in DB0IZ (und in anderen Mailboxen) in der Rubrik PGP zu finden.

Im WWW ist es im Zuammenhang mit meiner kleinen PGP/GPG-Seite zu finden

Dieser Text ist sowohl in HTML als auch in "normalen ASCII" erhältlich.

Es gibt auch ein deutsches Handbuch von PGP. Es wurde auch von DG1DAC im Juni 96 ins BBS System eingespielt (Rubrik PGP, BID: 216608DB0ERF, Title: "Alles ueber PGP")

Dank für die Hilfe bei der Erstellung an alle Diskussionsteilnehmer in der BBS-Rubrik PGP, insbesondere an DH1DAE, der ausserdem durch seinen PGP-Vortrag auf der 12. Internationalen PR-Tagung in Darmstadt den PGP - Stein im AFu mit ins Rollen brachte, und Dank an alle Lieferanten von Textbeiträgen (wiederum DH1DAE sowie DC8YH) und Korrekturen (besonders an Julian, DL6OCK).

Literatur

[Wobst] Wobst, Reinhard: Abenteuer Kryptologie; Bonn; Addison-Wesley-Longman, 1997

[ctpgp50] c't Magazin für Computertechnik; Ausgabe 8/97 S.58

Handbook of applied cryptographic

Bruce Sneider, Applied cryptographic

Ich bitte um Resonanz (Tippfehler, fachliche, strukturelle und stilistische Fehler oder Ergänzungen, offene Fragen etc.) per E-Mail an dg9ep@db0iz oder an dg9ep@1409.org
Alle Angaben ohne Gewähr.
Verbreitung des Textes nur im Sinne der ALAS.