Dass das Internet systembedingt unsicher ist, hat sich in aller Regel herumgesprochen. Daten durchlaufen von der Quelle bis zum Ziel zahlreiche Server und Systeme, an denen die Daten, abgegriffen und/oder manipuliert werden können. Persönliche und vertrauliche Daten können so einfach Dritten in die Hände fallen, die mit grosser krimineller Energie versuchen an diese Daten zu kommen.

Inwieweit staatliche Stellen den Datenverkehr abhören, protokollieren und abgreifen und zu manipulieren bzw. zensieren versuchen, weiss

1. keiner so genau und
2. was mit den gewonnen Daten angestellt wird, wird sich niemand öffentlich sagen trauen.

Tja, das war Stand der Dinge vor 2013, denn was bisher in den Bereich der Spekulation fiel, findet nun Bestätigung durch die Erkenntnisse des Whistleblowers Edward Snowden zu den Projekten PRISM aus den USA und TEMPORA aus England. Seit Jahren werden unschuldige Bürgerinnen und Bürger von staatlichen Institutionen unter Generalverdacht gestellt und überwacht! Regierungen scheuen keinen Aufwand um in die Privatsphäre unschuldiger Bürgerinnen und Bürger einzudringen, Daten auszulesen und auszuwerten!

Was lernen wir aus dieser Tatsache? Unsere Kommunikation ist nach besten Wissen und Gewissen, so zu gestalten, damit andere unsere Daten nicht mitlesen und manipulieren können. Ferner ist sicherzustellen, dass Empfänger vertrauen können, dass Informationen tatsächlich von dem versandt wurden, von dem wir glauben, diese zu bekommen.

Hierzu greifen wir auf asymmetrische Verschlüsselungstechniken zurück, die wir entweder mit OpenPGP oder S/MIME realisieren können.

Für die vertrauliche und gesicherte Kommunikation mit mir, einfach PGP oder S/MIME nutzen! Mein S/MIME-Userzertifikat und auch mein mein PGP-Key kann man z.B. einfach auf einen der folgenden Seiten

• mein SKS-Keyserver
• https://certbox.org/
• https://www.globaltrustpoint.com/

auffindbar. Einfach auf einem der beiden Seiten nach meiner eMail-Adresse michael@nausch.org suchen!

Das ganze Thema wurde bei mehreren Infoabenden/Stammtischen der Piratenpartei am 02.12.2009, 04.07.2013 sowie am 05.09.2013 einem interessierten Teilnehmerkreis erklärt (Quellen in einer höheren Auflösung gibt es beim Author auf Anfrage).

Aktuell überarbeitete Version 3: KV Ebersbergversion

Bei beiden asymetrischen Verschlüselungsverfahren, ob nun OpenPGP oder S/MIME, sollte man grundsätzlich das Verfahren verinnerlichen. Was ist nun das Prinzip einer asymetrischen Verschlüsselung und wie unterscheidet es sich von der sysmetrischen?

Bei einer symetrischen Verschlüsselung haben beide Kommunikationspartner den gleichen Schlüssel und können mit Hilfe dieses Keys jeweils die Daten ver- und auch wieder entschlüsseln. Das ist nicht sonderlich rechenintensiv, hat aber einen entscheidenden Haken: Wie kommen beide Kommunikationspartner an den Schlüssel? Auf dem gleichen Kommunikationsweg den Schlüssel zur Kommunikation auszutauschen ist nicht sonderlich intelligent - auch wenn z.B. ein großer Möchtegern-VoIP-Anlagenhersteller, dies genau so unsinnigerweise macht und meint, dass sei besonders toll ;) .

Im Gegensatz zur symetrischen Verschlüsselung nutzt die asymetrischen Verschlüsselung ein Schlüsselpaar aus zwei Teilen, einem privaten oder öffentlichen Schlüssel. Dabei ist es im Grunde egal, welcher Teil veröffentlich wird, Hauptsache der als privat definierte, wird entsprechend so behandelt und der Nutzer hält diesen mit allen Mitteln privat - sprich sein Eigentum und nur ihm zugänglich.

Diese beiden Schlüssel sind durch mathematische Eigenschaften so miteinander verwoben, dass gilt:

1. Was mit dem öffentlichen Schlüssel verschlüsselt wurde, ist nur mit dem privaten zu entschlüsseln.
2. Mit dem öffentlichen Schlüssel codierte Inhalte lassen sich mit dem öffentlichen Schlüssel nicht mehr entschlüsseln.
3. Daten die mit dem privaten Schlüssel codiert wurden, lassen sich mit dem öffentlichen Schlüssel öffnen. So kann eine Prüfsumme einer Nachricht mit dem privaten Schlüssel versehen werden. Der Empfänger kann dann die codierte Prüfsumme entschlüsseln und mit der eigenen erstellten Prüfsumme vergleichen und somit feststellen, ob die Daten manipuliert wurden. Man nennt dies auch Signieren.

Die Frage ist bei der ganzen Sache allerdings, wie können wir wissen, ob der öffentliche Schlüssel auch wirklich zu dem gehört, den wir meinen?

Bei dieser Gretchenfrage unterscheiden sich nun die beiden Verfahren OpenPGP und S/MIME. Bei OpenPGP verwendet man das sogenannte Web of Trust, bei dem sich die einzelnen Teilnehmer gegenseitig als vertrauenswürdige Kommunikationspartner einstufen. Dazu signieren Sie nach erfolgter Überprüfung mehrerer Daten, den öffentlichen Schlüssel des Kommunikationspartners, mit dem eigenen private Key. Darüber hinaus kann man auch anderen Teilnehmern soweit vertrauen, dass man von deren signierte Schlüssel als vertrauenswürdig akzeptiert. Eine genaue Beschreibung des Web of Trust findet man im übrigen bei Wikipedia. Beim alljährlichen VDR Camp finden unter anderem auch Keys Signing Sessions statt, deren Ablauf hier beschrieben ist.

Bei S/MIME sieht das etwas anders. Hier kommen X.509-Zertifikate zum Einsatz, wie man sie bei SSL-geschützten Webanwendungen her kennt. Genauso wie diese, werden S/MIME-Zertifikate von Trustcentern ausgestellt - wie z.B. CAcert. Ein solches Zertifikat entsteht, wenn das Trustcenter nach Überprüfung der Anmeldedaten den öffentlichen Schlüssel des Antragstellers mit dem privaten Schlüssel der Zertifizierungsstelle signiert. Der öffentliche Schlüssel, versehen mit dieser Signatur, bildet dann das X.509-Zertifikat.

Bei der Basisinstallation unseres Betriebssystems wir GnuPG bereits mit installiert, so dass wir uns um eine gesonderte Installation keine großen Gedanken machen müssen. Mittels rpm -iql könne wir ansehen, was uns GnuPG alles mitbringt und wo die einzelnen dateien abgespeichert wurden.

