Next: 3. Windowsversionen Up: 2. KommandozeilenversionenPGP 2.6.x, 5.x, GnuPG Previous: LEGAL_KLUDGE - (nicht) von 2.3a lesbare Dateien erzeugen

Unterkapitel

15. Spezielle Befehle

Dieser Teil des Handbuchs beinhaltet spezielle Themen, die nicht im ersten Teil "Grundlagen" enthalten sind. Das Lesen dieses Teils ohne Kenntnis des vorangegangenen ist nicht sehr sinnvoll. Andererseits ist die Kenntnis dieses Teils für die Benutzung von PGP nicht unbedingt erforderlich.

1. Auswahl eines Schlüssels über seine Schlüssel-ID

Bei allen Kommandos, die die Angabe einer Benutzer-ID oder eines Teils derselben erfordern, kann statt dessen auch die hexadezimale Schlüssel-ID benutzt werden. Für PGP muß vor der Schlüssel-ID ein 0x geschrieben werden. Beispiel:
$\begin{command}2.6.x: pgp -kv 0x67F7 \end{command}$
listet alle Schlüssel auf, in denen 67F7 ein Teil der Schlüssel-ID ist.

GnuPG und PGP 5.0 erwarten die gesamte kurze ID, die gesamte lange ID oder den gesamten Fingerabdruck des Schlüssels. Beginnt der Parameter mit einem Buchstaben, muß eine 0 vorangestellt werden, PGP 5.0 erwartet auf jeden Fall ein 0x:
$\begin{command}gpg: gpg -kv 0621CC013 gpg: gpg -e datei \ : -r 8AFAB30A453B6BFD6DDAC3DA2F654DBE32106275 5.0: pgpk -l 0xD0938CF5 \end{command}$

Diese Option ist vor allem dann praktisch, wenn es von einer Person zwei verschiedene Schlüssel mit ein und derselben Benutzer-ID gibt. In diesem Fall läßt sich mit Hilfe der Schlüssel-ID einer der beiden Schlüssel eindeutig auswählen. Die Auswahl eines Schlüssels über seinen Fingerprint ist wohl ausschließlich für den automatisierten Ablauf interessant.

2. Trennung der Unterschrift von der Nachricht

Normalerweise wird eine Unterschrift in derselben Datei gespeichert wie der Text, der unterschrieben wird. Dadurch ist die Prüfung einer Unterschrift in den meistens Fällen einfach und bequem möglich. Unter bestimmten Umständen ist es aber sinnvoll, die Unterschrift in einer eigenen Datei, unabhängig von der Textdatei, zu speichern. Hierzu dient die Option -b zusammen mit der Option -s.

Beispiel:
$\begin{command}2.6.x: pgp -sb brief.txt 5.0: pgps -b brief.txt gpg: gpg -sb brief.txt gpg: gpg -b brief.txt gpg: gpg --detach-sign brief.txt \end{command}$

Hier wird eine Datei brief.sig bzw. brief.txt.sig erzeugt, die nur die Unterschrift enthält. Der Inhalt der Datei brief.txt wird nicht in brief.sig gespeichert (und kann aus dieser Datei auch nicht berechnet werden). Wenn die Unterschrift in einer eigenen Datei (brief.sig in obigem Beispiel) erzeugt wurde, müssen beide Dateien (im Beispiel brief.sig und brief.txt) an die Empfängerin geschickt werden. Sie benötigt beide Dateien, um die Echtheit der Unterschrift zu prüfen. Wenn sie die Datei mit der Unterschrift durch PGP bearbeiten läßt, stellt das Programm fest, daß diese Datei keinen Text enthält, und fragt die Benutzerin nach dem Namen der Textdatei. Erst danach kann PGP die Unterschrift prüfen. Wenn der Empfänger bereits weiß, daß Text und Unterschrift in getrennten Dateien gespeichert sind, kann er auch beide Dateinamen in der Kommandozeile angeben:
$\begin{command}2.6.x: pgp brief.sig brief.txt 5.0: pgpv brief.sig brief.txt gpg: gpg --verify brief.txt.sig brief.txt \end{command}$

In diesem Fall fragt PGP nicht nach dem Namen der Textdatei. Die Unterschrift in einer eigenen Datei zu speichern, ist dann sinnvoll, wenn die Unterschriften unabhängig vom Text protokolliert werden sollen, beispielsweise

als öffentliche Unterschrift unter einem Text, der erst später veröffentlicht werden soll (Prophezeiungen von Lottozahlen o.ä.).
für Dateien mit ausführbaren Programmen (bei MS-DOS: .EXE und .COM) oder Archive (beispielswiese .zip), um eine Virusprüfung durchzuführen.
wenn mehrere Personen ein Dokument (zum Beispiel einen Vertrag) unterschreiben sollen, ohne daß die Unterschriften "verschachtelt" werden. Die Unterschrift jeder einzelnen Person wird unabhängig von den anderen gespeichert.

