GnuPG: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
Wechseln zu: Navigation, Suche
(Löschantrag abgelehnt)
(Edit War verworfen. Bitte nicht aus Trotz einfach alle Änderungen revidieren! Nutzt die Diskussionsseite für sachliche Einwände und Vorschläge!)
Zeile 1: Zeile 1:
GnuPG ist ein Kryptografieprogramm zur Signierung, Verschlüsselung und Entschlüsselung von Daten. Als OpenSource-Software nutzt es sog.
+
{{righttoc}}
patentfreie Algorithmen und ist unter verschiedenen Betriebssystemen (u.a. auch Microsofts Windows) lauffähig.
+
GnuPG ist ein Kryptografieprogramm zur Signierung, Verschlüsselung und Entschlüsselung von Daten. Die Möglichkeiten GPGs belaufen sich unter anderem auf Verschlüsselung und Signierung von E-Mails, Chats und Dateien.
Die Möglichkeiten GPGs belaufen sich unter anderem auf Verschlüsselung (im Weiteren entfällt der Zusatz ''Entschlüsselung'', weil
+
alleinige Verschlüsselung in der Regel unlogisch ist) von E-Mails, Chats und Dateien, was es gerade für Instant Messaging interessant
+
macht.
+
  
==Funktionsweise==
+
== Installation ==
GnuPG funktioniert mit Hilfe eines Schlüsselpaars, bestehend aus einem privaten Schlüssel, der, wie der Name schon sagt, im Privatbesitz bleibt, und einem öffentlichen Schlüssel, der an die Kommunikationspartner weitergegeben wird. Durch den öffentlichen Schlüssel ist die Verschlüsselung eines Datums möglich, jedoch erlaubt nur der private Schlüssel die Entschlüsselung.
+
GnuPG ist im „extra“-Repository verfügbar und kann aus diesem mittels [Pacman] installiert werden.
  
==Installation==
+
  pacman -Sy gnupg
  # pacman -Sy gnupg
+
  
==Erzeugen eines Key-Pairs==
+
== Funktionsweise ==
Damit wir loslegen können, legen wir uns ein Key-Pair zu.
+
GnuPG funktioniert mit Hilfe eines Schlüsselpaars, bestehend aus einem privaten Schlüssel, der nicht veröffentlicht wird, und einem öffentlichen Schlüssel, der an die Kommunikationspartner weitergegeben wird. Daten werden mit dem öffentlichen Schlüssel verschlüsselt, und können nur vom Besitzer des Privaten Schlüssels wieder entschlüsselt werden (asymmetrische Verschlüsselung).
$ gpg --gen-key
+
Wir geben Namen, E-Mail-Adresse und Kommentar ein, welche später zu Identifierung durch die Partner genutzt werden kann. Es müssen nicht
+
unbedingt wahre Angaben sein...
+
Wir erhalten eine Ausgabe wie:
+
pub  1024D/77421F4F 2003-02-27 Vorname Nachname (Kommentar) <E@mail.ru>
+
    Key fingerprint = CB84 38FF 2195 95DF ACA0  44B1 468F 1F20 23F8 0042
+
sub  1024g/C596B611 2003-02-27
+
Diese sagt uns, dass ''77421F4F'' die hexadezimale Kennung des Schlüssels. Diese sollte man immer mit 0x einleiten, damit GPG die Eingabe
+
besser von anderen unterscheiden kann.
+
  
==Ungültigkeitsvorbehalt==
+
== Erzeugen eines Schlüsselpares ==
Für den Fall der Fälle sollte man sich vielleicht die Option vorbehalten, den aktuellen Schlüssel für ungültig zu erklären.
+
Zum Verwenden muss man erstmalig eine Schlüsselpaar erzeugen.
Beispielsweise, wenn man sein Passwort vergessen hat...
+
$ gpg --gen-revoke 0xKEYID > revokeKey
+
Speichert das Revoke-Zertifikat in der Datei ''revokeKey''. Diese Datei sollte an einem sicherern Ort aufbewahrt werden, da sie die
+
Ungültigkeitserklärung für den Schlüssel enthält.
+
  
