GnuPG: GnuPG benutzen
GnuPG ist nun schon voll einsatzbereit. Was man jetzt noch wissen sollte, steht in diesem Kapitel.
Auflisten (Kommandozeile)
[Bearbeiten]Mit gpg --list-keys erhält man eine Auflistung all seiner öffentlichen Schlüssel („Schlüsselbund“, „key ring“). Zum Beispiel:
/home/sbeyer/.gnupg/pubring.gpg ------------------------------- pub 1024D/FCC5040F 2004-04-26 uid Stephan Beyer <s-beyer@gmx.net> uid Stephan Beyer (sbeyer) <sbeyer@kidstation.de> uid [jpeg image of size 2193] uid Stephan Beyer (Uni) <Stephan.Beyer@stud.tu-ilmenau.de> uid Stephan Beyer (JabberID) <sbeyer@jabber.org> sub 1024g/AC6D579F 2004-04-26
pub steht für „öffentlich“ (public), während sec für „geheim“ (secure) stünde. Bei FCC5040F handelt es sich also um die Schlüssel-ID meines öffentlichen Schlüssels. 2004-04-26 ist das ISO-Datum (JJJJ-MM-TT) der Schlüsselerstellung. Die mit uid beginnenden Zeilen zeigen meine Benutzer-IDs („user id“), wie z. B. Stephan Beyer <s-beyer@gmx.net>. 1024 bedeutet, dass der Schlüssel 1024 Bit lang ist. Hinter der Länge steht jeweils das Verfahren: Ein D bedeutet DSA, g ist ElGamal, R steht für RSA. sub steht für öffentliche und ssb für geheime Unterschlüssel.
Man kann die Ergebnisliste auf bestimmte Treffer einschränken, wenn man als folgende Parameter einfach Suchkriterien eingibt. Diese sind automatisch mit ODER verknüpft. Beispiel:
~$ gpg --list-key 'Werner Koch' 6EDDD207FCC5040F pub 1024D/FCC5040F 2004-04-26 uid Stephan Beyer <s-beyer@gmx.net> uid Stephan Beyer (sbeyer) <sbeyer@kidstation.de> uid [jpeg image of size 2193] uid Stephan Beyer (Uni) <Stephan.Beyer@stud.tu-ilmenau.de> uid Stephan Beyer (JabberID) <sbeyer@jabber.org> sub 1024g/AC6D579F 2004-04-26 pub 1024D/57548DCD 1998-07-07 [expires: 2005-12-31] uid Werner Koch (gnupg sig) <dd9jn@gnu.org> pub 1024D/3DDBDDEA 2001-11-03 uid Hans-Joachim Baader <hjb@pro-linux.de> sub 1024g/2C42C700 2001-11-03
Es ist übrigens (wie auch bei den vielen anderen gpg-Kommandos) egal, ob man Singular (--list-key) oder Plural (--list-keys) benutzt die Ausgabe bleibt die gleiche. Kann gpg keine Treffer zur Suche finden, erzeugt es einen Fehler:
~$ gpg --list-keys gibtsnicht gpg: error reading key: public key not found ~$ echo $? 2
Mit --list-secret-keys zeigt GnuPG alle geheimen Schlüssel aus dem Schlüsselbund „secring.gpg“ an. Sollten Sie mehrere Schlüssel haben, können optional ein Schlüssel oder Teile davon mit angegeben werden:
$ gpg --list-secret-keys meisenkaiserin@nym sec 1024D/123123AB 2007-07-23 [expires: 2009-01-01] uid Huerbine von Pleuselspink (2007-2008) <meisenkaiserin@nym.alias.net> ssb 2048g/456ABC45 2007-07-23 [expires: 2008-07-29]
Sollte hinter dem sec ein #-Zeichen stehen, so bedeutet dies, der Schlüssel ist nicht mehr benutzbar.
Mit --list-sigs zeigt gpg die Signaturen der Schlüssel an.
Mit --fingerprint zeigt gpg die „Fingerabdrücke“ der Schlüssel an, mit denen man Schlüssel identifizieren kann. --fingerprint ist ein gpg-Kommando, während --with-fingerprint eine Option ist, die man bei anderen Kommandos nutzen kann:
~$ gpg --list-sigs --with-fingerprint sbeyer
pub 1024D/FCC5040F 2004-04-26
Key fingerprint = F03F E6A6 F9B8 9520 88BA 587E 6EDD D207 FCC5 040F
uid Stephan Beyer <s-beyer@gmx.net>
sig 3 FCC5040F 2004-10-09 Stephan Beyer <s-beyer@gmx.net>
sig 7624F276 2004-04-29 SilenceX <SilenceX@parityerror.de>
sig 687B8FCA 2004-06-26 Frank Lerche <frank@frank-lerche.de>
sig 4743206C 2004-06-28 Joachim Breitner <mail@joachim-breitner.de>
[...]
Anmerkung: Wenn Sie gpg-Listenausgaben in Skripten zur weiteren Verarbeitung verwenden wollen, nutzen Sie den Zusatzparameter --with-colons. Das Ausgabeformat dazu ist näher unter /usr/share/doc/gnupg/DETAILS.gz erläutert. Wenn Sie dabei mit --list-sigs arbeiten, nutzen Sie zusätzlich --fast-list-mode. Das ist schneller, da es nur die in der Signatur verankerte Schlüssel-ID anzeigt und nicht noch nach der primären Benutzer-ID im Schlüsselbund suchen muss (uid wird dann generell weggelassen). Dann sei noch --fixed-list-mode erwähnt, das Schlüssel-ID und primäre Benutzer-ID getrennt anzeigt und die Zeit in Sekunden seit 1.1.1970 angibt.
Exportieren
[Bearbeiten]Wahrscheinlich will man seinen öffentlichen Schlüssel mal in eine Datei ausgeben (z. B. um ihn auf seine Homepage zu legen). Exportieren macht --export, das ohne Parameter allerdings alle öffentlichen Schlüssel ausgibt (analog zu --list-keys). Zu Anfang ist das zwar nur der eigene, trotzdem sollte man eindeutige Teile der Benutzer-ID (z. B. Name oder E-Mailadresse) oder die Schlüssel-ID (8-stellig, 16-stellig oder 40-stellig – der gesamte Fingerprint –, mit und ohne vorangestelltem 0x möglich) an --export anfügen. --export 0xFCC5040F und --export s-beyer@gmx.net führen immer zu dem, was ich will. In dieser Form ist es also weitestgehend eindeutig. --export Stephan exportiert irgendwann auch die anderen Stephans, deren öffentliche Schlüssel ich mal haben werde.
Mit --output Dateiname bzw. -o Dateiname wird die Ausgabe in einer Datei gespeichert. (Ich hab anfangs immer eine UNIX-typische Umleitung mittels > Dateiname gemacht und auch keine Probleme damit gehabt. Dennoch empfehle ich, lieber -o Dateiname zu verwenden.) Beispiel:
gpg -o ~/sbeyer-public-key.gpg --export 0xFCC5040F
Werfe ich einen Blick in die neu erstellte sbeyer-public-key.gpg, so stelle ich fest, dass es sich um ziemlich hässliche 8-Bit-Ausgaben handelt, und das ist übers Netz manchmal ungeeignet zu verschicken, gerade per E-Mail. Dafür bietet gpg die Option -a bzw. --armor an, die man unbedingt bei allen Ausgaben nutzen sollte, um 8-Bit-Ausgaben zu unterdrücken und schöne Base64-Ausgaben zu machen.
gpg -a -o ~/sbeyer-public-key.asc --export 0xFCC5040F
Der Dateisuffix .asc wurde gewählt, weil sich jetzt nur noch ASCII-Symbole, ja sogar nur druckbare Zeichen in sbeyer-public-key.asc befinden.
Auf einigen Systemen ist statt einer ~/.gnupg/gpg.conf eine ~/.gnupg/options installiert, welches die Konfigurationsdatei älterer GnuPG-Versionen war. Ich empfehle in diesem Falle, die Datei umzubenennen. Wenn gpg.conf existiert, wird options ignoriert.
Widerrufen
[Bearbeiten]Möchte man aus welchen Gründen auch immer seinen Schlüssel widerrufen, so importiert man das zu dem Schlüssel gehörige Widerrufszertifikat. Damit wird der Schlüssel lokal auf dem Rechner widerufen. Aber Vorsicht, das Widerrufen eines Schlüssels ist endgültig und kann nicht rückgängig gemacht werden. Alle Dokumente, Emails etc., die mit diesem Schlüssel verschlüsselt wurden, sind nicht wiederherstellbar. Damit nun aber auch der Rest der Welt erfährt, dass wir unseren Schlüssel widerrufen haben, senden wir unseren Schlüssel, der nun ein Widerrufszertifikat trägt, erneut an einen Schlüsselserver. Der Code dafür sieht wie folgt aus:
gpg --import ~/.gnupg/revoke.asc gpg --send-keys Schlüssel-ID
Importieren
[Bearbeiten]Mit gpg --import Dateiname wird der öffentliche Schlüssel eines Kommunikationspartners aus einer exportierten Datei importiert. Ohne Angabe eines Dateinamens kann man den Schlüssel per Zwischenablage hinein kopieren oder abtippen viel Spaß... Erst mit dem Import, also dem Hinzufügen des Schlüssels zum eigenen Schlüsselbund („Keyring“), kann man verschlüsselte Daten mit dem Benutzer austauschen, ihn signieren etc. Anders ausgedrückt: Erst wenn er importiert ist, „kennt“ GnuPG ihn.
Signieren von Schlüsseln
[Bearbeiten]Mit gpg --sign-key ID gibt man an, dass man den Schlüssel mit der entsprechenden ID (wie bei --export oder --list-keys) signieren und somit beglaubigen will. GnuPG stellt zur Sicherheit noch ein paar Fragen, die man möglichst ehrlich beantworten sollte. Das soll heißen, dass der Schlüssel wirklich zu überprüfen ist: persönlich, mit amtlichen Ausweis und gpg-Fingerabdruck. Für solche Zwecke gibt es zum Beispiel Keysigning-Partys, worauf ich später noch zurückkommen werde.
Natürlich sollte man der Welt zeigen, dass man diesen Schlüssel signiert hat. Das macht man, indem man den Schlüssel an einen Schlüsselserver oder dem Schlüsseleigentümer per E-Mail sendet (am besten verschlüsselt), er ihn dann importiert und selbst an einen Server schickt. (Wer öfter signiert und das Ganze ernsthaft und gewissenhaft betreibt, fasst seine Signaturregeln und sein Signierverhalten in einer Richtlinie zusammen.)
Bearbeiten und Löschen
[Bearbeiten]Mit gpg --edit-key ID (kurz: --edit) erhält man eine interaktive GnuPG-Kommandozeile zum Bearbeiten des Schlüssels. help oder auch die Manpage leisten dazu Hilfe. Wenn man die Begriffe beherrscht, ist die Menüführung an sich sehr einfach. Mit den verfügbaren Befehlen kann man alle bisher gemachten Angaben nochmals verändern, Schlüssel signieren, ein JPEG-Foto (nicht zu groß!) von sich hinzufügen, Besitzer-Vertrauen setzen, Richtlinien-Adresse hinzufügen und vieles mehr.
Das Kommando --delete-key ID entfernt den angegebenen öffentlichen Schlüssel aus dem Schlüsselbund (z. B. falls man versehentlich einen falschen oder veralteten importiert hat). --delete-secret-key ID löscht angegebene (eigene) geheime Schlüssel.
PGP-Schlüsselserver
[Bearbeiten]Ich habe es vorher schon erwähnt. Ein Schlüsselserver speichert die öffentlichen Schlüssel für alle (leider auch für Spammer) abrufbar ab. Um Schlüsselserver anzugeben, kann man die Option --keyserver Schlüsselserver benutzen. Ich empfehle aber einen Eintrag wie keyserver Schlüsselserver in die ~/.gnupg/gpg.conf. Außerdem empfehle ich einen Blick in die Manpage (man gpg), wegen --keyserver-options (bzw. seinen gpg.conf-Konfigurationszeilen), womit man Timeouts, Proxyserver und andere Dinge einstellen kann.
Werner Koch, der Entwickler von GnuPG, schrieb mir nach Erstveröffentlichung des Artikels eine Mail und bat mich, einen Schlüsselserver zu empfehlen. Er schrieb:
- „Fast alle Schlüsselserver haben gewaltige Probleme mit OpenPGP-Schlüsseln, die über die ganz einfache Struktur hinausgehen. Man sollte sie deswegen nicht mehr benutzen. Die Round-Robin-Adresse
subkeys.pgp.netist eine Alternative, da diese Server gepatcht sind und die Schlüssel wenigstens nicht mehr unbrauchbar machen falls das passiert ist, kann man sowieso nichts mehr machen. Meine Empfehlung lautet, SKS-Schlüsselserver zu benutzen. Diese haben eine moderne Software, die aktiv entwickelt wird, und zudem noch einen sehr fortschrittlichen Synchronisationsmechanismus. Sie gleichen auch mit den alten Servern ab, sofern die Schlüssel in Ordnung sind. In Deutschland istkeyserver sks.keyserver.penguin.deangebracht.“ Anmerkung: Der erwähnte SKS-Server ist nicht mehr erreichbar,keyserver.noreply.orgist eine Alternative.
Viele Schlüsselserver bieten ein Web-Interface zur Suche, zum Abrufen und zum Einsenden von öffentlichen Schlüsseln an. Allerdings ist es oft schneller und einfacher, GnuPG selbst mit dem Schlüsselserver kommunizieren zu lassen. Hierzu beherrscht GnuPG verschiedene Protokolle:
- Das „Horowitz Key Protocol“, kurz HKP, benannt nach Marc Horowitz vom MIT, der den ersten Schlüsselserver überhaupt programmierte und aufsetzte. Dieser ist aber jetzt anscheinend veraltet bzw. fehlerhaft (siehe oben), daher bitte nicht verwenden! HKP basiert eigentlich auf HTTP und ist nur eine Art Erweiterung. Sowohl die ältere PKS-Software als auch die neue und bessere SKS-Serversoftware kommunizieren über HKP, das über Port 11371 läuft. Beispiele nutzbarer Server sind:
x-hkp://keyserver.noreply.org,hkp://subkeys.pgp.net. Wer hinter einer Firewall sitzt, wird sich über einen HKP-Server auf Port 80 freuen, wie zum Beispielhkp://keyserver.kjsl.com:80(gepatchter PKS) oderhkp://pgp.srv.ualberta.ca:80(SKS). - „Finger“ ist ein sehr altes Protokoll, um Informationen eines anderen Nutzers (auf demselben oder anderem Host) zu bekommen. Solch eine Information kann auch der öffentliche Schlüssel sein (je nach Fingerdämon in
~/.pgpkey,~/.pubkeyoder~/.plan). Als Schlüsselserver gibt manfinger:User@Hostan. Finger läuft über TCP-Port 79. - GnuPG kann auch per E-Mail Schlüssel anfordern, hochladen, suchen. Allerdings erhält man die Antwort des Servers auch nur per E-Mail und nicht von gpg selbst. Dazu sollte ein lauffähiger und konfigurierter MTA (z. B. Exim, Postfix, Sendmail, etc.) installiert sein. Die Serversoftware dazu stammt von Michael Graff. Das Schlüsselserver-Schema sieht so aus:
mailto:E-Mailadresse, meistmailto:pgp-public-keys@Server. Allerdings habe ich den Verdacht, dass alle E-Mail-Schlüsselserver veraltete PKS-Software laufen haben. - Das „Lightweight Directory Access Protocol“, kurz LDAP, ist eigentlich ein Protokoll für Verzeichnisdienste. Network Associates Inc. kreierten die erste (einzigen?) LDAP-Schlüsselserversoftware. Beispiele:
ldap://certserver.pgp.comfunktionierte bei mir als einziger, angeblich soll auchldap://pgp.surfnet.nlgute Dienste leisten. LDAP-Schlüsselserver lauschen auf Port 11370 und LDAPS-Schlüsselserver auf 11369.
Für alle Protokolle sind GnuPGs Befehle die gleichen, aber das Verhalten mag leicht unterschiedlich sein. HKP ist die übliche und wahrscheinlich auch älteste Methode, daher beziehe ich mich immer auf das Verhalten von gpg, wenn es mit einem HKP-Schlüsselserver kommuniziert.
Also: wie lauten die Befehle?
- Mit
gpg --search-keys "Stephan Beyer"(kurz:--search) suche ich z. B. alle meine öffentlichen Schlüssel und natürlich die meiner namentlichen Doppelgänger. GnuPG zeigt mir daraufhin die Treffer an. Aus diesen Treffern kann ich interaktiv einen auswählen und dieser wird automatisch importiert. - Mit
gpg --send-keys 0xFCC50404F(kurz:--send) exportiere ich meinen Schlüssel an den angegebenen Schlüsselserver. GnuPG meldet sich dabei nur mit einer Fehler- oder Erfolgsmeldung zurück. - Mit
gpg --recv-keys 0xDEADBEEF 0xF00BA211(kurz:--recv) importiere ich direkt die öffentlichen Schlüssel mit den Schlüssel-IDs 0xDEADBEEF und 0xF00BA211. (Die Beispiele sind rein fiktiv.) Ist der zu empfangende Schlüssel bereits im Schlüsselbund, so wird der Schlüssel aktualisiert (neue oder widerrufene Benutzer-IDs, Signaturen, Unterschlüssel usw.). gpg --refresh-keys(kurz--refresh) aktualisiert alle importierten öffentlichen Schlüssel. Dies kann man auch auf bestimmte Schlüssel (analog zu den anderen Befehlen) eingrenzen. Ist ein zu aktualisierender Schlüssel nicht im Schlüsselbund enthalten, so wird er ignoriert.
Verschlüsseln, Entschlüsseln, Signieren
[Bearbeiten]Wenn man GnuPG hauptsächlich für E-Mails verwenden will, dann sollte man sich mit der Dokumentation seines MUAs (E-Mailprogramm) vertraut machen und im entsprechenden Kapitel auf diesem Wikibook ergänzen. Von mutt bis evolution unterstützen die meisten MUAs GnuPG direkt, über eine Erweiterung oder über ein Hilfsprogramm. Meistens ist es ganz einfach mit zwei Tasten oder einem Mausklick erledigt, und schon ist eine E-Mail verschlüsselt (und signiert). Leider existieren zu viele MUAs, um hier auf alle einzugehen und es wäre ungerecht, es nur für mutt zu beschreiben. 
(Es sei nochmal auf das entsprechende Kapitel hier im Wikibook verwiesen.)
Will man vertrauliche Daten nicht per E-Mail, sondern z. B. per CD-R an den Empfänger weitergeben, so kann man Dateien auch direkt verschlüsseln:
gpg --output Datei.gpg --recipient Empfänger --encrypt Datei
Oder kurz:
gpg -o Datei.gpg -r Empfänger -e Datei
Die Endung .gpg ist natürlich nicht zwingend, sondern nur ein Vorschlag. Die armor-Einstellung lohnt bei großen über CD-R weitergegebenen Dateien nicht mehr, da eine binäre Speicherung auf CD-R kein Problem darstellt (im Gegensatz zur binären Übertragung per E-Mail) und die Datei nur unnötig größer wird. (ASCII-Verpackung ist durchschnittlich 4/3 mal so groß wie das 8-Bit-Original.) Steht also armor in Ihrer Konfiguration, so können Sie diese mit der Option --no-armor deaktivieren.
Eine rekursive Verschlüsselung von Verzeichnissen ist seitens GnuPG nicht möglich. Hier sollte man entweder
- die Dateien in ein Archiv (z. B.
tar) packen und dieses dann verschlüsseln, z. B. packt und verschlüsselt der Befehltar -c /home/michael/*|gpg -r Empfänger -e -o /tmp/home.tar.cryptalle Dateien des Verzeichnisses /home/michael in die Datei /tmp/home.tar.crypt. Der Befehlgpg -d /tmp/home.tar.crypt |tar -xvf -stellt das Verzeichnis aus der verschlüsselten Datei wieder her. Oder - die Dateien einzeln verschlüsseln mit
find Verzeichnis -type f -exec gpg -o {}.gpg -r Empfänger -e {} \;odergpg -r Empfänger --encrypt-files Verzeichnis/*(Vorsicht mit Platzhaltern bei Unterverzeichnissen!) mitarmorbekommen die verschlüsselten Dateien ein.asc-Suffix, und ohne wird.gpgan den Dateinamen angehängt. Die Originaldateien bleiben erhalten.
Wie weiter oben schon erwähnt, kann der Empfänger z. B. über seine E-Mailadresse, seinen Namen oder seine Schlüssel-ID angegeben werden.
Die Entschlüsselung erfolgt analog dazu mit:
gpg -o Datei -d Datei.gpg
-d kann der besseren Lesbarkeit wegen auch als --decrypt ausgeschrieben werden. Zum Entschlüsseln wird man nach seiner Passphrase gefragt, da gpg ja auf den geheimen Schlüssel zugreifen muss.
Pures Verschlüsseln reicht oft nicht, da die Daten ja auf dem Weg zum Empfänger trotzdem noch verändert werden können. Hier hilft das digitale Signieren der Nachricht. Mit gpg -o Datei.sig --sign Datei erstellt man eine Signatur für die Datei. Verschlüsseln und signieren zugleich funktioniert mit --sign --encrypt Datei oder kurz mit -s -e Datei. Die Signatur einer nur signierten und nicht verschlüsselten Datei überprüft man mit gpg --verify Datei.gpg auf Unversehrtheit („Integrität“). Die Signatur einer signierten und verschlüsselten Datei wird beim Entschlüsseln (gpg --decrypt Datei.gpg) automatisch auf Unversehrtheit („Integrität“) geprüft. Wenn das Entschlüsseln auch ohne Signatur-Überprüfung möglich sein soll, dann verschlüsselt man zuerst die Datei und generiert dann eine abgespaltene Signatur, mit --detach-sign (kurz: -b) statt --sign. Die mit -o angegebene Ausgabedatei ist hierbei die Datei, die die Signatur enthält. Empfohlener Dateisuffix ist .sig oder auch .asc. -b lässt sich nicht sinnvoll mit -e kombinieren. Um den Unterschied zwischen -s und -b zu zeigen, ein Beispiel:
/tmp$ gpg --no-armor -s foo.tar.gz
[...]
/tmp$ gpg --no-armor -b foo.tar.gz
[...]
/tmp$ wc -c foo*
518144 foo.tar.gz
519374 foo.tar.gz.gpg
65 foo.tar.gz.sig
1037583 total
/tmp$ rm foo.tar.gz
/tmp$ gpg --verify foo.tar.gz.gpg
gpg: Signature made Mon Feb 14 03:23:14 2005 CET using DSA key ID FCC5040F
gpg: Good signature from "Stephan Beyer <s-beyer@gmx.net>"
[...]
/tmp$ gpg --verify foo.tar.gz.sig
gpg: no signed data
gpg: can't hash datafile: file open error
foo.tar.gz.gpg enthält foo.tar.gz und dessen Signatur; foo.tar.gz.sig enthält nur die Signatur. Nach dem Löschen der Originaldatei kann die abgespaltene Signatur nicht mehr zum Überprüfen genutzt werden. Abgespaltene Signaturen nimmt man immer, wenn man Dateien zum Download anbietet und diese signieren möchte.
- Doch Vorsicht: Zusatzwissen! was passiert beim Signieren überhaupt? Digitale Signaturen sind eigentlich nur mit asymmetrischen Verfahren so zu erreichen, dass sie den Ansprüchen an Unterschriften gerecht werden. Zuerst wird von der Datei ein nicht umkehrbarer Hashwert über eine Einweg-Hashfunktion wie z. B. MD5 (gilt mittlerweile als unsicher) oder SHA* (SHA-1 ebenfalls) ermittelt. Salopp gesagt: Bilden Sie von einer 10-stelligen Zahl die Quersumme das ist einfach und dann versuchen Sie mal, aus ihrer Quersumme die 10-stellige Ausgangszahl zu ermitteln (ohne sie zu kennen) da wird es schon schwerer... Das leistet im Grunde die Hashfunktion. Der Hashwert wird daraufhin mit Hilfe des geheimen Schlüssels verschlüsselt. Beim Überprüfen der Signatur wird sie mit dem öffentlichen Schlüssel entschlüsselt. Man erhält den Hashwert. Die erfolgreiche Entschlüsselung mit dem öffentlichen Schlüssel ist Beweis, dass der Hash-Wert vom privaten Schlüssel verschlüsselt wurde. Dieser Beweis ist die digitale Unterschrift des Hash-Wertes. Von der Datei wird ebenfalls der Hashwert berechnet. Die beiden Hashwerte werden verglichen. Sind sie identisch, dann ist bei guter Hashfunktion die Wahrscheinlichkeit sehr groß, dass die erhaltene Datei der Originaldatei entspricht. Gibt es Abweichungen, so ist eindeutig belegt, dass die Datei verändert wurde.
- Die Hashfunktion ist notwendig. Würde man sie weglassen und direkt die Datei zum Signieren verschlüsseln, so hätte man das Problem, dass ein Angreifer über die Signatur Rückschlüsse auf ihren geheimen Schlüssel machen kann. Daher sollte auch der Hashwert möglichst nicht umkehrbar sein. Außerdem geht das verschlüsseln des Hashwertes um einiges schneller, als riesige Dokumente zu verschlüsseln.
Die Verhältnisse der Schlüssel sind also bei der digitalen Unterschrift umgekehrt als beim entschlüsseln: Digitale Unterschrift: Privater schlüssel verschlüsselt. Öffentlicher Schlüssel entschlüsselt.
Analog zu dem weiter oben erwähnten --encrypt-files (um mehrere Dateien zu verschlüsseln) gibt es auch --decrypt-files (entschlüsseln), --verify-files (Signaturen überprüfen) und irgendwann vielleicht auch Entsprechendes für -s und -b, was in Version 1.4.0 leider noch nicht möglich ist.
Beim Verschlüsseln sollte man wissen, dass die verschlüsselten Dateien bzw. E-Mails wirklich nur der Empfänger entschlüsseln kann, also, wenn man dieser nicht ist, kann man sie auch selbst nicht mehr lesen (z. B. eine Kopie einer gesendeten verschlüsselten Mail wird lokal archiviert, und man will diese später wieder lesen). Um das zu ändern, ergänzt man encrypt-to eigeneID in der ~/.gnupg/gpg.conf. So wird zusätzlich der eigene öffentliche Schlüssel zum Verschlüsseln mitverwendet. Möchte man darauf in Ausnahmefällen wieder verzichten, so gibt man die Option --no-encrypt-to an.
Möchte man Daten gar nicht weitergeben, sondern nur vor fremden Zugriffen schützen, so kann man GnuPG auch symmetrisch verschlüsseln lassen. Dazu dient das gpg-Kommando --symmetric (kurz: -c).
~$ gpg -o gnupg.wml.gpg -c gnupg.wml Geben Sie die Passphrase ein:
Als Passphrase wird natürlich nicht die Passphrase des geheimen Schlüssels verlangt, sondern eine frei erdachte, die nur für dieses eine Dokument gelten sollte. Entschlüsselt wird, wie auch bei der asymmetrischen Verschlüsselung, mit -d, nur dass eben die dokumentspezifische Passphrase angegeben werden muss.
Voreingestellter Verschlüsselungsalgorithmus für -c ist übrigens CAST5. Mit der Option --cipher-algo Algorithmus darf man einen anderen Algorithmus wählen. Meiner GnuPG-Version stehen zum Beispiel 3DES, BLOWFISH, AES, AES192, AES256 und TWOFISH als Alternativen zur Verfügung. Diese Information erhält man mit gpg --version.