PGP 2.6.x kann bei einer Datei, in der Unterschrift und Text in einer Datei stehen, die Unterschrift auch nachträglich vom Text trennen. Dies geschieht mit der Option -b bei der Entschlüsselung:
$\begin{command}2.6.x: pgp -b brief \end{command}$
Hier wird brief.pgp entschlüsselt. Falls eine Unterschrift vorhanden ist, wird sie geprüft und in einer eigenen Datei brief.sig gespeichert.

Diese Option fehlt leider bei PGP 5.0 und GnuPG.

3. Entschlüsselung einer Nachricht und Speicherung zusammen mit einer Unterschrift

Normalerweise wollen Sie eine verschlüsselte Nachricht vollständig entschlüsseln, die Unterschrift (oder mehrere verschachtelte Unterschriften) prüfen und hierbei eine "Schicht" nach der anderen abtrennen, bis der originale Klartext übrig bleibt. Manchmal wollen Sie aber die Nachricht nur entschlüsseln und die Unterschrift bei der Nachricht belassen.

Dies ist beispielsweise dann sinnvoll, wenn Sie die Kopie einer unterschriebenen Nachricht an eine dritte Person weiterleiten möchten, gegebenenfalls erneut verschlüsselt.

Angenommen, es kommt eine Nachricht, die Charlie unterschrieben hat, verschlüsselt mit dem öffentlichen Schüssel des Empfängers. Die Nachricht soll entschlüsselt und zusammen mit Charlies Unterschrift an Alice weitergeleitet werden, gegebenenfalls mit ihrem öffentlichen Schlüssel verschlüsselt. Mit PGP ist das kein Problem. Mit folgendem Kommando wird eine Nachricht entschlüsselt, ohne daß die Unterschriften abgetrennt werden:
$\begin{command}2.6.x: pgp -d brief gpg: gpg -d brief gpg: gpg --decrypt brief \end{command}$

Hier wird die Datei brief.pgp entschlüsselt, und Unterschriften werden, falls vorhanden, zusammen mit dem entschlüsselten Klartext in der Ausgabedatei gespeichert. Die Ausgabedatei kann archiviert oder - gegebenenfalls wieder verschlüsselt - an eine andere Person weitergeleitet werden. PGP 5.0 scheint keine derartige Option zu bieten.

4. Der Austausch von Text zwischen unterschiedlichen Computern

Mit PGP kann jede Art von Klartext verschlüsselt werden, irgendwelche Binärdaten ebenso wie Text. Wahrscheinlich wird PGP am häufigsten für die Verschlüsselung von E-Mail benutzt, so daß der Klartext aus Text-Daten besteht.

Text wird auf verschiedenen Computern leicht unterschiedlich dargestellt. Beispielsweise endet eine Zeile bei MS-DOS/Microsoft Windows mit den beiden Zeichen für Wagenrücklauf und Zeilenvorschub. Bei Unix endet eine Zeile nur mit dem Zeichen für Zeilenvorschub. Beim Macintosh endet eine Zeile mit dem Zeichen für Wagenrücklauf, ohne Zeilenvorschub. Umlaute einer MS-DOS-Textdatei werden unter Windows und Unix nicht korrekt angezeigt. Traurig, aber wahr.

Nicht verschlüsselte Textdaten werden bei E-Mail-Systemen in eine kanonische Form gebracht, wenn sie zwischen zwei Computern ausgetauscht werden. Bei kanonischer Textdarstellung besteht ein Zeilenende aus den Zeichen Wagenrücklauf und Zeilenvorschub. Beispielsweise E-Mail-Nachrichten werden beim Versand im Internet so kodiert. Außerdem werden die verwendeten Umlaute in eine allgemeinverständliche Form gebracht und das verwendete Format im "Header" der Nachricht, wo die Steuerinformationen stehen, vermerkt. Dadurch ist es einfach, Texte zwischen verschiedenen Computern auszutauschen.

Diese automatische Anpassung der Textdarstellung an das jeweilige Betriebssystem ist bei verschlüsselten Nachrichten nicht möglich, weil der Klartext durch die Verschlüsselung dem Übertragungsprogramm verborgen bleibt. Diese Aufgabe muß das Verschlüsselungsprogramm übernehmen. Deshalb kann man bei PGP angeben, ob der Klartext als Binärdaten oder als Text angesehen werden soll. In letzterem Fall wird der Klartext vor der Verschlüsselung in eine kanonische Form gebracht. Bei der Entschlüsselung wird er dann in die Form gebracht, die für das Betriebssystem des Computers, auf dem entschlüsselt wird, geeignet ist.