Das ganze ist sinnvoll, wenn der Key auf einem Server liegt, wir ihn auf diesem aber nicht löschen können. Wichtig ist, dass die
+
gpg --gen-key
--keyserver-Option gesetzt ist. (Laut man-Page werden die Keyserver oft untereinander gesynct).
+
Zum Beispiel kann man den Server in die ''~/.gnupg/options'' schreiben:
+
$ echo ''keyserver wwwkeys.de.pgp.net'' >> ~/.gnupg/options
+
  
Lade den Key vom Server:
+
Es müssen dann einige Daten angegeben werden. Man sollte hier, wenn man einen „offiziellen“ Schlüssel erstellen will, seine richtigen Daten angeben. Wenn man anonym bleiben will, kann man hier selbstvertändlich beliebige Fantasiedaten angeben.
$ gpg --keyserver wwwkeys.de.pgp.net --recv-keys 0xKeyID
+
Importiere das Ungültigkeitszertifikat:
+
$ gpg --import revokeKey
+
Sende den Key wieder auf den Server:
+
$ gpg --keyserver wwwkeys.de.pgp.net --send-keys 0xKeyID
+
(Die Option --keyserver ist optional, wenn dieser bereits in der ''options'' steht.)
+
  
Eine andere Möglichkeit ist, die Ablaufdaten möglichst niedrig resp. zeitnah zu halten, sodass die Keys automatisch ungültig werden.
+
pub  1024D/77421F4F 2000-06-25 Vorname Nachname (Kommentar) <user@example.org>
 +
    Key fingerprint = CB84 AD4C 2195 FFAD ACA0  471B 468F 3FF9 0781 DF4A
 +
sub  1024g/C596B611 2000-06-25
 +
 
 +
Die Schlüssel-ID ist ''77421F4F''. Dies ist die hexadezimale Kennung des Schlüssels. Diese sollte bei der Eingabe in Programme immer mit „0x“ eingeleitet werden.
 +
 
 +
== Verbreitung der Schlüssel ==
 +
Schlüssel können auf sogenannte Schlüsselserver geladen werden. Dort ist es anderen möglich diese Schlüssel beispielsweise anhand der E-Mailadresse oder auch der Schlüssel-ID zu finden und herunterzuladen.
 +
 
 +
Um den Schlüssel hoch- oder herunter zuladen benutzt man „gpg“ mit entsprechenden Parametern
 +
 
 +
gpg --send-keys 0x77421F4F
 +
gpg --recv-keys 0xDED070DE
 +
 
 +
Es wird der im Generierungsbeispiel erstellte Schlüssel auf einen Schlüsselserver geladen, danach wird ein anderer Schlüssel von einem Schlüsselserver heruntergeladen.
 +
 
 +
Man muss hier jedoch jeweils mittels des parameters „--keyserver“ noch explizit einen zu verwendenen Schlüsselserver angeben. Will man dies nicht, muss man den zu verwendenen Schlüsselserver in die GnuPG-Konfigurationsdatei „~/.gnupg/options“ schreiben
 +
 
 +
keyserver wwwkeys.de.pgp.net
 +
 
 +
Hier wird der Schlüsselserver „wwwkeys.de.pgp.net“ verwendet.
 +
 
 +
Das praktische an der Schlüsselserver-Methode ist, dass man den Key direkt importiert. Der Nachteil ist natürlich, dass man in aller Regel nicht immer die KeyID parat hat. Dafür ist eine Suchfunktion über einen Browser erreichbar. Hier kann man sich die Keys als klartext anzeigen und herunterladen. Um einen heruntergeladenen Key nun noch zu importieren, ist ein:
  
==Verbreitung der Keys==
 
Keys können auf sogenannte Key-Server geladen werden. Dort ist es anderen möglich diese zu finden (beispielsweise anhand der
 
E-Mailadresse oder auch der KeyID) und herunterzuladen. Um den Key hochzuladen reicht ein:
 
$ gpg --send-keys 0xKeyID
 
Um Keys herunterzuladen ein:
 
$ gpg --recv-keys 0xKeyID
 
Das praktische an dieser Methode ist, dass man den Key direkt importiert. Der Nachteil ist natürlich, dass man in aller Regel nicht
 
gerade die KeyID parat hat. Dafür ist eine Suchfunktion über einen Browser erreichbar. Hier kann man sich die Keys als klartext
 
anzeigen und herunterladen. Um einen heruntergeladenen Key nun noch zu importieren, ist ein:
 
 
  $ gpg --import KeyFile
 
  $ gpg --import KeyFile