# rpm -iql gnupg
Name        : gnupg                        Relocations: (not relocatable)
Version     : 1.4.5                             Vendor: CentOS
...

...
Size        : 4696623                          License: GPL
Signature   : DSA/SHA1, Mo 09 Mär 2009 02:45:48 CET, Key ID a8a447dce8562897
URL         : http://www.gnupg.org/
Summary     : Ein GNU-Dienstprogramm für sichere Kommunikation und Datenspeicherung.
Description :
GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and
creating digital signatures. GnuPG has advanced key management
capabilities and is compliant with the proposed OpenPGP Internet
standard described in RFC2440. Since GnuPG doesn't use any patented
algorithm, it is not compatible with any version of PGP2 (PGP2.x uses
only IDEA for symmetric-key encryption, which is patented worldwide).
/usr/bin/gpg
/usr/bin/gpg-zip
/usr/bin/gpgsplit
/usr/bin/gpgv
/usr/bin/lspgpot
/usr/lib/gnupg
/usr/lib/gnupg/gpgkeys_curl
/usr/lib/gnupg/gpgkeys_finger
/usr/lib/gnupg/gpgkeys_hkp
/usr/lib/gnupg/gpgkeys_ldap
/usr/share/doc/gnupg-1.4.5
/usr/share/doc/gnupg-1.4.5/AUTHORS
/usr/share/doc/gnupg-1.4.5/BUGS
/usr/share/doc/gnupg-1.4.5/COPYING
/usr/share/doc/gnupg-1.4.5/ChangeLog
/usr/share/doc/gnupg-1.4.5/DETAILS
/usr/share/doc/gnupg-1.4.5/HACKING
/usr/share/doc/gnupg-1.4.5/INSTALL
/usr/share/doc/gnupg-1.4.5/NEWS
/usr/share/doc/gnupg-1.4.5/OpenPGP
/usr/share/doc/gnupg-1.4.5/PROJECTS
/usr/share/doc/gnupg-1.4.5/README
/usr/share/doc/gnupg-1.4.5/THANKS
/usr/share/doc/gnupg-1.4.5/TODO
/usr/share/doc/gnupg-1.4.5/samplekeys.asc
/usr/share/gnupg
/usr/share/gnupg/FAQ
/usr/share/gnupg/faq.html
/usr/share/gnupg/options.skel
/usr/share/info/gpg.info.gz
/usr/share/info/gpgv.info.gz
/usr/share/locale/be/LC_MESSAGES/gnupg.mo
/usr/share/locale/ca/LC_MESSAGES/gnupg.mo
/usr/share/locale/cs/LC_MESSAGES/gnupg.mo
/usr/share/locale/da/LC_MESSAGES/gnupg.mo
/usr/share/locale/de/LC_MESSAGES/gnupg.mo
/usr/share/locale/el/LC_MESSAGES/gnupg.mo
/usr/share/locale/en@boldquot/LC_MESSAGES/gnupg.mo
/usr/share/locale/en@quot/LC_MESSAGES/gnupg.mo
/usr/share/locale/eo/LC_MESSAGES/gnupg.mo
/usr/share/locale/es/LC_MESSAGES/gnupg.mo
/usr/share/locale/et/LC_MESSAGES/gnupg.mo
/usr/share/locale/fi/LC_MESSAGES/gnupg.mo
/usr/share/locale/fr/LC_MESSAGES/gnupg.mo
/usr/share/locale/gl/LC_MESSAGES/gnupg.mo
/usr/share/locale/hu/LC_MESSAGES/gnupg.mo
/usr/share/locale/id/LC_MESSAGES/gnupg.mo
/usr/share/locale/it/LC_MESSAGES/gnupg.mo
/usr/share/locale/ja/LC_MESSAGES/gnupg.mo
/usr/share/locale/nb/LC_MESSAGES/gnupg.mo
/usr/share/locale/pl/LC_MESSAGES/gnupg.mo
/usr/share/locale/pt/LC_MESSAGES/gnupg.mo
/usr/share/locale/pt_BR/LC_MESSAGES/gnupg.mo
/usr/share/locale/ro/LC_MESSAGES/gnupg.mo
/usr/share/locale/ru/LC_MESSAGES/gnupg.mo
/usr/share/locale/sk/LC_MESSAGES/gnupg.mo
/usr/share/locale/sv/LC_MESSAGES/gnupg.mo
/usr/share/locale/tr/LC_MESSAGES/gnupg.mo
/usr/share/locale/zh_CN/LC_MESSAGES/gnupg.mo
/usr/share/locale/zh_TW/LC_MESSAGES/gnupg.mo
/usr/share/man/man1/gpg.1.gz
/usr/share/man/man1/gpg.ru.1.gz
/usr/share/man/man1/gpgv.1.gz
/usr/share/man/man7/gnupg.7.gz

Im Zuge der Schlüsselgenerierung, kann der öffentliche Schlüssel auf einem Keyserver, z.B. http://keyserver.nausch.org hochgeladen werden.

Die Erzeugung des Schlüsselpaares wir mit dem Befehl gpg --gen-key gestartet. Die Fragen beantwortet man gemäß der eigenen Vorstellung(en)