Wenn die Option -t bzw. -textmode beim Verschlüsseln und/oder Unterschreiben einer Nachricht mit angegeben wird, konvertiert PGP den Text vor der Verschlüsselung bzw. dem Unterschreiben in die kanonische Form.
$\begin{command}2.6.x: pgp -et message.txt Empfänger-ID 5.0: pgpe -t -r Alice message.txt gpg: gpg -e -r Bob --textmode message.txt \end{command}$

Diese Option schaltet PGP automatisch ab, sobald es in der zu verschlüsselnden Datei Daten findet, die es nicht als Text betrachtet. Falls der Klartext aus einem 8-Bit-Zeichensatz besteht, falls er also Zeichen enthält, die nicht im ASCII-Standard enthalten sind (Umlaute o.ä.), verwendet PGP bei der Konvertierung in die kanonische Form den Zeichensatz latin1 (ISO 8859-1 Latin Alphabet 1). Die Konvertierung hängt davon ab, was als Parameter CHARSET in der PGP-Konfigurationsdatei eingetragen ist, vgl. Abschnitt 14. Latin1 ist eine Obermenge von ASCII, mit diakritischen Zeichen (ä, ö, ü, $\l$ , ð, ...) für viele westeuropäische Sprachen.

5. Vermeidung von "Spuren des Klartextes" auf der Festplatte

Nachdem PGP eine Datei verschlüsselt hat, kann es bei Bedarf die Datei mit dem Klartext überschreiben und danach löschen, so daß keine "Spuren" des Klartextes auf der Festplatte verbleiben. Dies verhindert, daß der Klartext mit einem Sektor-Editor oder einem ähnlichen Programm noch gelesen werden kann. Diese Option ist sinnvoll, um zu vermeiden, daß vertrauliche Informationen unkontrolliert auf der Festplatte verbleiben.

Um den Klartext nach der Verschlüsselung von der Festplatte zu löschen, wird die Option w verwendet:
$\begin{command}2.6.x: pgp -esw message.txt Empfänger-ID \end{command}$

Hier wird eine verschlüsselte, unterschriebene Datei message.pgp erzeugt, und die Klartext-Datei message.txt wird danach überschrieben und gelöscht. Diese Option sollte mit Vorsicht benutzt werden - damit gelöschte Dateien sind verloren, auch wenn sie nur versehentlich gelöscht wurden.

Zudem muß betont werden, daß hierdurch keinerlei Fragmente des Klartextes gelöscht werden, die ein Textverarbeitungsprogramm häufig auf der Festplatte ablegt, wenn man einen Text eintippt und bearbeitet. Die meisten Textverarbeitungsprogramme erzeugen Backup- und temporäre Dateien. Außerdem wird die Klartext-Datei nur einmal überschrieben. Das ist zwar ausreichend, um ein Lesen des Klartextes mit den üblichen Werkzeugen der Datenwiederherstellung zu verhindern, reicht aber nicht aus, um einen gezielten und ausgefeilten Leseversuch abzuwehren, bei dem eine schwache Restmagnetisierung der überschriebenen Daten mittels spezieller Hardware ausgewertet wird. Weiterhin funktioniert dieses Überschreiben nicht immer garantiert, beispielsweise bei Verwendung einer komprimierten Festplatte kann es sehr leicht fehlschlagen. PGP 5.0 und GnuPG bieten leider keine derartige Option.

6. Import direkt vom Keyserver

Um einen Schlüssel (bei aktiver Internet-Verbindung) direkt von einem Keyserver zu laden, können Sie die folgenden Kommandos verwenden:
$\begin{command}5.0: pgpk -a User-ID 5.0: pgpk --HTTPKeyServerHost=horowitz.surfn... ...pg: gpg --recv-keys --keyserver=horowitz.surfnet.nl \ : Zimmermann \end{command}$
Bei PGP 5.0 funktioniert dieser Aufruf nur dann, wenn keine Datei mit dem angegebenen Namen gefunden wird. Außerdem ist es notwendig, daß in der Konfigurationsdatei ein Keyserver korrekt eingestellt ist (oder auf der Kommandozeile angegeben wird, wie im jeweils zweiten Beispiel). Für PGP 5.0 kann dies z.B. durch einen Eintrag

AutoServerFetch=1
HTTPKeyServerHost=pgpkeys.mit.edu
HTTPKeyServerPort=11371

geschehen (was aber die Standardeinstellungen sind). GnuPG verwendet immer den Standardport 11371, hier lautet die analoge Zeile in der Datei options

keyserver pgpkeys.mit.edu

7. Export zum Keyserver

Die im vorangegangenen Abschnitt genannten Einstellungen sind für GnuPG auch hier notwendig. PGP 5.0 erfordert die explizite Angabe des Servers, daher sind keine besonderen Einstellungen vonnöten.
$\begin{command}gpg: gpg --send-keys User-ID [User-ID2 ...] 5.0: pgpk -x User-ID -o hkp://horowitz.surfnet.nl \end{command}$