erforderlich.
 
  
==Dateisignaturen==
+
erforderlich. Wobei „KeyFile“ den über den Browser heruntergeladenen, öffentlichen Schlüssel beinhalten muss.
Um Dateien zu signieren, reicht ein:
+
 
  $ gpg --armor --detach-sign Datei
+
== Dateisignaturen ==
Das führt dazu, dass eine neue Datei namens ''Datei.asc'' angelegt wird, die die Signatur enthält.
+
Mittels GnuPG können auch Dateien signiert werden. So kann man sehr einfach einen Dateiaustausch betreiben, und der Empfänger kann sich sicher sein, von wem die Datei kommt.
Möchte man aber die Signatur an das Dateiende hängen, so gelingt das mit:
+
 
  $ gpg --clearsign -a Datei
+
  gpg --armor --detach-sign Dateiname
Das ist allerdings nur bei Klartextdateien zu empfehlen, weil Binärdateien danach aller Regel nach solange unbrauchbar sind, bis die  
+
 
Signatur wieder entfernt wird.
+
Hiermit wird die Datei „Dateiname“ Signiert. Es wird eine Datei „Dateiname.asc“ erstellt, in der sich die Signatur befindet. Möchte man die Signatur an das Dateiende hängen, ist dies ebenfalls möglich.
 +
 
 +
  gpg --clearsign -a Dateiname
 +
 
 +
Dieses Vorgehen ist allerdings nur bei Klartextdateien zu empfehlen, weil Binärdateien danach aller Regel nach solange unbrauchbar sind, bis die Signatur wieder entfernt wird.
 +
 
 +
gpg --verify Dateiname.asc Dateiname
 +
 
 +
Hiermit wird die Datei „Dateiname“ anhand der Signaturdatei „Dateiname.asc“ verifiziert.ein. Die Angabe der Datei, die verifiziert werden soll, ist nur erforderlich, sofern die .asc-Datei nicht denselben Namen hat, wie die signierte Datei. In dem konkreten Beispiel ist es also eigentlich nicht erforderlich.
 +
 
 +
== Dateiverschlüsselung ==
 +
Dateien können nicht nur Signiert, sondern auch Verschlüsselt werden.
 +
 
 +
gpg --encrypt -a --recipient KeyId Dateiname
 +
 
 +
Als „KeyId“ muss die Schlüssel-ID desjenigen angegeben werden, der die Datei „Dateiname“ später mit seinem Privaten schlüssel entschlüsseln soll. Entschlüßselt werden Dateien wie folgt.
 +
 
 +
gpg --decrypt --output Dateiname Dateiname.asc
 +
 
 +
== Ungültigkeitsvorbehalt ==
 +
Dieser Schlüssel ist, wenn nicht anders definiert, unbegrenzt lange gültig. Um einen schlüssel vor Ablauf der Gültigkeitsdauer für ungültig erklären zu können, muss ein Widerrufszertifikat, der „Revoke Key“, erstellt werden.
 +
 
 +
gpg --gen-revoke 0x77421F4F > revokeKey
 +
 
 +
Im Beispiel wird das Widerrufszertifikat für den oben generierten Schlüssel erstellt. Hat man den Schlüssel beispielsweise auf einen Schlüsselserver geladen, kann man ihn in diesem Fall im Allgemeinen nicht direkt wieder löschen. Hier kommt das Widerrufszertifikat zum tragen.
  
Um die Signatur zu verfizieren gibt man:
+
  gpg --keyserver wwwkeys.de.pgp.net --recv-keys 0x77421F4F
  $ gpg --verify Datei.asc Datei
+
gpg --import revokeKey
ein. Das abschließende "Datei" ist nur erforderlich, sofern die .asc-Datei nicht denselben Namen (exklusive Suffix) hat, wie die
+
gpg --keyserver wwwkeys.de.pgp.net --send-keys 0x77421F4F
signierte Datei. In dem konkreten Beispiel ist es also nicht erforderlich.
+
  