$ gpg --gen-key
gpg (GnuPG) 1.4.5; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: Verzeichnis `/home/django/.gnupg' erzeugt
gpg: Neue Konfigurationsdatei `/home/django/.gnupg/gpg.conf' erstellt
gpg: WARNUNG: Optionen in `/home/django/.gnupg/gpg.conf' sind während dieses Laufes noch nicht wirksam
gpg: Schlüsselbund `/home/django/.gnupg/secring.gpg' erstellt
gpg: Schlüsselbund `/home/django/.gnupg/pubring.gpg' erstellt
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (1) DSA and Elgamal (default)
   (2) DSA (nur signieren/beglaubigen)
   (5) RSA (nur signieren/beglaubigen)
Ihre Auswahl? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 0
Schlüssel verfällt nie
Ist dies richtig? (j/N) j

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Ihr Name ("Vorname Nachname"): Michael Nausch
Email-Adresse: django@omni128.de
Kommentar: 
Sie haben diese User-ID gewählt:
    "Michael Nausch <django@omni128.de>"

Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden? F
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu schützen.

Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
.+++++++++++++++.+++++.++++++++++++++++++++.+++++++++++++++..+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.+++++.>+++++..................................+++++
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
+++++...+++++.++++++++++..++++++++++..++++++++++.++++++++++.+++++.......+++++.++++++++++...+++++.+++++++++++++++.+++++.++++++++++..+++++..++++++++++...........++++++++++.++++++++++..+++++..+++++.+++++++++++++++>+++++...+++++.++++++++++++++++++++.+++++..+++++.++++++++++>.+++++>...+++++.>+++++.........+++++^^^
gpg: /home/django/.gnupg/trustdb.gpg: trust-db erzeugt
gpg: key 0CC2A7BA marked as ultimately trusted
Öffentlichen und geheimen Schlüssel erzeugt und signiert.

gpg: "Trust-DB" wird überprüft
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   1024D/0CC2A7BA 2009-04-27
  Schl.-Fingerabdruck = A6FD 1BE7 6A94 4544 1073  BFDB 73E9 9A2A 0CC2 A7BA
uid                  Michael Nausch <django@omni128.de>
sub   4096g/8FE37004 2009-04-27

Nach der Erstellung der Erstellung des Schlüsselpaares befinden sich im Verzeichnis .gnupg zwei Dateien, nämlich secring.pgp und pubring.pgp.

 $ ll .gnupg/

insgesamt 32
-rw------- 1 django django 9207 27. Apr 21:55 gpg.conf
-rw------- 1 django django 1678 27. Apr 22:04 pubring.gpg
-rw------- 1 django django 1678 27. Apr 22:04 pubring.gpg~
-rw------- 1 django django  600 27. Apr 22:04 random_seed
-rw------- 1 django django 1842 27. Apr 22:04 secring.gpg
-rw------- 1 django django 1280 27. Apr 22:04 trustdb.gpg

Im ersten Schlüsselring secring.pgp befindet sich der oder die privaten Schlüssel und im pubring.pgp alle öffentlichen, auch die von Dritten. Verwendet man GnuPG zum ersten Mal, befindet sich in beiden Schlüsselringen nur jeweils ein Schlüssel. Den Inhalt des privaten Schlüsselringes erfährt man mittels gpg --list-secret-keys.

 $ gpg  --list-secret-keys

/home/django/.gnupg/secring.gpg
-------------------------------
sec   1024D/0CC2A7BA 2009-04-27
uid                  Michael Nausch <django@omni128.de>
ssb   4096g/8FE37004 2009-04-27

Der Inhalt des öffentlichen keyrings zeigt gpg --list-keys.

 $ gpg  --list-keys

/home/django/.gnupg/pubring.gpg
-------------------------------
pub   1024D/0CC2A7BA 2009-04-27
uid                  Michael Nausch <django@omni128.de>
sub   4096g/8FE37004 2009-04-27

Bei einem „produktiven Schlüsselring“ werden entsprechend alle Schlüssel im öffentlichen Schlüsselbund angezeigt:

 $  gpg  --list-keys

/home/bigchief/.gnupg/pubring.gpg
---------------------------------
pub   1024D/2384C849 2009-03-30
uid                  Michael Nausch <michael@nausch.org>
uid                  Michael Nausch (aka BigChief) <bigchief@omni128.de>
uid                  Michael Nausch (aka Django) <django@nausch.org>
sub   4096g/D239B202 2009-03-30

pub   1024D/81EBD929 2007-11-23
uid                  Sebastian Schubert (SpaceNet AG) <ssc@space.net>
sub   2048g/CC15DA69 2007-11-23

pub   1024D/0DE59D7A 2007-11-16
uid                  Thomas Keil <thomas@weblizards.de>
sub   4096g/C77D03BC 2007-11-16

pub   1024D/C3B26780 2007-11-11 [expires: 2011-11-10]
uid                  Peer Heinlein -- Heinlein Professional Linux Support GmbH <p.heinlein@heinlein-support.de>
sub   4096g/DE228890 2007-11-11 [expires: 2011-11-10]

pub   1024D/4C016DE0 2008-01-02
uid                  Marco Scholl (Email) <mail@marco-scholl.de>
uid                  Marco Scholl (Ubuntu-Launchpad) <ubuntu@marco-scholl.de>
uid                  [jpeg image of size 2556]
sub   2048g/38C3B14C 2008-01-02

pub   1024D/CBBEBF26 2008-07-30
uid                  Bernd Goetter (dh5is) <routerman@gmx.net>
uid                  [jpeg image of size 3176]
sub   2048g/E46E82C6 2008-07-30

pub   1024D/E9E5F528 2009-03-28 [expires: 2011-03-28]
uid                  Robert Fuhge <fuhge@web.de>
sub   2048g/31EC58B6 2009-03-28 [expires: 2011-03-28]

pub   2048D/DEA1DF01 2008-10-26
uid                  Dieter Hametner (for VDR related emails) <dh+vdr@gekrumbel.de>
uid                  Dieter Hametner (Dieter Hametner) <dh@gekrumbel.de>
sub   4096g/866FC4B5 2008-10-26

pub   1024D/FDB5AACC 2009-04-04 [expires: 2014-04-03]
uid                  Carsten Presser (cpresser) <c@rstenpresser.de>
sub   2048g/AEFC9365 2009-04-04 [expires: 2014-04-03]

pub   1024D/A2C9DB22 2002-10-12
uid                  Udo Richter <udo.richter@gmx.de>
uid                  Udo Richter <udo_richter@gmx.de>
sub   1024g/E0D6A337 2002-10-12

pub   1024D/AEDAA642 2008-03-03
uid                  Tobias Grimm <tobias.grimm@e-tobi.net>
uid                  Tobias Grimm <tg@e-tobi.net>
uid                  Tobias Grimm <vdr@e-tobi.net>
uid                  Tobias Grimm <etobi@debian.org>
uid                  Tobias Grimm <debian@e-tobi.net>
uid                  Tobias Grimm <tobias@e-tobi.net>
sub   2048g/5979DD9D 2008-03-03

Sollte ein Bösewicht die Datei secring.pgp mit dem privaten Schlüssel in seine Finger kriegen, kann er mit dem Schlüssel nur etwas anfangen, wenn er dessen Passphrase kennen sollte. Sollte man jedoch in die Bredullie kommen, einen Schlüssel für ungültig zu erklären, da z.B. die Festplatte abgeraucht ist, oder man schlichtweg die Passphrase vergessen hat, so muss man entsprechend vorbereitet sein.

Hierzu erstellen wir uns nun ein Revocation Certificate¹⁾. Da wir hierzu den privaten Schlüssel, wie auch die Passphrase benötigen, erklärt, warum wir uns genau jetzt darüber Gedanken machen (müssen). Dieses Revocation Certificate muss an einem besonderen streng geheimen Ort aufbewart werden, da damit könnte ein Angreifer, den Key seines Opfers unwiederbringlich zurückziehen und dies ohne jegliche weitere Sicherung oder Passphraseabfrage. Wir Schreiben das Zertifikat also ab!

O.K. erst einmal wird mit gpg --gen-revoke key-ID das Zertifikat erzeugt. Zuerst ermitteln wir uns aber die entsprechende Key-ID:

 $ gpg  --list-sigs

/home/django/.gnupg/pubring.gpg
-------------------------------
pub   1024D/C591B828 2009-04-28
uid                  Michael Nausch <django@omni128.de>
sig 3        C591B828 2009-04-28  Michael Nausch <django@omni128.de>
sub   4096g/7662A515 2009-04-28
sig          C591B828 2009-04-28  Michael Nausch <django@omni128.de>

Anschließend erzeugen wir das Rückrufzertifikat:

 $ gpg --gen-revoke C591B828

sec  1024D/C591B828 2009-04-28 Michael Nausch <django@omni128.de>

Create a revocation certificate for this key? (y/N) y
Grund für den Widerruf:
  0 = Kein Grund angegeben
  1 = Hinweis: Dieser Schlüssel ist nicht mehr sicher
  2 = Schlüssel ist überholt
  3 = Schlüssel wird nicht mehr benutzt
  Q = Abbruch
(Wahrscheinlich möchten Sie hier 1 auswählen)
Ihre Auswahl? 3
Geben Sie eine optionale Beschreibung ein. Beenden mit einer leeren Zeile:
> Dies war nur ein Demonstrationsschlüssel!
> 
Grund für Widerruf: Schlüssel wird nicht mehr benutzt
Dies war nur ein Demonstrationsschlüssel!
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "Michael Nausch <django@omni128.de>"
1024-bit DSA key, ID C591B828, created 2009-04-28

Ausgabe mit ASCII Hülle erzwungen
Widerrufszertifikat wurde erzeugt.

Bitte speichern Sie es auf einem Medium welches sie wegschliessen
können; falls Mallory (ein Angreifer) Zugang zu diesem Zertifikat
erhält, kann erIhren Schlüssel unbrauchbar machen.  Es wäre klug,
dieses Widerrufszertifikat auch auszudrucken und sicher aufzubewahren,
falls das ursprüngliche Mediumnicht mehr lesbar ist. Aber Obacht: Das
Drucksystem kann unter Umständen eine Kopie anderen Nutzern zugänglich
machen.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: A revocation certificate should follow

iHIEIBECADMFAkn3UoUsHQNEaWVzIHdhciBudXIgZWluIERlbW9uc3RyYXRpb25z
c2NobMO8c3NlbCEACgkQSKXk5sWRuCi3QQCVGAy0rN55BUGgFVH5I0EepgcjfgCf
ey5WP/BwgqyyIx/VPweiJAFUREE=
=m1aK
-----END PGP PUBLIC KEY BLOCK-----

Den Zertifikatsblock speichern wir dann in einer Textdatei an einem sicheren Ort ab.

 $ vim revocation.crt

Soll nun der Schlüssel zurückgezogen werden, so braucht man lediglich die Datei revocation.crt in den öffentlichen Schlüsselbund pubring.pgp zu importieren. GnuPG erkennt nun das Rückrufzertifikat für einen der Schlüssel handelt und hängt des diesem ohne weitere Sicherheitsabfrage an.

 $ gpg --import revocation.crt 

gpg: key C591B828: "Michael Nausch <django@omni128.de>" revocation certificate imported
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                 neue Schlüsselwiderrufe: 1
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u

Anschließend können wir uns den Inhalt des öffentlichen schlüsselringes anzeigen lassen:

 $ gpg --list-sigs C591B828

pub   1024D/C591B828 2009-04-28 [revoked: 2009-04-28]
rev          C591B828 2009-04-28  Michael Nausch <django@omni128.de>
uid                  Michael Nausch <django@omni128.de>
sig 3        C591B828 2009-04-28  Michael Nausch <django@omni128.de>

Beim Schlüssel mit der ID C591B828 sehen wir nun am Zeilenanfang ein rev, welches uns anzeigt, dass dieser Schlüssel zurückgezogen (revoked) wurde. Anschließend läd man den Schlüssel auf einen Keyserver.

Will man seinen privaten Schlüssel von einem Rechner auf einen vertrauenswürdigen weiteren Rechner transferieren, gehen wir wie folgt vor.

Als erstes holen wir uns die Key-ID des Schlüssels, den wir exportieren möchten.

 $ gpg  --list-secret-keys

/home/django/.gnupg/secring.gpg
-------------------------------
sec   1024D/1F0471F12384C849 2009-03-30
uid                          Michael Nausch <michael@nausch.org>
uid                          Michael Nausch (aka BigChief) <bigchief@omni128.de>
uid                          Michael Nausch (aka Django) <django@nausch.org>
ssb   4096g/8088CA80D239B202 2009-03-30

Anschließend exportieren wir den gewünschten private-Key, in unserem Beispiel ist dies die ID 1F0471F12384C849.

 $ gpg --export-secret-key --armor 1F0471F12384C849 > 1F0471F12384C849-secret.asc

Die Datei 1F0471F12384C849-secret.asc enthält nun den private key und wir können diese Datei sichern, oder auf einen Zielrechner/Device kopieren.

Um einen Schlüssel an einen Freund direkt auszuhändigen, oder um den öffentlichen Schlüssel auf einer Homepage zu veröffentlichen, ist es notwendig den public Key zu exportieren. Hierzu benutzen wir den Befehl gpg – export –armor keyID > public-key.asc

 $ gpg --export --armor 2384C849 > public-key.asc

 $ cat public-key.asc 

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.5 (GNU/Linux)

mQGiBEnRHRIRBACR8Tm9jHPJ9RGkJA9OAPB/SrR7/5h/ho96yCuiZvlHRZJgRnZo
6nl1psT4I4ILY787KPi757P9CnXIVcFR6BJtfg5rwR9xUDSWRj2jqx3XWvSscqaz
4MEcrY1T4m9GHNrQi/O/bydiX8ugiBy55UaimsRnqU3AT7+k8aSCz9Q1ewCg7LIt
FpkkXnKGL+XFvEeaUqoYI/0EAIaGymU2Y7Cd3vq6jCl8qswjxnHzGiaowro0GeOH
TR78pksJD+mF3PqDBI3PCVI0PFitPsRCKEchAJuWmEXf0TEHOFquG6LtDGTfeapu
OE/CCCGFyd/KTH7BU/n/h2EBex/+tcdyaWN/g0OUkoXz3N1i9wocTWvraVgKwxpL
4E/hA/9UEtkDb1kDFn/6vAxJTAllkPvRBH9s4qX3jxE9VXjBF75ElN+uvIM9wWM0
RxjP3HaNXwSbRr+KZA2A6fpYbJnE/17LZ1DpQm9F8H6n3cf/nTD7GXZdznUsu7YV
vGcU63Kx1qhNLPCEphLI42TBgLuqR1f8kEAtSfFKgmQ73QeK2rQjTWljaGFlbCBO
YXVzY2ggPG1pY2hhZWxAbmF1c2NoLm9yZz6IYwQTEQIAIwIbAwYLCQgHAwIEFQII
AwQWAgMBAh4BAheABQJJ0R8EAhkBAAoJEB8EcfEjhMhJGiUAoJt5VLDVwRjL7M21
CGOojLl0xucNAKCiFgBJvMVJfGldqu3m9f1OeWZbTohGBBARAgAGBQJJ12PAAAoJ
EKcOoZ9MAW3gG24AoICAaUlcCJBWC/M4UTFxJ2eQ788EAJ9jQEP8ftKFMx+kNA1K
/MFAFvH274hGBBARAgAGBQJJ2kDsAAoJEPcYDSau2qZC2RkAnjBl0Yf1Mzu8vJZg
3N4Q2A7efl0aAJ9kMtlSjWwPg2xwrKx18+CEik/5VIhGBBARAgAGBQJJ2lMOAAoJ
ED/Dkkv9tarMcqgAoNQgUWKqZaSDCzKp37ln4U50tCFOAKDsYHMPF2NGROIjpuzi
j4qV4CjYWYhGBBARAgAGBQJJ27NKAAoJEIRjxf/Lvr8mkksAoMy2weW2gyJ+kDbW
phjPgFlSfnEHAJ9GL5ZWFDsa2ThupL+2nA0GuqTQ5ohWBBARCwAGBQJJ2oG8AAoJ
EB/fNUveod8B2fEA4LPjBK67s++8EprA8nSdyXTMgw3lPPAwRxWi0OQA4KB3P2Xo
tezVEYj/JvOuuHbP70Kh+zNRRw8/QVm0M01pY2hhZWwgTmF1c2NoIChha2EgQmln
Q2hpZWYpIDxiaWdjaGllZkBvbW5pMTI4LmRlPohgBBMRAgAgBQJJ0R6nAhsDBgsJ
CAcDAgQVAggDBBYCAwECHgECF4AACgkQHwRx8SOEyEmTgwCgiAIzkeiY+QVEZ5s1
4BrMyyyJhG8AoI7IH18iOH8K1FZGcOqhbs6nRGHiiEYEEBECAAYFAknXY8AACgkQ
pw6hn0wBbeADGQCfRPq7TAvuCQHBVQo8/r3JNC004agAn1XqvOD2Zv70gM5IgIft
AUtP2U6+iEYEEBECAAYFAknaQOwACgkQ9xgNJq7apkL1oACeNjg0+DOHWq3ouNb9
rrt+Qqu0/IsAnA+KM383QqdbbSc5RlhgykPUL2G7iEYEEBECAAYFAknaUw4ACgkQ
P8OSS/21qsxN8wCggM/ypa06JlHtj61TSv2u7SIzXM0An1JLmON0BTzseRmzMCEE
TBZCM5IWiEYEEBECAAYFAknbs08ACgkQhGPF/8u+vyYRqACdE9urnI7qIDCwWHbg
1LG+9vzf+84AnjLiQv1Jd5sA9B2v13ztrKl6/kzLiFYEEBELAAYFAknagbwACgkQ
H981S96h3wHy5ADgj3GrZ9u7UfC4XNECO6w8mjvf0QLi/AtfN9XqPgDffPmS08he
7xk1gvYM+hzm7IU6Dv+DN3hU/QbcKbQvTWljaGFlbCBOYXVzY2ggKGFrYSBEamFu
Z28pIDxkamFuZ29AbmF1c2NoLm9yZz6IYAQTEQIAIAUCSdEe0gIbAwYLCQgHAwIE
FQIIAwQWAgMBAh4BAheAAAoJEB8EcfEjhMhJa9cAoNiV37wAheLKJxUN9Ui+cjJI
vt0MAKC80k4tO7Oa0E3nO6Qbq3Cu/i/6eohGBBARAgAGBQJJ12PAAAoJEKcOoZ9M
AW3gq4EAnAoBXyI9HNhBNbhB/sBPmCNEgBEtAKCl9krifoij25l3wmb9X6FUdXzY
N4hGBBARAgAGBQJJ2kDsAAoJEPcYDSau2qZCqN4AoIawtaQoHX8dkon96WeOZhql
7VZiAJ9a4kdk2OU1H8JOl5gLDHTaQfgfEohGBBARAgAGBQJJ2lMOAAoJED/Dkkv9
tarMdTAAoKFSc2Jw6M+wZCNc/fZEj6jqqHSAAJ4soecklyB3piOV+AruhmRe8R0f
DYhGBBARAgAGBQJJ27NPAAoJEIRjxf/Lvr8m4ZoAnjWuo4zN50J3OVizMaQYDbYH
g7K3AJ93Qe8isJhUYzChdanLTi4KNPwo/4hWBBARCwAGBQJJ2oG8AAoJEB/fNUve
od8BLqkA31GEhEnkOep/6qnYL2OOWjYJydEBpj+oTbe4KuMA4J5puTM6tvdkp9e4
F2jcc+6xDKNMegBZug/1Rby5BA0ESdEdkhAQAMs80NMTiH+JMV5u9ieTpuvv/kZV
vJvrEUTBZ46YygbHvgkdkaG5APAsuxryRUxXNQpH8kacMdolOrPdUmpqLAs1zuq7
pFtalXwYAbdl0jZJsM1zfpx4FJ0ExRY3fviQrapAsrfd95p9Zz6yLHE6OPhKdVyU
pi2VVAFvaLir7nmyNFCjwfaPC5cDUoDHfuHpnEXC4p3YEmynK8ySjSktMt+T6A1C
l2zjGq4gdf/SqxDEGOZzHPrTx6Dbb69h9xzS6CqPllvMKfjck2MovZCOBq29cI1l
LS8dT2smLWUwiVsxCn9mfqQg1u3SQhrfcGHlhzKvFdPY0aN7cILOCPUedBWQL5Wk
tnoF+GTPDfhOsvhuOTnrCz8TcZwwkZqH16jCV/oFCKvmg5fv/FzoZhn26trihn9Y
UtfTmJlpcjjKUQEeDhDyX6F7vKyhv5XfHCZ+cnSa+YUJze8DoL9eqJmaT6zzvbT5
mn90yPJFvaoiXslYlY7DdjKW85S8Al1VQJLEvS03Kdaz2pqUWOPkYLJ8VCxNQLKe
lLqkcEHXeYukpmBP2eQT/jDsGpaziZiT96xZQppg53tWrAdRoZetnlL8/Nc/husm
JN/U/Pv9/mNd4dutk/OpJmQOLPM6WZ0ZKOx3V7NdXd1bFAaIkwchAPxoEvfZ6ZZN
R4ts9kAHSP9//w8vAAMHD/9/GqSZ7BqpcVtTDhoZfrb4sr/auORxepxJIWWmYFs+
dTGHzuPup7Rzj8O0eTOFvv1Fqzek4IXJBNDR/ulHiFbOTLbQ7fTVvIH/HQN7ZsiB
zpj91C1alZVO69nSPw6O5QIpSnqx+azXLmdtsjv77trtuAa2tvJWI1Bv3KcIzm3e
gSXcSeVpSmSU3R45FuaCR4G2D3iv7nb8S2FokalJC0A32A9aiGb+TFgXTno7UAcm
g+yF+7/VFqDQi9jlMjCKgUGsj6yM8cxDpiL292Iqstx3/WFpc82a0pBZwh0aKruV
fwToO7hLenSLvNIVXcSDG3wvWREHqosScnXCO0gln6XGOj5VSHJ+T4mUBK4v/GyI
2DWFCkqufpz/tzu39Cf2/aF6kHSu+y3dypSQ4CTbaAkOP32SGN2c2zPL6R6HzFh6
kA3qgtSfwa4cwYvf3U1wSyZQOp3DQLgJ+FbPkX8KLA4wQ+FkApsKZXoQoLMcf4WF
BxhQJnagtFajAt+HMP0C/5Kmk4qJuAV5YDWAdwxWAdxkMbeYiAm4GfkrxikEC6sU
jloprzxctT2HwFEA8kSyN86tTv1qnphYleBgblOeP4HM1H07iKBjIF34Gvo1+K3Z
J7QHgUluxQK2KD3WSakCzvSqHr/au5fvzm4wnY1EvqLwC0qXbrI7vJLz4rkpEhNt
RYhJBBgRAgAJBQJJ0R2SAhsMAAoJEB8EcfEjhMhJjvUAn0PyyXdK714eWa8dQUmd
36efmnu7AJ9yr+km06Z7BdZ1z8AOfNJdwpp0vg==
=gen/
-----END PGP PUBLIC KEY BLOCK-----

Den zuvor exportierten public key können wir nun in einem WEB-Formular auf einem Keyserver manuell eintragen. Oder wir exportieren diesen direkt aus dem öffentlichen Schlüsselring:

 $ gpg --keyserver keyserver.nausch.org --send-key 2384C849

gpg: sending key 2384C849 to hkp server keyserver.nausch.org

Um nun nicht jedesmal den Keysever manuell angeben zu müssen, hinterlegen wir diesen in der Konfigurationsdatei ~/.gnupg/gpg.conf.

 $ vim ~/.gnupg/gpg.conf

...
# Djangos bevorzugter Keyserver, eingetragen am 28.04.2009
keyserver keyserver.nausch.org

Nunmehr reicht ein:

 $ gpg --send-key 2384C849
 gpg: sending key 2384C849 to hkp server keyserver.nausch.org

Beim Revocation Certifikat haben wir bereits die Importfunktion genutzt. Genauso funktioniert im Übrigen der Import eines fremden public Keys.

 $ gpg --import friendly-user.asc

Genau so geht dies natürlich direkt von einem Keyserver aus.

 $ gpg --recv-key 57548dcd

Zum Editieren eines Schlüssel, so z.B. zum Ergänzen von weiteren User-IDs (eMail-Adressen) oder zum Festlegen des Vertrauenswertes oder zum Beglaubigen (Signieren) von Schlüsseln nutzen wir den Schlüsseleditor. Diesen rufen wir auf über gpg –edit-key keyID.

$ gpg --edit-key 2384C849
gpg (GnuPG) 1.4.5; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Geheimer Schlüssel ist vorhanden.

pub  1024D/2384C849  created: 2009-03-30  expires: niemals     usage: SC  
                     trust: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096g/D239B202  created: 2009-03-30  expires: niemals     usage: E   
[ultimate] (1). Michael Nausch <michael@nausch.org>
[ultimate] (2)  Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ultimate] (3)  Michael Nausch (aka Django) <django@nausch.org>

Befehl> help
quit        Menü verlassen
save        speichern und Menü verlassen
help        Diese Hilfe zeigen
fpr         show key fingerprint
list        Schlüssel und User-IDs auflisten
uid         User-ID N auswählen
key         select subkey N
check       check signatures
sign        sign selected user IDs [* see below for related commands]
lsign       sign selected user IDs locally
tsign       sign selected user IDs with a trust signature
nrsign      sign selected user IDs with a non-revocable signature
adduid      Eine User-ID hinzufügen
addphoto    Eine Foto-ID hinzufügen
deluid      delete selected user IDs
addkey      add a subkey
addcardkey  add a key to a smartcard
keytocard   move a key to a smartcard
bkuptocard  move a backup key to a smartcard
delkey      delete selected subkeys
addrevoker  Einen Widerrufschlüssel hinzufügen
delsig      delete signatures from the selected user IDs
expire      change the expiration date for the key or selected subkeys
primary     flag the selected user ID as primary
toggle      toggle between the secret and public key listings
pref        Liste der Voreinstellungen (für Experten)
showpref    Liste der Voreinstellungen (ausführlich)
setpref     set preference list for the selected user IDs
keyserver   set the preferred keyserver URL for the selected user IDs
notation    set a notation for the selected user IDs
passwd      Die Passphrase ändern
trust       Den "Owner trust" ändern
revsig      revoke signatures on the selected user IDs
revuid      revoke selected user IDs
revkey      revoke key or selected subkeys
enable      enable key
disable     disable key
showphoto   show selected photo IDs
clean       compact unusable user IDs and remove unusable signatures from key
minimize    compact unusable user IDs and remove all signatures from key

* The `sign' command may be prefixed with an `l' for local signatures (lsign),
  a `t' for trust signatures (tsign), an `nr' for non-revocable signatures
  (nrsign), or any combination thereof (ltsign, tnrsign, etc.).