8. Anzeige des entschlüsselten Klartextes am Bildschirm

Um den entschlüsselten Klartext nur am Bildschirm zu lesen (ähnlich dem Unix-Kommando more), ohne daß er in eine Datei geschrieben wird, kann die Option -m verwendet werden:
$\begin{command}2.6.x: pgp -m brief.pgp 5.0: pgpv -m brief.pgp gpg: gpg --decrypt -o- brief.pgp \vert less \end{command}$

Dieser Befehl zeigt den entschlüsselten Klartext am Bildschirm an. Im Abschnitt 14 erfahren Sie, wie Sie ein externes Anzeigeprogramm einbinden, das das Lesen komfortabler macht.

9. Verschlüsseln einer Nachricht "nur für die Augen der Empfängerin"

Um festzulegen, daß die Empfängerin den entschlüsselten Klartext nur am Bildschirm lesen, ihn aber nicht in eine Datei schreiben kann, wird die Option -m beim Verschlüsseln verwendet:
$\begin{command}2.6.x: pgp -sem message.txt Empfänger-ID \end{command}$

Wenn die Empfängerin eine so verschlüsselte Nachricht mit ihrem privaten Schlüssel und ihrem Mantra entschlüsselt, wird der Klartext nur auf ihrem Bildschirm angezeigt, aber nicht auf der Festplatte gespeichert. Die Textanzeige erfolgt auf dem Bildschirm so, wie zuvor im Abschnitt 15.8 beschrieben.

Wenn der Empfänger die Nachricht ein zweites Mal lesen will, muß er die Nachricht erneut entschlüsseln.

Diese Option ist der sicherste Weg, um zu verhindern, daß vertrauliche Nachrichten versehentlich als Klartext auf der Festplatte des Empfängers liegenbleiben, leider kann sie es aber nicht verhindern, sondern entspricht mehr einem Warnschild. GnuPG bietet leider keine derartige Option; PGP 5.0 beachtet sie zwar bei mit 2.6.x verschlüsselten Dateien, bietet aber selbst keine Möglichkeit, eine Datei in dieser Weise zu verschlüsseln.

10. "Anonym" verschlüsseln

Wenn Sie Nachrichten versenden wollen, ohne daß Unbeteiligte (Mafia, Geheimdienste, Systemadministratoren, ...) erfahren, an wen Sie die Nachrichten verschlüsseln, ist einer der Schritte, Systeme wie Remailer und Mixmaster zu verwenden (siehe Kapitel 5.9 auf Seite ). Soll nicht bekannt werden, daß der Empfänger eine verschlüsselte Nachricht erhalten hat, können Sie die entsprechenden Nachrichten beispielsweise in die Newsgroup alt.anonymous.messages posten. Das reicht aber nicht aus, da normalerweise in einer verschlüsselten Nachricht vermerkt wird, wer sie entschlüsseln kann. Im OpenPGP-Standard ist deshalb vorgesehen, daß an der entsprechenden Stelle auch die Schlüssel-ID 0 eingetragen werden darf, was "keine Angabe" bedeutet. GnuPG bietet hierfür die Option -throw-keyid.
$\begin{command}gpg: gpg -o- --throw-keyid -ear padeluun secret \ : \vert inews -S -ttest -nalt.anonymous.messages \end{command}$

11. Beibehaltung des originalen Dateinamens des Klartextes

Normalerweise gibt PGP der Datei mit dem entschlüsselten Klartext den gleichen Namen wie der Datei mit dem verschlüsselten Text, aber ohne Suffix. Ein anderer Name für die Klartext-Datei kann mit der Option -o festgelegt werden. Bei den meisten E-Mail-Nachrichten ist dies sinnvoll, weil man so den Dateinamen bei der Entschlüsselung festlegen kann und typische Nachrichten meist unbrauchbare ursprüngliche Dateinamen wie an_phil.txt oder krypt.msg haben.

Wenn PGP eine Klartext-Datei verschlüsselt, fügt es den originalen Dateinamen dem Klartext vor der Komprimierung bei. Normalerweise verwendet PGP diesen originalen Dateinamen bei der Entschlüsselung nicht, aber bei Bedarf kann PGP angewiesen werden, der entschlüsselten Klartext-Datei diesen Namen zu geben. Das ist sinnvoll, wenn PGP dazu benutzt wird, Dateien zu ver- und entschlüsseln, deren Name von Bedeutung ist.

Um den originalen Namen der Klartext-Datei zu erhalten, kann die Option -p bzw. -use-embedded-filename verwendet werden. Um beim Verschlüsseln einen anderen Namen als Originalnamen einzutragen, bietet GnuPG die Option -set-filename.
$\begin{command}2.6.x: pgp -p verschlüsselte-datei gpg: gpg --use-embedded-filen... ...selte-datei gpg: gpg --set-filename nochnemail -er tom /etc/passwd \end{command}$

