Beim Entschlüsseln der Datei wird versucht, einen Unterschlüssel zu verwenden, und es tritt der Fehler „Kein geheimer Schlüssel“ auf.

Question

Verwendet: gpg (GnuPG) 2.0.22 libgcrypt 1.5.3

Ich versuche, eine Datei von einer Remote-Site zu entschlüsseln. Ich habe unseren Schlüssel in eine Datei exportiert. gpg <filename>Gibt zurück: (Schlüssel-IDs geändert)

pub 2048R/656CC421 2018-04-19
sub 2048R/99F89J32 2018-04-19

Ich habe es an den Absender geschickt und ihn gebeten, es zu importieren, zu unterzeichnen und zu vertrauen.

Sie haben mir zwei verschiedene Schlüsseldateien geschickt. Die Verwendung gpg <filename>ergibt:

1. pub 2048R/62568LK1 2015-09-03

2. pub 2048R/J561VE25 2015-09-23

Wenn ich einen Editierschlüssel eingebe, erhalte ich Folgendes:

Mein Schlüssel:

Secret key is available.

pub 2048R/656CC421 created: 2018-04-19 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/99F89J32 created: 2018-04-19 expires: never usage: E
[ultimate] (1).

Ihre Schlüssel:

1. pub 2048R/62568LK1 created: 2015-09-23 expires: never usage: SCE
trust: full validity: full
[ full ] (1).

2. pub 2048R/99F89J32 created: 2015-09-03 expires: never usage: SC
trust: full validity: full
[ full ] (1).

Ich führe den Entschlüsselungsbefehl in einem Bash-Skript mit den folgenden Parametern aus.

echo $passphrase | /usr/bin/gpg --verbose --passphrase-fd 0 --no-tty --output $output_file --recipient myuser --decrypt $input_file

Nachfolgend sehen Sie die Ausgabe des Befehls:

Version: GnuPG v1.2.4 (MingW32)
gpg: armor header:
gpg: public key is 99F89J32
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19
"usrname (Description) <[email protected]>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

Meine Schlussfolgerung aus all dem ist, dass der Absender mir seinen öffentlichen Schlüssel im selben Format senden muss, in dem ich ihn gesendet habe. Zum Beispiel:

pub 2048R/J561VE25 2015-09-23

sub 2048R/SOM3NUMB 2015-09-23

Mein Gedanke ist, dass die Schlüsseldateien, die sie mir geschickt haben, nicht die entsprechenden Pub/Sub-Informationen enthalten und GPG sie daher nicht validieren kann, da ich nur über einen Teil der Informationen ihres Schlüsselpaars verfüge.

Kann mir jemand sagen, ob ich damit falsch liege oder ob meine Gedanken richtig sind?

Danke!

Answer 1

Version: GnuPG v1.2.4 (MingW32)

heilige Bälledas ist alt – Version 1.2.4 wurde veröffentlicht in2003. Dem Absender scheint die Aktualisierung seiner Sicherheitssoftware ziemlich egal zu sein.

(Ihre eigene Version 2.0.22 ist mit 2013 als Veröffentlichungsdatum nicht viel besser.)

gpg: public key is 99F89J32
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: using subkey 99F89J32 instead of primary key 656CC421

Das ist normal. Das „Haupt“-Schlüsselpaar wird nur zum Signieren (also Zertifizieren) anderer Schlüssel verwendet; oft auch zum Signieren von Nachrichten. Es kann nicht zum Verschlüsseln verwendet werden – für diesen Zweck haben Sie immer einen Unterschlüssel.

(Die Trennung ermöglicht außerdem Dinge wie die Offline-Signierung oder die häufige Rotation von Verschlüsselungsschlüsseln.)

gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19 "usrname (Description) <[email protected]>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

Klingt so, als ob GnuPG versucht hat, eine Passphrase-Eingabeaufforderung zum Entsperren anzuzeigendeinSchlüsselpaar, aber entweder konnte das Passphrase-Fenster nicht geöffnet werden oder Sie haben es versehentlich selbst abgebrochen.

Die Passwortabfrage wird von GnuPG angezeigt.PinnwandKomponente, die wiederum überGPG-Agent. Ich weiß nicht wirklich, wo ich mit der Fehlerbehebung unter Windows beginnen soll – vielleichteine neuere Versionwürde besser funktionieren. (Ihr GnuPG 2.0.22 wurde 2013 veröffentlicht.)

Neuere Versionen, beginnend mit GnuPG 2.1, unterstützen einen "Loopback Pinentry"-Modus, der ohne denPinnwandKomponente. Wenn das Upgrade allein nicht hilft, versuchen Sie, diese Option zu aktivieren.

dass der Absender mir seinen öffentlichen Schlüssel senden muss

Der öffentliche Schlüssel des Absenders ist für die Entschlüsselung nutzlos und wird nur zur Signaturüberprüfung benötigt.

Wie zum Beispiel:

pub 2048R/J561VE25 2015-09-23

Mein Gedanke ist, dass die Schlüsseldateien, die sie mir geschickt haben, nicht die entsprechenden Pub/Sub-Informationen enthalten und GPG sie daher nicht validieren kann, da ich nur über einen Teil der Informationen ihres Schlüsselpaars verfüge.

Nein. Diese Information ist gedacht fürDu, der Benutzer – es fasst den Typ des Schlüssels, die kurze (nutzlose) ID und das Ablaufdatum zusammen. GnuPG kann dies problemlos aus dem Schlüssel selbst extrahieren, aber das muss es nicht.

Answer 2

Nun, nach langem Hin und Her habe ich die Lösung in zwei Änderungen gefunden.

1. Die Datei gpg-agent.conf musste pinentry-program /usr/bin/pinentry-curseshinzugefügt werden.

2. Der Skriptautor musste --batchseine Befehlszeile ergänzen.

Sobald dies erledigt war, konnte gpg auf den geheimen Schlüssel zugreifen und die Verschlüsselung durchführen.

Vielen Dank an Grawity für die Antwort. Wir wissen Ihre Zeit zu schätzen.