Befehl> quit

Zu einem bestehendem Schlüsselpaar, lassen weitere eMail-Adressen hinzufügen. Hierzu lassen wir uns erst einmal alle secret-keys ausgeben.

 $ gpg --list-secret-keys

/home/django/.gnupg/secring.gpg
-------------------------------
sec   1024D/1F0471F12384C849 2009-03-30
uid                          Michael Nausch <michael@nausch.org>
uid                          Michael Nausch (aka BigChief) <bigchief@omni128.de>
uid                          Michael Nausch (aka Django) <django@nausch.org>
ssb   4096g/8088CA80D239B202 2009-03-30

In diesem Beispiel haben wir nur einen privaten Schlüssel im Schlüsselbund. Zum Anfügen einer Adresse wählen wir zuerst den gewünschten key aus.

 $ gpg --edit-key 1F0471F12384C849

gpg (GnuPG) 2.0.14; Copyright (C) 2009 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.

Geheimer Schlüssel ist vorhanden.

pub  1024D/1F0471F12384C849  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: SC  
                             Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096g/8088CA80D239B202  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2)  Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3)  Michael Nausch (aka Django) <django@nausch.org>

Befehl>

Da wir eine weitere eMail an den Schlüssel anfügen wollen, teilen wir dies dem Programm durch die eingabe der Option adduid mit.

 Befehl> adduid