12. Ändern der Benutzer-ID und des Mantras

Ab und zu kann es erforderlich sein, das Mantra zu ändern, beispielsweise dann, wenn jemand beim Eintippen des Mantras zugeschaut hat. Oder die Benutzer-ID muß geändert werden, sei es wegen einer Heirat oder wegen einer geänderten E-Mail-Adresse. Oder es soll dem Schlüssel eine zweite oder dritte Benutzer-ID hinzugefügt werden, um mehrere E-Mail-Adressen oder eine Berufsbezeichnung einzutragen.

Mit PGP können einem Schlüssel mehrere Benutzer-IDs hinzugefügt werden, und jede dieser IDs kann für die Auswahl des Schlüssel aus dem Bund mit öffentlichen Schlüsseln verwendet werden. Die eigene Benutzer-ID und das Mantra können mit folgendem Kommando geändert werden:
$\begin{command}2.6.x: pgp -ke Benutzer-ID [Schlüsselbund] 5.0: pgpk -e Benutzer-ID gpg: gpg --edit-key Benutzer-ID \end{command}$

PGP fragt dann nach der neuen Benutzer-ID und dem neuen Mantra. Wenn der optionale Parameter Schlüsselbund angegeben wird, muß es sich um einen Bund mit öffentlichen Schlüsseln handeln, nicht mit geheimen. Der Parameter Benutzer-ID muß die eigene ID sein. PGP erkennt dies daran, daß diese ID sowohl im Bund mit öffentlichen Schlüsseln als auch im Bund mit geheimen Schlüsseln auftaucht. Beide Dateien werden geändert, auch wenn ein Bund mit öffentlichen Schlüsseln als Parameter angegeben wurde.

GnuPG bietet bei diesem Aufruf ein Menü, in dem Sie u.a. die Befehle adduid, deluid, addkey, delkey und passwd finden können. adduid und deluid dienen hierbei dem Hinzufügen und Löschen einzelner User-Kennungen. Mit addkey und delkey können Sie Ihre Teilschlüssel verwalten, also beispielsweise die alle sechs Monate gewechselten Schlüssel für privaten E-Mail-Verkehr. passwd schließlich dient dazu, das Mantra zu ändern.

13. Ändern der Vertrauensparameter für einen öffentlichen Schlüssel

Manchmal müssen die Vertrauens-Einstellungen für einen öffentlichen Schlüssel geändert werden. Was diese Vertrauensparameter sind, steht im Abschnitt 7.3. Mit folgendem Befehl können die Vertrauensparameter für einen öffentlichen Schlüssel geändert werden:
$\begin{command}2.6.x: pgp -ke Benutzer-ID [Schlüsselbund] 5.0: pgpk -e Benutzer-ID gpg: gpg --edit-key Benutzer-ID Menü: trust \end{command}$

Wenn der optionale Parameter Schlüsselbund angegeben wird, so muß es ein Bund mit öffentlichen Schlüsseln sein, nicht mit geheimen Schlüsseln.

14. Prüfen, ob der Bund mit öffentlichen Schlüsseln intakt ist

Normalerweise prüft PGP automatisch jeden Schlüssel und jede Unterschrift, die einem Bund mit öffentlichen Schlüsseln hinzugefügt werden, und paßt automatisch die Vertrauenseinstellungen und Gültigkeitswerte an. Theoretisch paßt es die Gültigkeitswerte aller betroffenen Schlüssel an, wenn ein Schlüssel dem Bund mit öffentlichen Schlüsseln hinzugefügt oder aus ihm gelöscht wird. Manchmal möchte man aber auch dann eine umfassende Analyse haben, wenn keine Änderungen an dem Schlüsselbund erforderlich sind: Prüfen der Bestätigung(en) der einzelnen Schlüssel, Prüfen der Vertrauensparameter, Neuberechnung der Gültigkeitswerte und Vergleich des eigenen, absolut vertrauenswürdigen Schlüssels mit der Sicherheitskopie auf einer schreibgeschützten Diskette. Es ist sinnvoll, diese Integritäts- und Konsistenzprüfung in regelmäßigen Abständen durchzuführen, um sicherzustellen, daß der Bund mit öffentlichen Schlüsseln wirklich intakt ist. Mit der Option -kc führt PGP eine vollständige Analyse des Bundes mit öffentlichen Schlüsseln aus:
$\begin{command}2.6.x: pgp -kc 5.0: pgpk -c gpg: gpg --check-sigs \end{command}$

