Ich habe gerade einen neuen Schlüssel generiert mit
gpg --schnell-Schlüssel generieren
Wenn ich das jetzt tue,
gpg --list-keys[email geschützt]
Ich bekomme so etwas:
pub rsa2048 2020-01-29 [SC] [expires: 2022-01-28]
DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF
uid [ultimate] [email protected]
sub rsa2048 2020-01-29 [E]
aber wenn ich das mache:
gpg --edit-key[email geschützt]
Ich erhalte ungefähr Folgendes:
gpg (GnuPG) 2.2.17; Copyright (C) 2019 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 rsa2048/DEADBEEFDEADBEEF
created: 2020-01-29 expires: 2022-01-28 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/BEEFDEADBEEFDEAD
created: 2020-01-29 expires: never usage: E
[ultimate] (1). [email protected]
Ich dachte, dass ich das Konzept von Schlüsseln und Unterschlüsseln zumindest teilweise verstanden hätte, aber das ergibt für mich immer noch keinen Sinn.
- Warum zeigt die Ausgabe in einem Fall öffentliche Schlüssel und im anderen Fall geheime Schlüssel an?
- Wie kommt es, dass ein öffentlicher Schlüssel ( ) im ersten Fall
pubals signierfähig ( ) angezeigt wird und ein geheimer Schlüssel ( ) im zweiten Fall als verschlüsselungsfähig ( ) angezeigt wird? Widerspricht das nicht dem, was wir in Public Key Crypto 101 gelernt haben?SssbE
Antwort1
Warum zeigt die Ausgabe in einem Fall öffentliche Schlüssel und im anderen Fall geheime Schlüssel an?
Ich würde vermuten, dass der Befehl in GnuPG 2.1+ --edit-keygeheime Schlüssel anzeigt, weil er das schon immer getan hat.
Damals in GnuPG 1.x (und ähnlich im ursprünglichen PGP 2.x) gab es zwei völlig getrennte Schlüsselringe (Pubring und Secring). Manche Operationen funktionierten mit dem einen und manche mit dem anderen. Es --list-secret-keyswar also genau wie früher, --list-keysaußer dass es aus einer anderen Datei las und --edit-keyseinen Unterbefehl hatte, der zwischen den beiden Ansichten wechselte.
Wie kommt es, dass ein öffentlicher Schlüssel (pub) im ersten Fall als signierfähig (S) angezeigt wird und ein geheimer Schlüssel (ssb) im zweiten Fall als verschlüsselungsfähig (E) angezeigt wird? Widerspricht das nicht dem, was wir in Public Key Crypto 101 gelernt haben?
Nein. Die Ausgabe beschreibt einen „Schlüssel“ wie im PGP-Objekt – nicht einen „Schlüssel“ im rein kryptographischen Sinn – und die Verwendungsflags beschreiben, um welche PGP-Operationen es sich handelt.gemeintverwendet werden, nicht nur, welche Kryptooperationen der „innere“ Schlüssel mathematisch ausführen kann. Das heißt, sie ändern sich nicht, je nachdem, ob Sie die öffentliche oder die private Hälfte betrachten.
Beispielsweise enthält Ihr Beispiel-PGP-Schlüsselblock zwei RSA-Schlüsselpaare, und beide könnten technisch gesehen sowohl signieren/verifizieren als auch verschlüsseln/entschlüsseln. Aber der ganze Sinn der beiden besteht darin, dass Sie ihre Zwecke getrennt halten möchten – d. h. Sie möchten nicht, dass GnuPG die Verschlüsselung mit einem Unterschlüssel durchführt, der zum Signieren gedacht ist, also filtern die Verwendungsflags ihn heraus.
(Für „Entschlüsseln“ bzw. „Überprüfen“ gibt es kein separates Flag, da in der Nachricht bzw. Signatur bereits angegeben ist, welcher Schlüssel dafür zu verwenden ist.)
Dies bedeutet auch, dass es mehrere Verwendungsflags geben kann, die demselben Vorgang (Signieren oder Überprüfen) entsprechen, jedoch in unterschiedlichen Kontexten:
- „S“ ermöglicht die Verwendung des Schlüssels zum Signieren von Nachrichten und Dateien (E-Mails usw.);
- „C“ erlaubt die Verwendung des Schlüssels zum Signieren (Zertifizieren) anderer Schlüssel/Unterschlüssel;
- Mit „A“ kann der Schlüssel zum Signieren von Authentifizierungsaufforderungen verwendet werden (wie bei TLS oder SSHv2).
Obwohl alle drei im kryptologischen Sinne die gleiche Art digitaler Signaturen erstellen, sind die Schlüssel selbst aus Sicherheitsgründen oft getrennt. (Beispielsweise sollte der Zertifizierungsschlüssel viel stärker geschützt sein als der Authentifizierungsschlüssel.)