Wir werden nun nach dem Namen, eMail-Adresse und Kommentar gefragt.

Ihr Name ("Vorname Nachname"): Django
Email-Adresse: django@nausch.org
Kommentar: 
Sie haben diese User-ID gewählt:
    "Django <django@nausch.org>"

Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden?

Nach Bestätigung der Daten durch Eingabe von F werden wir nach der bestehenden Passphrase unseres Schlüssels gefragt.

 Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
 Benutzer: "Michael Nausch <michael@nausch.org>"
 1024-Bit DSA Schlüssel, ID 1F0471F12384C849, erzeugt 2009-03-30

Im Speicher wurde nun eine weitere User-ID bzw. eMail-Adresse zu einem bestehenden private key hinzugefügt. Damit die Daten dauerhaft auf die Platte geschrieben werden, schließen wir unseren Bearbeitungsvorgang mit dem Befehl save ab.

 Befehl> save

Wie zuvor beim Hinzufügen eines Schlüssels, lassen wir uns erst alle secret-keys eines Schlüsselbundes ausgeben, wenn wir eine eMailadresse bei einem Schlüssel entfernen wollen.

 $ gpg --list-secret-keys

/home/django/.gnupg/secring.gpg
-------------------------------
sec   1024D/1F0471F12384C849 2009-03-30
uid                          Michael Nausch <michael@nausch.org>
uid                          Michael Nausch (aka BigChief) <bigchief@omni128.de>
uid                          Michael Nausch (aka Django) <django@nausch.org>
uid                          Django <django@nausch.org>
ssb   4096g/8088CA80D239B202 2009-03-30