Mit folgendem Befehl prüft PGP die Unterschriften für einen bestimmten öffentlichen Schlüssel:
$\begin{command}2.6.x: pgp -kc Benutzer-ID [Schlüsselbund] 5.0: pgpk -c Benutzer-ID gpg: gpg --check-sigs Benutzer-ID \end{command}$

Weitere Informationen darüber, wie der eigene Schlüssel mit einer Sicherheitskopie verglichen wird, stehen bei der Beschreibung des Parameters BAKRING im Abschnitt 14.

Eine komplette Überprüfung des Schlüsselbunds kann auch mit dem Befehl pgp -km durchgeführt werden, hierbei zeigt PGP auch die Vertrauensketten an.

15. Telephonische Kontrolle eines öffentlichen Schlüssels

Es kann vorkommen, daß man einen öffentlichen Schlüssel bekommt, der nicht von einer anderen vertrauenswürdigen Person bestätigt ist. Dann stellt sich die Frage, wie sich die Echtheit dieses Schlüssels feststellen läßt. Der beste Weg hierfür ist die Kontrolle des Schlüssels über einen anderen Kanal als den, über den der Schlüssel geschickt wurde.

Wenn man die Person kennt, der der öffentliche Schlüssel gehört, und wenn man auch ihre Stimme am Telephon erkennt, besteht eine einfache und bequeme Lösung des Problems darin, sie anzurufen, und den Schlüssel im Gespräch zu kontrollieren. Hierzu braucht man sich nicht mühsam den ganzen ASCII-dargestellten Schlüssel vorzulesen. Es reicht, den verhältnismäßig kurzen Fingerabdruck des Schlüssels zu vergleichen. Den Fingerabdruck eines Schlüssel gibt PGP mit der Option -kvc aus:
$\begin{command}2.6.x: pgp -kvc Benutzer-ID [schlüsselbund] 5.0: pgpk -ll Benutzer-ID gpg: gpg --fingerprint Benutzer-ID \end{command}$

PGP zeigt die Benutzer-ID zusammen mit dem Fingerabdruck an. Wenn beide Gesprächspartnerinnen diesen PGP-Befehl ausführen, können sie den Schlüssel anhand des Fingerabdruck kontrollieren.

Wenn die Echtheit sowohl des eigenen öffentlichen Schlüssels als auch des öffentlichen Schlüssels des Gesprächspartners überprüft ist, kann die Echtheit der Schlüssel wechselseitig durch eine Unterschrift bestätigt werden. Dies ist ein sicherer und komfortabler Weg, um mit dem Aufbau eines Netzes vertrauenswürdiger Schlüssel innerhalb eines Kreises von Freunden und Freundinnen zu beginnen.

Übrigens bietet sich der Fingerabdruck des eigenen Schlüssels geradezu dazu an, auf die Visitenkarte gedruckt zu werden.

16. Ein Wort zu großen öffentlichen Schlüsselbunden

PGP ist ursprünglich entwickelt worden, um kleine Schlüsselbunde mit ein paar hundert Schlüsseln zu verwalten. Mit der Zeit ist PGP aber sehr beliebt geworden, so daß viele Leute nun riesige Schlüsselbunde verwenden. Hierfür ist PGP 2.6.x nicht ausgelegt. Für die Aufnahme einiger Tausend Schlüssel in Ihren persönlichen Schlüsselbund kann PGP erhebliche Zeit brauchen.

Vielleicht möchten Sie einen riesigen "importierten" Schlüsselbund Ihrem eigenen hinzufügen, obwohl Sie eigentlich nur an ein paar Dutzend Schlüsseln interessiert sind. Wenn das alles ist, was Sie mit so einem riesigen Schlüsselbund anstellen möchten, gibt es einen effizienteren Weg: Extrahieren Sie die wenigen für Sie interessanten Schlüssel aus dem großen Bund und fügen Sie diese Schlüssel Ihrem eigenen Bund hinzu.

GnuPG können Sie anweisen, einen Schlüsselbund mit richtigen Datenbankmethoden zu verwalten, indem Sie ihn in der config-Datei mit gnupg-gdbm: vor dem eigentlichen Dateinamen angeben, also beispielsweise

keyring gnupg-gdbm:bigring

17. PGP als Filterprogramm im Unix-Stil

Unix-Fans sind es gewöhnt, "pipes" zu verwenden, um Daten zwischen zwei Programmen auszutauschen. Der Output eines Programms kann mittels einer "pipe" als Input in ein zweites Programm gelenkt werden. Damit dies funktioniert, müssen die Programme als "Filter" arbeiten, also ihre Daten aus dem "standard input" lesen und auf den "standard output" schreiben. PGP kann in dieser Form arbeiten.

Falls Ihnen schleierhaft ist, was obiges zu bedeuten hat, werden Sie diese Möglichkeit wahrscheinlich auch nicht brauchen, so daß Sie diesen Abschnitt überspringen können.

