Geduld zahlt sich aus! Nach theoretischen Grundlagen, Verifikationsexkurs und sicherer Einrichtung können wir jetzt endlich die ersten Früchte unserer Arbeit ernten: Nigelnagelneue PGP-Schlüssel! Aber auch hier steckt der Teufel natürlich im Detail: Schlüssel ist nicht gleich Schlüssel. Gibt es eigentlich anonyme Schlüssel? Und gilt bei den Schlüsseln: Doppelt so lang ist auch doppelt so sicher? Die Antworten gibt es hier im 4. Teil.
Dieser Artikel ist Teil der Serie "OpenPGP im Berufsalltag". Du möchtest auch die anderen Artikel lesen? Hier geht es zur Übersicht.
Schlüssel zurückziehen
Einen einmal veröffentlichten Schlüssel kann man nicht mehr von einem Schlüsselserver löschen. Dies ist besonders störend für den Fall, dass man einen Schlüssel nicht mehr benutzen kann, oder dieser gebrochen (kompromittiert) wurde.
In beiden Fällen müsste man einen neuen Schlüssel hochladen. Aber wie sollen andere Nutzer fortan wissen, welcher der aktuelle Schlüssel ist? Aus diesem Grund gilt zunächst: Man sollte darauf achten, immer nur genau einen Schlüssel zu veröffentlichen und auch nur genau diesen zu nutzen.
Im Fall der Fälle sollte man vor dem Hochladen eines neuen Schlüssels den alten zurückziehen (engl. revoke). Ein zurückgezogener Schlüssel wird entsprechend gekennzeichnet (engl. revoked key). Im Laufe der Zeit sammeln sich so einige zurückgezogene Schlüssel an, aber es gibt immer nur genau einen, der nicht zurückgezogen ist.
Das Zurückziehen hat den unangenehmen Nachteil, dass alle mit diesem Schlüssel signierten und verschlüsselten Daten sozusagen ebenfalls zurückgezogen sind, d. h. sie sind mindestens nicht mehr vertrauenswürdig. Dies gilt insbesondere für mit diesem Schlüssel erstellte Signaturen für andere Schlüssel. Dadurch wird das durch gegenseitiges Schlüsselsignieren errichtete Web of Trust geschwächt.
Haupt- und Unterschlüssel
Um solche und ähnlich unangenehme Effekte abzuschwächen, gibt es im OpenPGP-Standard neben normalen Schlüsseln auch sogenannte Unterschlüssel. Mit deren Hilfe kann man die Aufgaben Signieren (Sign), Verschlüsseln (Encrypt) und Authentifizieren (Authenticate) jeweils auf genau einen Unterschlüssel eines Hauptschlüssels verteilen. Die Schlüssel sind technisch immer an ihren Hauptschlüssel gebunden und können nicht losgelöst von diesem existieren. Dem Hauptschlüssel selbst bleibt die wichtige Aufgabe Zertifizieren (Certify) vorbehalten.
Warum wird es dadurch besser? Der Trick ist, dass für die alltäglichen Aufgaben nur die Unterschlüssel gebraucht werden. Der Hauptschlüssel selbst muss zum Signieren und Verschlüsseln nicht im Schlüsselring sein. Damit ist es möglich, ihn gesichert vor unbefugtem Zugriff, z. B. auf einem USB-Stick, aufzubewahren.
Ein Angreifer muss jetzt mehr Schlüssel brechen, um Signaturen und Verschlüsselung zu kompromittieren. Zusätzlich kann man jetzt Unterschlüssel einzeln zurückziehen, was das Risiko einer komplett nicht länger vertrauenswürdigen Korrespondenz verringert. Ein zurückgezogener Unterschlüssel kann durch einen neuen ersetzt werden, ohne den Hauptschlüssel zurückziehen oder ändern zu müssen.
Hauptschlüssel generieren
Aus den genannten Gründen werden wir also einen Hauptschlüssel und drei Unterschlüssel generieren. Dabei orientiere ich mich an dem sehr guten Artikel The Almost Perfect Key Pair. Wir legen also mal los:
Schlüsselalgorithmus
# Generate master key with all custom options activated gpg --expert --full-gen-key Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key
Als Erstes werden wir gefragt, welcher Kryptoalgorithmus für den Schlüssel genutzt werden soll. Aber halt! Geht Public Key nicht immer mit RSA? Offenbar nicht! Prinzipiell sind alle bekannten asymmetrischen Kryptoverfahren denkbar. Im Standard selbst ist das bekannte RSA, sowie DSA und Elgamal beschrieben. Optional - und von OpenPGP seit einiger Zeit ebenso unterstützt - ist ECC, die sogenannte Elliptic Curve Cryptography. Gerade Letzteres wird neuerdings hinsichtlich der (zukünftigen) Sicherheit empfohlen. Leider gibt es dafür aber noch keine weit verbreitete Unterstützung, weshalb die Chance hoch ist, dass andere nicht mit dem öffentlichen Schlüssel arbeiten können.
Wir werden Option 8 (RSA) wählen, weil...
- ...es weit verbreitet und gut verstanden, damit also maximal kompatibel zur Außenwelt ist.
- ...Sicherheitstoken wie der sogenannte Yubikey im Moment vor allem RSA unterstützen.
Es geht also weiter:
Schlüsselaufgaben
Your selection? 8 Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished
Hier kommt der entscheidende Moment. Wir werden alle mit diesem Schlüssel erlaubten Aktionen entfernen, bis auf Certify. Damit wird der Hauptschlüssel tatsächlich nur zum Beglaubigen taugen. Wir wählen also:
Current allowed actions: Sign Certify Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? s Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Certify Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? e Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Certify (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Schlüssellänge
Wie lang ist lang genug? Die RSA-Gretchenfrage. Generell gilt: Je länger, desto besser. Aber: Im Vergleich zwischen unterschiedlichen Kryptoverfahren bedeutet länger nicht automatisch besser, denn unterschiedliche Verfahren benötigen unterschiedliche Schlüssellängen. AES kommt mit 256 Bit aus, für DSA können 1024 Bit ausreichend sein usw.
Die Sicherheit von RSA beruht auf der Annahme, dass die Zerlegung einer großen Zahl in ihre Primfaktoren nur schwer oder oder gar nicht in ausreichend kurzer Zeit möglich ist. Die Schlüssellänge bestimmt die Größe dieser Zahl und hat damit direkten Einfluss auf die Sicherheit.
Also einfach 4096 Bit wählen und es ist für immer Ruhe? Nicht ganz! Für die Wahl der Schlüssellänge spielt auch die Art der späteren Nutzung eine Rolle. Ist bspw. die Nutzung auf einem Security-Token, wie z. B. einer OpenPGP-Card, geplant, kann die unterstützte Schlüssellänge durch Hardwarelimitierung begrenzt sein.
Der Yubico-Blog beleuchtet diese Zusammenhänge leicht verständlich und äußerst informativ. Unter'm Strich bedeutet das:
- 2048 Bit ist voraussichtlich bis 2030 okay für den täglichen Bedarf.
- 4096 Bit können exponentiell mehr Sicherheit bieten, verdoppeln aber Speicher- und Berechnungszeitbedarf. Ihr Einsatz muss also in Verbindung mit Punkt 1 ökonomisch abgewogen werden.
- RSA-Schlüssel werden alle paar Jahre ausgetauscht, die Wahl der Schlüssellänge ist also keine Entscheidung für alle Ewigkeit.
- Sicherheitshardware, wie z. B. der Yubikey NEO, kann Einschränkungen unterliegen, die die Verwendung von 4096 Bit langen Schlüsseln unmöglich machen.
- Die Verwendung von unnötig langen Schlüsseln auf eingebetteten Geräten erhöht Batterieverbrauch und Berechnungszeiten auf potenziell nicht akzeptable Werte.
Aus diesen Gründen wählen wir für den Hauptschlüssel 4096 Bit. Er wird nicht täglich benötigt und muss nicht auf Sicherheitshardware gespeichert sein. Die Unterschlüssel werden dagegen 2048 Bit lang. Das bietet einen guten Kompromiss aus Sicherheit und Ressourcenverbrauch auf eingebetteter Sicherheitshardware. Die generierten Unterschlüssel können wir damit später auf einer OpenPGP-Card, wie dem Yubikey NEO, speichern. Sollte eine solche Nutzung für die Schlüssel nicht geplant sein, kann man auch für die Unterschlüssel 4096 Bit wählen.
Update September 2018: Mittlerweile hat Yubico die 5. Serie der YubiKeys veröffentlicht. Der NEO heißt jetzt YubiKey 5 NFC und unterstützt RSA 4096. Sollte man den Einsatz der Schlüssel auf diesem Gerät planen, kann man auch für die Unterschlüssel 4096 bit Länge einstellen. Die prinzipiellen Nachteile eines längeren Schlüssels gelten natürlich immer noch. Die tatsächlichen Einbußen dürften sich aber in der Praxis kaum auswirken.
Update Mai 2021: Die neueste Firmware des Yubikey 5 unterstützt auch neueste ECC-Verfahren, darunter p384 und curve25519. Deren Verwendung scheint aber wegen der geringeren Verbreitung noch nicht so komfortabel zu sein, wie die von RSA. Details dazu gibt es bei Yubico.
Gültigkeitsdauer
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Neben dem Zurückziehen von Schlüsseln gibt es noch einen zweiten Mechanismus, um Schlüssel gegen Missbrauch zu schützen: den automatischen Gültigkeitsablauf. Signaturen und verschlüsselte Dokumente, die nach dem Ablauf eines Schlüssels erzeugt wurden, sollte nicht mehr vertraut werden. Programme wie Enigmail werden entsprechende Warnungen anzeigen. Die Gültigkeit kann regelmäßig vom Besitzer des Schlüssels verlängert werden, solange dieser noch die Kontrolle über ihn hat.
Die Wahl der Länge ist wie so oft eine Abwägung zwischen Sicherheit und Bequemlichkeit. Kurze Gültigkeitsdauern muss man zu oft verlängern. Lange Gültigkeitsdauern öffnen zuviel Angriffsfläche für Missbrauch.
Ich persönlich würde 1 Jahr wählen.
User-ID setzen
Key is valid for? (0) 1y
Key expires at 06/25/19 11:36:56 Mitteleuropäische Sommerzeit
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: Jan Mosig
Email address: jan.mosig@itemis.de
Comment:
You selected this USER-ID:
"Jan Mosig <jan.mosig@itemis.de>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
Jeder Schlüssel ist an eine USER-ID gebunden. Das ist ein Name und eine E-Mail-Adresse. Dabei ist es unerheblich, ob Name und Adresse zusammenpassen bzw. tatsächlich existieren. Man kann also sowohl "offizielle" Schlüssel, als auch anonyme Schlüssel generieren, je nach Bedarf.
Leider kann man sich so auch als jemand anderes ausgeben. Aus diesem Grund ist es wichtig, importierte Schlüssel auf ihre Gültigkeit und ihre Glaubhaftigkeit zu prüfen, beispielsweise indem man die Signaturen auf dem Schlüssel prüft, oder den echten Herausgeber nach der Schlüssel-ID fragt und diese vergleicht.
Jetzt fehlt nur noch ein letzter Schritt.
Passphrase
We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.
Vor der eigentlichen Generierung wird noch die sogenannte Passphrase abgefragt. Dabei handelt es sich um eine Art Passwort, mit dem der private Schlüssel zusätzlich verschlüsselt wird. Ohne Passphrase kann man also nicht entschlüsseln und nicht signieren, außerdem private Schlüssel nicht bearbeiten, exportieren oder löschen. Die Passphrase gilt auch für die Unterschlüssel.
Es gelten hier die üblichen Hinweise bei der Wahl eines Passworts. Ein gutes Passwort muss aber weder schwer zu merken sein, noch aus zufälligen Buchstaben, Zahlen und Sonderzeichen bestehen. Im Wesentlichen muss es einfach nur ausreichend lang sein. Lange Passwörter werden im Englischen Passphrase ("kurzer Satz") genannt, daher die Bezeichnung.
Ergebnis
Man erhält:
gpg: key 0x3D5C6DBB1C061833 marked as ultimately trusted
gpg: revocation certificate stored as 'C:/Users/mosig_user/.gnupg/openpgp-revocs.d\A3C1B44DEC45C33488A6C4C03D5C6DBB1C061833.rev'
public and secret key created and signed.
pub rsa4096/0x3D5C6DBB1C061833 2018-06-25 [C] [expires: 2019-06-25]
Key fingerprint = A3C1 B44D EC45 C334 88A6 C4C0 3D5C 6DBB 1C06 1833
uid Jan Mosig <jan.mosig@itemis.de>
- Der Schlüssel gilt als absolut vertrauenswürdig, es ist ja der eigene.
- Die Datei
A3C1B44DEC45C33488A6C4C03D5C6DBB1C061833.reventhält ein sogenanntes Widerrufszertifikat, das zum Zurückziehen des Schlüssel gebraucht wird. Bei Verlust ist kein Zurückziehen des Schlüssel mehr möglich! - Der Schlüssel hat auch einen Namen, die sogenannnte (long) ID:
0x3D5C6DBB1C061833. - Einige Krypto-Aufgaben benötigen den sogenannten Fingerprint (engl. Fingerabdruck). Das ist ein Hash-Code des eigentlichen 4096 Bit langen Schlüssels:
A3C1 B44D EC45 C334 88A6 C4C0 3D5C 6DBB 1C06 1833.
Damit haben wir den Hauptschlüssel generiert. Jetzt wäre ein guter Zeitpunkt, sich die ID (3D5C6DBB1C061833 in diesem Fall) aufzuschreiben. Sie wird in einigen der folgenden Schritte noch benötigt. Weiter geht es mit den Unterschlüsseln.
Unterschlüssel generieren
Da der Hauptschlüssel nur für das Beglaubigen freigeschalten ist, benötigen wir einen Unterschlüssel für jede weitere Aufgabe, also insgesamt drei:
- Encrypt
- Sign
- Autenticate
Unterschlüssel können über den Bearbeitungsmodus für Hauptschlüssel hinzugefügt werden:
gpg --expert --edit-key 3D5C6DBB1C061833
gpg (GnuPG) 2.2.7; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa4096/0x3D5C6DBB1C061833
created: 2018-06-25 expires: 2019-06-25 usage: C
trust: ultimate validity: ultimate
[ultimate] (1). Jan Mosig <jan.mosig@itemis.de>
gpg>
Wir landen in der sogenannten gpg-Shell, sozusagen eine Unterkonsole der Hauptkonsole. Mit ? können wir uns die verfügbaren Befehle anzeigen lassen. Wir werden addkey wählen. Damit wird ein Schlüsselgeneriervorgang gestartet, der ähnlich zu dem des Hauptschlüssels ist:
gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 8 Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished
Wir wählen natürlich den Kryptoalgorithmus des Hauptschlüssels (RSA) und kommen zur Auswahl der Schlüsselaufgaben. Jeder Schlüssel soll genau eine Aufgabe haben dürfen. Die Eingabe von S schaltet z. B. die Aufgabe Signieren ein und aus. Für den ersten Schlüssel werden wir nur Verschlüsseln (Encrypt) aktiviert lassen:
Your selection? s
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 1y
Key expires at 06/25/19 12:37:37 Mitteleuropõische Sommerzeit
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa4096/0x3D5C6DBB1C061833
created: 2018-06-25 expires: 2019-06-25 usage: C
trust: ultimate validity: ultimate
ssb rsa2048/
created: 2018-06-25 expires: 2019-06-25 usage: E
[ultimate] (1). Jan Mosig <jan.mosig@itemis.de>
Die anderen Werte wählen wir genau wie beim Hauptschlüssel, außer der Schlüssellänge! Aus den genannten Gründen wählen wir hier 2048 Bit. Wir erhalten einen Unterschlüssel mit ID 0xAB69A2DFCB50B517, der nur zum Verschlüsseln taugt.
Wenn wir den Vorgang noch 2x wiederholen und jeweils Signieren und Authentifizieren wählen, erhalten wir:
sec rsa4096/0x3D5C6DBB1C061833
created: 2018-06-25 expires: 2019-06-25 usage: C
trust: ultimate validity: ultimate
ssb rsa2048/0xAB69A2DFCB50B517
created: 2018-06-25 expires: 2019-06-25 usage: E
ssb rsa2048/0xC5CED131C6D9CF8C
created: 2018-06-25 expires: 2019-06-25 usage: S
ssb rsa2048/0xB65305FC2E9BBE54
created: 2018-06-25 expires: 2019-06-25 usage: A
[ultimate] (1). Jan Mosig <jan.mosig@itemis.de>
gpg> save #Store and quit
Das Schlüsselsetup ist jetzt komplett und funktionstüchtig. Es gibt allerdings noch etwas zu tun, um die Sicherheit signifikant zu steigern.
Backup anlegen
Momentan existieren die Schlüssel nur im privaten Keyring. Sollte dieser verloren gehen oder zerstört werden, sind die Schlüssel und damit alle verschlüsselten Inhalte verloren. Aus diesem Grund sollte man stets ein Backup anfertigen und an einem sicheren Ort aufbewahren.
Prinzipiell würde es reichen, einfach das gpg-Home-Verzeichnis zu sichern. Wir werden aber die Schlüssel einzeln exportieren. Damit erhält man weniger Ballast und ist vor allem mobil. Die Schlüssel könnten also auch auf einem anderen Gerät importiert werden. Das geht so:
# Generate backup copy of revocation certificate gpg --output 3D5C6DBB1C061833.rev --gen-revoke 3D5C6DBB1C061833 # Export public master key gpg --export --armor 3D5C6DBB1C061833 > 3D5C6DBB1C061833.pub.asc # Export private master key gpg --export-secret-keys --armor 3D5C6DBB1C061833 > 3D5C6DBB1C061833.priv.asc # Export private subkeys. There are no public subkeys. gpg --export-secret-subkeys --armor 3D5C6DBB1C061833 > 3D5C6DBB1C061833.sub_priv.asc
Damit erhält man vier Dateien, die man z. B. in einer verschlüsselten zip-Datei speichern und auf einem USB-Stick sichern kann.
Hauptschlüssel entfernen
Jetzt, wo wir ein Backup haben, können wir noch einen weiteren Schritt wagen: Den Hauptschlüssel aus dem Schlüsselring zu entfernen. Vorteil: Er kann so nicht kompromittiert werden. Nachteil: Alle Operation, die eine Beglaubigung erfordern, beispielsweise fremde Schlüssel signieren, erfordern einen Reimport des Schlüssels. Dies kommt aber in der täglichen Arbeit eher selten und wenn, dann verstärkt zu Beginn vor, wenn man noch nicht alle Schlüssel seiner regelmäßigen Kommunikationspartner beglaubigt hat.
Die folgende Prozedur löscht den Hauptschlüssel aus dem Schlüsselring. Achtung: Ohne Backup des Haupt- und der Unterschlüssel sind diese unwiederbringlich verloren!
# Delete master and sub keys, will request one approval per key (4 approvals total). gpg --delete-secret-key 3D5C6DBB1C061833 gpg (GnuPG) 2.2.7; Copyright (C) 2018 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. sec rsa4096/0x3D5C6DBB1C061833 2018-06-25 Jan Mosig <jan.mosig@itemis.de> Delete this key from the keyring? (y/N) y This is a secret key! - really delete? (y/N) y # Now reimport the subkeys only gpg --import 3D5C6DBB1C061833.sub_priv.asc gpg: key 0x3D5C6DBB1C061833: "Jan Mosig <jan.mosig@itemis.de>" not changed gpg: To migrate 'secring.gpg', with each smartcard, run: gpg --card-status gpg: key 0x3D5C6DBB1C061833: secret key imported gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1
Wenn wir uns jetzt den privaten Schlüsselring ansehen, können wir prüfen, ob es funktioniert hat.
Schlüsselring ansehen
Wie in Teil 1 beschrieben, kommen Schlüssel bei PGP immer paarweise: Es gibt einen öffentlichen Teil (Public Key) und einen privaten Teil (Private Key). Alle bekannten Schlüssel werden in einem sogenannten Schlüsselring gespeichert. Auch dieser ist zweigeteilt. Mit folgenden Befehlen kann man sich die zwei Teile ansehen:
# View public key ring gpg --list-keys # Or short version gpg -k
# View private key ring gpg --list-secret-keys # Or short version gpg -K
Unser private Schlüsselring sollte so aussehen:
gpg -K
C:/Users/mosig_user/.gnupg/pubring.kbx
--------------------------------------
sec# rsa4096/0x3D5C6DBB1C061833 2018-06-25 [C] [expires: 2019-06-25]
Key fingerprint = A3C1 B44D EC45 C334 88A6 C4C0 3D5C 6DBB 1C06 1833
uid [ultimate] Jan Mosig <jan.mosig@itemis.de>
ssb rsa2048/0xAB69A2DFCB50B517 2018-06-25 [E] [expires: 2019-06-25]
ssb rsa2048/0xC5CED131C6D9CF8C 2018-06-25 [S] [expires: 2019-06-25]
ssb rsa2048/0xB65305FC2E9BBE54 2018-06-25 [A] [expires: 2019-06-25]
Perfekt! So sollte es aussehen. Der oberste Schlüssel (sec) ist der 4096 bittige Masterkey. Die Raute (#) zeigt an, dass dieser nicht im Schlüsselring vorhanden ist. Darunter sehen wir die drei 2048 bittigen Unterschlüssel (ssb), jeweils einen für Encrypt, Sign und Authenticate.
Damit wären wir fertig. Die Schlüssel können so für Verschlüsselung und Signatur genutzt werden. Die Auswahl des korrekten Schlüssels für den jeweiligen Task führt gpg automatisch durch.
Im nächsten Teil werfen wir einen Blick auf die Nutzung der Schlüssel mit Thunderbird und Enigmail zur täglichen Verschlüsselung und Signatur von E-Mails.
Kommentare