In diesem Beispiel haben wir nur einen privaten Schlüssel im Schlüsselbund. Zum Löschen einer Adresse wählen wir zuerst den gewünschten key aus.

 $ gpg --edit-key 1F0471F12384C849

gpg (GnuPG) 2.0.14; Copyright (C) 2009 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.

Geheimer Schlüssel ist vorhanden.

pub  1024D/1F0471F12384C849  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: SC  
                             Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096g/8088CA80D239B202  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2)  Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3)  Michael Nausch (aka Django) <django@nausch.org>
[ uneing.] (4)  Django <django@nausch.org>

Befehl>

Mit dem Befehl uid wählen wir nun diejenige User-ID aus, die wir löschen möchten.

 Befehl> uid 4

pub  1024D/1F0471F12384C849  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: SC  
                             Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096g/8088CA80D239B202  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2)  Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3)  Michael Nausch (aka Django) <django@nausch.org>
[ uneing.] (4)* Django <django@nausch.org>

An dem Sternchen * hinter der UID-Nummer sehen, wir welche ID ausgewählt wurde. Nun können wir mit dem Befehl deluid die gewählte UID löschen.

 Befehl> deluid

Wir werden nun gefragt, ob wir dies wirklich wünschen.

 Diese User-ID wirklich entfernen? (j/N) j