Wenn die Option -f verwendet wird, arbeitet PGP als Filter. Beispiel:
$\begin{command}2.6.x: ls -al \vert pgp -feast Empfänger-ID \ : \vert mail -s '**... ...o'' \vert gpg -ear tom \ : \vert mail t.budewig@bionic.zerberus.de \end{command}$

Diese Option kann die Verwendung von PGP zusammen mit E-Mail-Programmen vereinfachen.

Wenn man PGP als Unix-Filter verwendet, möglicherweise in einem Unix-Skript oder in einer MS-DOS-Batchdatei, kann es sinnvoll sein, die Umgebungsvariable PGPPASS zu verwenden, um zu verhindern, daß PGP bei jedem Aufruf das Mantra abfragt. PGPPASS ist weiter unten beschrieben.

18. Unterdrückung nicht notwendiger Fragen: BATCHMODE

Wird in der PGP-Befehlszeile +batchmode angegeben, stellt PGP während des Programmablaufes keinerlei unnötige Fragen. Bei PGP 5.0 heißt die entsprechende Option -z, bei GnuPG -batch. Beispiel:
$\begin{command}2.6.x: pgp +batchmode verschlüsselte_datei 5.0: pgpv -z verschlüsselte_datei gpg: gpg --batch verschlüsselte_datei \end{command}$

Dies ist sinnvoll, wenn PGP aus Unix-Shell-Skripten oder aus einer MS-DOS-Batchdatei aufgerufen wird. Manche PGP-Befehle, insbesondere für die Schlüsselverwaltung, benötigen in jedem Fall Eingaben durch die Benutzerin. Sie sollten deshalb in Shell-Skripten vermieden werden.

BATCHMODE kann auch bei der Prüfung der Echtheit einer Unterschrift verwendet werden. Ist die Unterschrift nicht in Ordnung, wird als Beendigungscode 1 zurückgegeben. Bei einer intakten Unterschrift gibt PGP den Wert 0 zurück. Bei GnuPG ist hierfür kein gesonderter Parameter notwendig, gpg -verify liefert bereits 1 oder 0 als Rückgabewert.

19. "Ja" oder "Nein" als Standardantwort bei Bestätigungsabfragen: FORCE/yes/no

FORCE veranlaßt PGP, "ja" als Standardantwort anzunehmen, wenn es danach fragt, ob eine bereits existierende Datei überschrieben werden soll, oder ob ein öffentlicher Schlüssel aus einem Schlüsselbund mit -kr entfernt werden soll. GnuPG bietet als analoge Option -yes und komplementär -no. PGP 5.0 hat keine entsprechende Option. Beispiel:
$\begin{command}2.6.x: pgp +force verschlüsselte_datei gpg: gpg --yes verschlüsselte_datei gpg: gpg --no verschlüsselte_datei \end{command}$
oder:
$\begin{command}2.6.x: pgp -kr +force smith gpg: gpg --import --no keyring.asc \end{command}$

FORCE kann praktisch sein, wenn PGP aus einem Skript (MS-DOS: Batchdatei) aufgerufen wird.

20. Der Beendigungscode von PGP

Um den Betrieb von PGP aus Unix-Skripten oder MS-DOS-Stapeldateien zu unterstützen, gibt PGP eine Statusmeldung an die aufrufende Shell zurück. Ein Beendigungscode von 0 bedeutet, daß kein Fehler auftrat; jeder andere Wert signalisiert einen Fehler. Hiermit können Sie beispielsweise Kommandosequenzen wie diese verwenden:

pgp -seat $mailfile $empfaenger
if [ $? -eq 0 ]; then
 mail -s 'encrypted file' $empfaenger <$mailfile.asc
else
 ...
fi

Eine Liste der möglichen Fehlercodes, wie sie PGP 2.6.3i liefert, finden Sie in der folgenden Tabelle:

21. Umgebungsvariable für das Mantra: `PGPPASS`

Normalerweise fragt PGP das Mantra genau zu dem Zeitpunkt ab, zu dem ein geheimer Schlüssel benötigt wird. Das Mantra kann aber auch in der Umgebungsvariablen PGPPASS gespeichert werden. Wenn PGPPASS definiert ist, versucht PGP, ihren Wert als Mantra für den Zugriff auf einen geheimen Schlüssel zu verwenden. Ist das in PGPPASS gespeicherte Mantra nicht korrekt, fragt PGP nach dem richtigen Mantra.

Unter MS-DOS könnte das Mantra so gesetzt werden:

SET PGPPASS=Zaphod Beeblebrox wird Bundespräsident

Die Eingabe eines Mantra während des Laufs von PGP ist dann nicht mehr erforderlich, vorausgesetzt, daß "Zaphod Beeblebrox wird Bundespräsident" wirklich das richtige Mantra ist.