==Dateiverschlüsselung==
+
Hiermit wird der Schlüssel zuerst vom Schlüsselserver heruntergeladen, dann der Revoke-Key importiert, und der Schlüssel wieder auf den Schlüsselserver geladen. Dadurch, dass die Schlüsselserver sich untereinander recht schnell synchronisieren, dauert es nur einige Minuten, und der Key ist auf allen Servern als ungültig vermerkt.
Um eine Datei zu verschlüsseln brauchen wir die Datei, die an den Partner versendet werden soll und dessen öffentlichen Schlüssel.
+
$ gpg --encrypt -a --recipient KeyId Datei
+
  
Der Gegenüber entschlüsselt die entstandene Datei ''Datei.asc'' dann folgendermaßen:
+
Eine andere Möglichkeit ist, die Ablaufdaten möglichst zeitnah zu setzen, sodass die Keys automatisch ungültig werden. Dies resultiert zwar darin, dass man häufiger einen neuen Schlüssel erstellen muss, man läuft aber nicht Gefahr, dass ein längst nicht mehr verwendeter Schlüssel noch als Gültig geführt wird.
$ gpg --decrypt --output Datei Datei.asc
+
und erhält damit die entschlüsselte Datei in der Datei ''Datei'' (:D).
+
  
==Siehe auch==
+
== Siehe auch ==
[[Grundlagen der Verschlüsselung in Netzwerken]]
+
* [[Grundlagen der Verschlüsselung in Netzwerken]]
  
[[Jabber]]
+
== Weblinks ==
 +