Dies e Frage bestätigen wir mit der Eingabe von j.

pub  1024D/1F0471F12384C849  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: SC  
                             Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096g/8088CA80D239B202  erzeugt: 2009-03-30  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2)  Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3)  Michael Nausch (aka Django) <django@nausch.org>

Auch hier müssen wir die Änderung mit dem Befehl save abspeichern. Zur Sicherheit frägt uns aber das Programm, falls wir diesen schritt vergessen haben sollten.

 Befehl> quit

 Änderungen speichern? (j/N) j

In Regelmäßigen Abständen ist es zweckmäßig und angeraten, die Schlüssel im lokalen Schlüsselspeicher zu aktualisieren. Somit kann festgestellt werden, ob z.B. Schlüssel noch aktuell oder zurückgerufen worden sind.

Im einfachsten Fall machen wir das mit Hilfe einer GUI oder eben auf der Konsole mit dem Aufruf /usr/bin/gpg –refresh-key.

 # /usr/bin/gpg --refresh-key

gpg: 18 Schlüssel werden per hkp://keyserver.nausch.org aktualisiert
gpg: fordere Schlüssel 7C03FC4F von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 8B7684D4 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 81EBD929 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 0DE59D7A von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel C3B26780 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 4C016DE0 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel CBBEBF26 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel E9E5F528 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel DEA1DF01 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel FDB5AACC von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel A2C9DB22 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel AEDAA642 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 2840C708 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 65D0FD58 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel CD9EC0A8 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 3A4B0B6A von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel 581A98A1 von hkp-Server keyserver.nausch.org an
gpg: fordere Schlüssel D4827E51 von hkp-Server keyserver.nausch.org an
gpgkeys: key 126AAB0159C57820F3FE773EB27468897C03FC4F not found on keyserver
gpg: Schlüssel 8B7684D4: "Klaus Tachtler (klaus) <klaus@tachtler.net>" nicht geändert
gpg: Schlüssel 81EBD929: "Sebastian Schubert (SpaceNet AG) <ssc@space.net>" nicht geändert
gpg: Schlüssel 0DE59D7A: "Thomas Keil <thomas@weblizards.de>" nicht geändert
gpg: Schlüssel C3B26780: "Peer Heinlein -- Heinlein Professional Linux Support GmbH <p.heinlein@heinlein-support.de>" nicht geändert
gpg: Schlüssel 4C016DE0: "Marco Scholl (Ubuntu-Launchpad) <ubuntu@marco-scholl.de>" nicht geändert
gpg: Schlüssel CBBEBF26: "Bernd Goetter (dh5is) <routerman@gmx.net>" nicht geändert
gpg: Schlüssel E9E5F528: "Robert Fuhge <fuhge@web.de>" nicht geändert
gpg: Schlüssel DEA1DF01: "Dieter Hametner (Emails mit Piraten Partei) <dh+piraten@gekrumbel.de>" nicht geändert
gpg: Schlüssel FDB5AACC: "Carsten Presser (cpresser) <c@rstenpresser.de>" nicht geändert
gpg: Schlüssel A2C9DB22: "Udo Richter <udo.richter@gmx.de>" nicht geändert
gpg: Schlüssel AEDAA642: "Tobias Grimm <tobias.grimm@e-tobi.net>" nicht geändert
gpg: Schlüssel 2840C708: "dirk astrath <dastrath@gmx.de>" nicht geändert
gpg: Schlüssel 65D0FD58: "CA Cert Signing Authority (Root CA) <gpg@cacert.org>" nicht geändert
gpg: Schlüssel CD9EC0A8: "Thomas KÜHNE" nicht geändert
gpg: Schlüssel 3A4B0B6A: "ValiDOM (valid until 2013-12-31) <vali@validom.de>" nicht geändert
gpg: Schlüssel 581A98A1: "Joel HATSCH <home@joel-hatsch.net>" nicht geändert
gpg: Schlüssel D4827E51: "Joel HATSCH <home@joel-hatsch.net>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 17
gpg:                             unverändert: 17

Natürlich muss man nicht hardcore-mäßig auf der Konsole alle die vorgenannten Befehle auf der Konsole absetzen. Sowohl KDE als auch Gnome bringen recht komfortable und leistungsstarke GUI²⁾ mit.

Beide Programme sind soweit selbsterklärend, so dass eine weitere Beschreibung hier nicht notwendig ist.

