Beim Entschlüsseln der Datei wird versucht, einen Unterschlüssel zu verwenden. Anschließend wird der Fehler 'Kein geheimer Schlüssel' angezeigt

422
Noobux

Verwenden von: gpg (GnuPG) 2.0.22 libgcrypt 1.5.3

Ich versuche, eine Datei von einem entfernten Standort zu entschlüsseln. Ich habe unseren Schlüssel in eine Datei exportiert. gpg <filename>Rückgabe: (Schlüssel-IDs geändert)

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

Ich schickte es an den Absender und bat sie, es zu importieren, zu unterschreiben und ihm zu vertrauen.

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

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

Wenn ich einen Edit-Key mache, 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

Folgendes ist 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) <usrname@domain.com>" gpg: public key decryption failed: Operation cancelled gpg: decryption failed: No secret key

Meine Schlussfolgerung daraus ist, dass der Absender mir seinen öffentlichen Schlüssel in dem Format senden muss, das ich ihm gesendet habe. Sowie:

pub 2048R/J561VE25 2015-09-23

sub 2048R/SOM3NUMB 2015-09-23

Meiner Meinung nach hatten die Schlüsseldateien, die sie mir geschickt haben, nicht die entsprechenden Informationen zu pub / sub und daher kann gpg nicht überprüft werden, da ich nur einen Teil der Informationen ihres Schlüsselpaars habe.

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

Vielen Dank!

0

2 Antworten auf die Frage

0
grawity 
Version: GnuPG v1.2.4 (MingW32)

heilige BälleDas ist alt - Version 1.2.4 wurde 2003 veröffentlicht . Der Absender kümmert sich nicht besonders darum, seine Sicherheitssoftware zu aktualisieren, wie es scheint.

(Ihre eigene 2.0.22 ist mit dem Veröffentlichungsdatum 2013 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 Schlüsselpaar "main" wird nur zum Signieren (auch als Zertifizieren bezeichnet) anderer Schlüssel verwendet. oft auch zum Signieren von Nachrichten. Es ist nicht für die Verschlüsselung verwendbar - Sie haben immer einen Unterschlüssel für diesen Zweck.

(Die Trennung ermöglicht auch Dinge wie das Offline-Signieren oder häufige Rotation des Verschlüsselungsschlüssels.)

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

Es scheint, als ob GnuPG versucht hat, eine Passphrasen-Eingabeaufforderung anzuzeigen, um das Schlüsselpaar zu entsperren, aber entweder das Passphrasen-Fenster konnte nicht geöffnet werden oder Sie haben es versehentlich abgebrochen.

Die Passwortabfrage wird durch die GnuPG- Komponente pinentry angezeigt, die selbst über den gpg-agent gestartet wird . Ich weiß nicht genau, wo ich das Problem unter Windows beheben sollte - vielleicht würde eine neuere Version 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 die Pinentry- Komponente arbeiten kann. Wenn das Upgrade nicht von alleine hilft, aktivieren Sie diese Option.

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

Der öffentliche Schlüssel des Senders ist für die Entschlüsselung unbrauchbar und nur für die Signaturprüfung erforderlich.

Sowie:

pub 2048R/J561VE25 2015-09-23

Meiner Meinung nach hatten die Schlüsseldateien, die sie mir geschickt haben, nicht die entsprechenden Informationen zu pub / sub und daher kann gpg nicht überprüft werden, da ich nur einen Teil der Informationen ihres Schlüsselpaars habe.

Nein. Diese Information ist für Sie als Benutzer gedacht. Sie enthält eine Zusammenfassung des Schlüsseltyps, der kurzen (nutzlosen) ID und des Ablaufdatums. GnuPG kann es sehr gut aus dem Schlüssel selbst extrahieren, nicht so, dass es nötig ist.

0
Noobux

Nach vielem Hin und Her fand ich die Lösung in zwei Änderungen.

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

  2. Der Drehbuchautor musste --batchseine Befehlszeile hinzufügen .

Nachdem dies erledigt war, konnte gpg zum geheimen Schlüssel gelangen und entschlüsseln.

Vielen Dank für die Antwort. Ihre Zeit wird geschätzt.

Verwandte Probleme