Nein, das wäre kein gutes Mantra, insbesondere, wenn Sie Douglas Adams-Fan sind. Nicht einmal, wenn wir es nicht abgedruckt hätten. "Am gelben Auto ein 25er Diamant." oder so etwas ist schon etwas besser. Was wirklich gut ist, hängt davon ab, wie gut Sie es sich merken können -- Ihr Mantra sollte so kompliziert und so wenig zu Ihnen passend sein, daß Sie es gerade noch behalten und schnell tippen können, ohne daß Sie es aufschreiben müssen. Wenn Sie sich etwas wie tte/RU66WcgIa.F0};6DeAy??zu@7dzc-iIsP+ merken können und bereit sind, es täglich mehrmals zu tippen, wäre das natürlich toll und sehr, sehr sicher. Außerdem hätten Sie dann meine Hochachtung - ich könnte mir das nie merken.

Die Verwendung von PGPPASS ist einerseits riskant, macht aber andererseits die Arbeit mit PGP wesentlich einfacher, wenn man regelmäßig größere Mengen verschlüsselter Nachrichten erhält.

Die Auswertung der Umgebungsvariablen PGPPASS hat Philip Zimmermann auf vielfachen Wunsch hin in PGP aufgenommen. Die Verwendung von PGPPASS ist aber gefährlich, weil das Mantra dann nicht nur in Ihrem Gedächtnis, sondern auch irgendwo im Speicher Ihres Rechners steht. Leichtsinnig wäre es, das Mantra in einer Datei auf demselben Rechner zu speichern, auf dem auch Ihre Datei secring.pgp steht. Nicht nur sehr leichtsinnig, sondern einfach dumm wäre es, das Mantra in einer Batchdatei, am Ende gar in autoexec.bat, zu speichern. Jedermann könnte sich in der Mittagspause an Ihren Rechner setzen und sowohl Ihr Mantra als auch Ihren geheimen Schlüsselbund mitgehen lassen.

Die Gefährlichkeit von PGPPASS kann nicht stark genug betont werden.

Falls Sie PGPPASS unbedingt brauchen, ist es am sichersten, das Kommando zum Setzen von PGPPASS unmittelbar vor der Benutzung von PGP einzutippen und unmittelbar nach der Benutzung von PGP PGPPASS wieder zu löschen oder den Computer auszuschalten. Sie sollten PGPPASS auf keinen Fall verwenden, wenn andere Personen Zugang zu Ihrem Computer haben. Jemand könnte vorbeikommen und Ihr Mantra ganz einfach durch Abfragen der Umgebungsvariablen herausfinden.

PGP stellt noch weitere, weniger bedenkliche Methoden zur Verfügung, mit denen die Eingabe des Mantras automatisiert werden kann. Auch diese sind Sicherheitsrisiken, aber kleinere. Das Mantra kann mit der Option -z in der Befehlszeile übergeben werden:
$\begin{command}2.6.x: pgp -m zZaphod Beeblebrox wird Kanzler'' geheim.pgp \end{command}$

Oder es wird in eine (vor anderen Benutzern geschützte) Datei geschrieben und der Pfad und der Dateiname dieser Datei in der Umgebungsvariablen PGPPASSFD gespeichert.

GnuPG bietet etwas ähnliches, hier muß aber ein "file descriptor" angegeben werden. Die Details sind eher unwichtig und meistens wird die Funktionalität vermutlich verwendet, wenn GnuPG von einem anderen Programm aus gestartet wird. Wenn Sie die bash verwenden, funktioniert z.B. so ein Aufruf:

$\begin{command}gpg: gpg --passphrase-fd 42 -sb datei.txt 42<~/.gpg/mantra \end{command}$

Bedenken Sie bei allen diesen "Vereinfachungen", daß Systemadministratoren auf praktisch allen Systemen problemlos alle Dateien und Umgebungsvariablen lesen können. Es ist natürlich richtig, daß sie auch laufenden Prozessen "über die Schulter schauen" können, aber das ist wesentlich aufwendiger und bedarf eines sehr viel genaueren Timings. Sie sollten auch nicht vergessen, daß die eigentlichen Systemadministratoren oft überrascht wären, wer alles Administrator-Rechte auf ihrem System hat. Außerdem hat der Aufruf mit der Option -z den Nachteil, daß Ihr Mantra dann auf der Kommandozeile steht. Zum Einen gelangt es so in die "history" Ihrer Shell (unter MS-DOS reicht sie im Original nur eine Zeile weit, aber mit 4DOS sieht das schon wieder anders aus...), zum anderen ist die Kommandozeile eines laufenden Prozesses auch für andere Benutzer sichtbar. PGP überschreibt den entsprechenden Teil zwar mit Leerzeichen, aber in der Zeit bis dahin ist Ihr Mantra für jeden eingeloggten Benutzer lesbar.