* [http://www.gnupg.org/ Website von GnuPG] {{sprache|en}}
 +
* [http://enigmail.mozdev.org/home/index.php Enigmail, GnuPG-Verschlüßselung für Thunderbird] {{sprache|en}}
 +
* [http://de.wikibooks.org/wiki/GnuPG GnuPG auf Wikibooks] {{sprache|de}}
  
 
[[Kategorie:Netzwerk]]
 
[[Kategorie:Netzwerk]]

Version vom 26. Juni 2009, 13:09 Uhr

GnuPG ist ein Kryptografieprogramm zur Signierung, Verschlüsselung und Entschlüsselung von Daten. Die Möglichkeiten GPGs belaufen sich unter anderem auf Verschlüsselung und Signierung von E-Mails, Chats und Dateien.

Installation

GnuPG ist im „extra“-Repository verfügbar und kann aus diesem mittels [Pacman] installiert werden.

pacman -Sy gnupg

Funktionsweise

GnuPG funktioniert mit Hilfe eines Schlüsselpaars, bestehend aus einem privaten Schlüssel, der nicht veröffentlicht wird, und einem öffentlichen Schlüssel, der an die Kommunikationspartner weitergegeben wird. Daten werden mit dem öffentlichen Schlüssel verschlüsselt, und können nur vom Besitzer des Privaten Schlüssels wieder entschlüsselt werden (asymmetrische Verschlüsselung).

Erzeugen eines Schlüsselpares

Zum Verwenden muss man erstmalig eine Schlüsselpaar erzeugen.

gpg --gen-key

Es müssen dann einige Daten angegeben werden. Man sollte hier, wenn man einen „offiziellen“ Schlüssel erstellen will, seine richtigen Daten angeben. Wenn man anonym bleiben will, kann man hier selbstvertändlich beliebige Fantasiedaten angeben.

pub  1024D/77421F4F 2000-06-25 Vorname Nachname (Kommentar) <user@example.org>
    Key fingerprint = CB84 AD4C 2195 FFAD ACA0  471B 468F 3FF9 0781 DF4A
sub  1024g/C596B611 2000-06-25

Die Schlüssel-ID ist 77421F4F. Dies ist die hexadezimale Kennung des Schlüssels. Diese sollte bei der Eingabe in Programme immer mit „0x“ eingeleitet werden.

Verbreitung der Schlüssel

Schlüssel können auf sogenannte Schlüsselserver geladen werden. Dort ist es anderen möglich diese Schlüssel beispielsweise anhand der E-Mailadresse oder auch der Schlüssel-ID zu finden und herunterzuladen.

Um den Schlüssel hoch- oder herunter zuladen benutzt man „gpg“ mit entsprechenden Parametern

gpg --send-keys 0x77421F4F
gpg --recv-keys 0xDED070DE 

Es wird der im Generierungsbeispiel erstellte Schlüssel auf einen Schlüsselserver geladen, danach wird ein anderer Schlüssel von einem Schlüsselserver heruntergeladen.

Man muss hier jedoch jeweils mittels des parameters „--keyserver“ noch explizit einen zu verwendenen Schlüsselserver angeben. Will man dies nicht, muss man den zu verwendenen Schlüsselserver in die GnuPG-Konfigurationsdatei „~/.gnupg/options“ schreiben

keyserver wwwkeys.de.pgp.net

Hier wird der Schlüsselserver „wwwkeys.de.pgp.net“ verwendet.

Das praktische an der Schlüsselserver-Methode ist, dass man den Key direkt importiert. Der Nachteil ist natürlich, dass man in aller Regel nicht immer die KeyID parat hat. Dafür ist eine Suchfunktion über einen Browser erreichbar. Hier kann man sich die Keys als klartext anzeigen und herunterladen. Um einen heruntergeladenen Key nun noch zu importieren, ist ein:

$ gpg --import KeyFile

erforderlich. Wobei „KeyFile“ den über den Browser heruntergeladenen, öffentlichen Schlüssel beinhalten muss.

Dateisignaturen

Mittels GnuPG können auch Dateien signiert werden. So kann man sehr einfach einen Dateiaustausch betreiben, und der Empfänger kann sich sicher sein, von wem die Datei kommt.

gpg --armor --detach-sign Dateiname

Hiermit wird die Datei „Dateiname“ Signiert. Es wird eine Datei „Dateiname.asc“ erstellt, in der sich die Signatur befindet. Möchte man die Signatur an das Dateiende hängen, ist dies ebenfalls möglich.

gpg --clearsign -a Dateiname

Dieses Vorgehen ist allerdings nur bei Klartextdateien zu empfehlen, weil Binärdateien danach aller Regel nach solange unbrauchbar sind, bis die Signatur wieder entfernt wird.

gpg --verify Dateiname.asc Dateiname

Hiermit wird die Datei „Dateiname“ anhand der Signaturdatei „Dateiname.asc“ verifiziert.ein. Die Angabe der Datei, die verifiziert werden soll, ist nur erforderlich, sofern die .asc-Datei nicht denselben Namen hat, wie die signierte Datei. In dem konkreten Beispiel ist es also eigentlich nicht erforderlich.

Dateiverschlüsselung

Dateien können nicht nur Signiert, sondern auch Verschlüsselt werden.

gpg --encrypt -a --recipient KeyId Dateiname

Als „KeyId“ muss die Schlüssel-ID desjenigen angegeben werden, der die Datei „Dateiname“ später mit seinem Privaten schlüssel entschlüsseln soll. Entschlüßselt werden Dateien wie folgt.

gpg --decrypt --output Dateiname Dateiname.asc 

Ungültigkeitsvorbehalt

Dieser Schlüssel ist, wenn nicht anders definiert, unbegrenzt lange gültig. Um einen schlüssel vor Ablauf der Gültigkeitsdauer für ungültig erklären zu können, muss ein Widerrufszertifikat, der „Revoke Key“, erstellt werden.

gpg --gen-revoke 0x77421F4F > revokeKey

Im Beispiel wird das Widerrufszertifikat für den oben generierten Schlüssel erstellt. Hat man den Schlüssel beispielsweise auf einen Schlüsselserver geladen, kann man ihn in diesem Fall im Allgemeinen nicht direkt wieder löschen. Hier kommt das Widerrufszertifikat zum tragen.

gpg --keyserver wwwkeys.de.pgp.net --recv-keys 0x77421F4F
gpg --import revokeKey
gpg --keyserver wwwkeys.de.pgp.net --send-keys 0x77421F4F

Hiermit wird der Schlüssel zuerst vom Schlüsselserver heruntergeladen, dann der Revoke-Key importiert, und der Schlüssel wieder auf den Schlüsselserver geladen. Dadurch, dass die Schlüsselserver sich untereinander recht schnell synchronisieren, dauert es nur einige Minuten, und der Key ist auf allen Servern als ungültig vermerkt.

Eine andere Möglichkeit ist, die Ablaufdaten möglichst zeitnah zu setzen, sodass die Keys automatisch ungültig werden. Dies resultiert zwar darin, dass man häufiger einen neuen Schlüssel erstellen muss, man läuft aber nicht Gefahr, dass ein längst nicht mehr verwendeter Schlüssel noch als Gültig geführt wird.

Siehe auch

Weblinks