Zum Signieren einer Datei, also dem Beglaubigen einer Datei mit einer digitalen Unterschrift, existieren mehrere Möglichkeiten. Wir legen uns einfach eine Testdate mit dem aktuellen Datum an.

 $ ddate > Testdatei

 $ cat Testdatei 

Today is Pungenday, the 45th day of Discord in the YOLD 3175

Mit gpg --sign Dateiname erzeugen wir die Signatur, kompremieren die Originaldatei und schreiben beides in Binärformat in eine neue Datei.

 $ gpg --sign Testdatei 

You need a passphrase to unlock the secret key for
user: "Michael Nausch <michael@nausch.org>"
1024-bit DSA key, ID 2384C849, created 2009-03-30

Diese Datei liegt zwar im Binärformat aber keineswegs verschlüsselt vor.

 $ cat Testdatei.gpg 

�
�����$(�R�Q���'��$ΐ�⒔Ē�L��)�B�S+2�J��S�����TӒ
                                                       �T~��Kfqr~Q�BfX*���E���ܔ�Þ��
d
�|A�"��v�>O�r$W��j+{��束�
                          \����P��}�{x��-���

Dieses Vorgehen macht jedoch nur Sinn, wenn mit der Option --encrypt gleichzeitig die Datei verschlüsselt werden soll.

 $ gpg --encrypt --sign -r 2384C849 Testdatei

You need a passphrase to unlock the secret key for
user: "Michael Nausch <michael@nausch.org>"
1024-bit DSA key, ID 2384C849, created 2009-03-30

Will man die Daten per eMail verschicken so benutzt man die Option --armor.

 $ gpg --sign --armor Testdatei

You need a passphrase to unlock the secret key for
user: "Michael Nausch <michael@nausch.org>"
1024-bit DSA key, ID 2384C849, created 2009-03-30

Nun können wir uns die erstellte signierte Datei ansehen.

 $ cat Testdatei.asc

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.5 (GNU/Linux)

owGbwMvMwCQoz1L4UbnlhCfjGp8kzpDU4pKUxJLUTM/v6U9C8lMSKxUyixUCSvPS
U/OAHB2FkoxUBRPTkgwFkFR+moJLZnFyflGKQmYeWCrS38dFwdjQ3JSrw56ZlQFk
Csx8QaZZ0gxzuLxOLFrGsOrFpwOrXhWuv2v34D27O8P8Iu/gXfcYvQ9+EfTwv1H5
ZnX3/S/LAQ==
=G1f3
-----END PGP MESSAGE-----

Soll die Originaldatei zusammen mit der Signatur in der erzeugten Datei stehen, so verwendet man die Option --clearsign.

 $ gpg --clearsign --armor Testdatei

You need a passphrase to unlock the secret key for
user: "Michael Nausch <michael@nausch.org>"
1024-bit DSA key, ID 2384C849, created 2009-03-30

Die erzeugte Testdatei.asc enthält dann:

 $ cat Testdatei.asc 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Today is Pungenday, the 45th day of Discord in the YOLD 3175
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFJ92i4HwRx8SOEyEkRAjwHAJsFNjNZmdXHYNA0cs+hv1cj0JhH5wCfSB2r
qljC/6inruZdj0BX2zwoBRI=
=smHj
-----END PGP SIGNATURE-----

Mit gpg --verify können wir die Signatur der datei überprüfen:

 $ gpg --verify Testdatei.asc 

gpg: Signature made Di 28 Apr 2009 22:36:08 CEST using DSA key ID 2384C849
gpg: Good signature from "Michael Nausch <michael@nausch.org>"
gpg:                 aka "Michael Nausch (aka BigChief) <bigchief@omni128.de>"
gpg:                 aka "Michael Nausch (aka Django) <django@nausch.org>"

Als letzte Variante gibt es dann noch die entkoppelte Signatur. Auch hier kann mittels der Option --armor die Ausgabe in lesbaren Format erzwungen werden. Andernfalls würde die Signatur in binärer Form erzeugt werden.

 $ gpg --detach-sign --armor Testdatei

You need a passphrase to unlock the secret key for
user: "Michael Nausch <michael@nausch.org>"
1024-bit DSA key, ID 2384C849, created 2009-03-30

In der nun erzeugten Datei ist nur noch die Signatur enthalten.

 $ cat Testdatei.asc 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBJ92rnHwRx8SOEyEkRArFEAJ9YUv8YvCj63rh3f/MGmD1O+9PyAwCfQhfu
nDMDrNa7OKWXMjcuXPLLKr4=
=FYiz
-----END PGP SIGNATURE-----

Wir verändern nun zu Testzwecken den Inhalt der Testdatei - wir fügen ein Zeichen ein.

 $ vim Testdatei

Today is Pungenday, the 45th day of Discord in the YOLD 3175!

Und überprüfen nunmehr die Signatur der Testdatei, was natürlich postwendend als BAD signature angeprangert wird.

 $ gpg --verify Testdatei.asc Testdatei

gpg: Signature made Di 28 Apr 2009 22:55:18 CEST using DSA key ID 2384C849
gpg: BAD signature from "Michael Nausch <michael@nausch.org>"

Wurde die Signatur verändert so fällt dies sofort auf:

 $ gpg --verify Testdatei.asc Testdatei

gpg: Prüfsummenfehler; 3a1dd4 - 1588b3
gpg: [don't know]: indeterminate length for invalid packet type 2
gpg: no signature found
gpg: Die Unterschrift konnte nicht überprüft werden.
Denken Sie daran, daß die Datei mit der Unterschrift (.sig oder .asc)
als erster in der Kommandozeile stehen sollte.

Verschlüsselt wird jeweils mit dem Public Key des Empfängers, daher geben wir die KeyID beim Verschlüsseln mit der Option -r an.

 $ gpg --encrypt --armor -r 4C016DE0 Testdatei

Ohne den Schalter –armor wird die Datei im Binärformat gespeichert.

 $ gpg --encrypt -r 4C016DE0 Testdatei

Zum Entschlüsseln nutzen wir die Option --decrypt; da auf den privaten schlüsselbund zugegriffen wird, ist die Passphrase mit anzugeben.

 $ gpg --decrypt Testdatei.asc > neue_Testdatei

You need a passphrase to unlock the secret key for
user: "Michael Nausch <michael@nausch.org>"
4096-bit ELG-E key, ID D239B202, created 2009-03-30 (main key ID 2384C849)

gpg: verschlüsselt mit 4096-Bit ELG-E Schlüssel, ID D239B202, erzeugt 2009-03-30
      "Michael Nausch <michael@nausch.org>"

Nachdem wir uns im vorliegenden Kapitel mit den theoretischen Grundlagen befasst haben, widmen wir uns im nachfolgendem Kapitel dem Umgang mit S/MIME in der Praxis.

Im folgendem Kapitel widmen wir uns im Detail dem CryptoStick der German Privacy Foundation und das im Detail unter CentOS 6.x.

• Zurück zu >>Projekte und Themenkapitel<<
• Zurück zur Startseite