gpg2: kein geheimer schlüssel

Ich benutze Enigmail seit über einem Jahr ohne Probleme und heute funktioniert es nicht mehr.

Ich fand die folgende interessante Tatsache:

gpg --decrypt something.gpg # this works
gpg2 --decrypt something.gpg # this fails

Mit gpg Version 2 auf meinem Computer ist also etwas kaputt.

Das hat mich dazu gebracht zu sehen, dass:

gpg --list-secret-keys # reads from ~/.gnupg/secring.gpg
gpg2 --list-secret-keys # reads from ~/.gnupg/pubring.gpg (pubring?!) 

Dies scheint die Wurzel des Problems zu sein ... natürlich gpg2 kann den geheimen Schlüssel nicht finden, da er in der falschen Datei gesucht wird.

Wie könnte mein gpg2 scheitern, wenn meine gpg funktioniert gut? Ich sehe keine Optionen, um anzugeben, woher die geheimen Schlüssel gelesen werden.

Hat jemand irgendwelche Ideen?

Antwort auf @grawity :

Danke, ich danke Ihnen für Ihre Hilfe. ich rannte straceund ich verstehe, wovon du redest.

Jedoch auch danach gpg2 --import ... Ich sehe keinen Unterschied im Verhalten. Ich kann es nur zum Laufen bringen, wenn ich neu starte (ohne gpg-agent zu starten), laufe gpg2 --import ..., dann renne gpg2 --decrypt .... Nach dieser Sequenz verhält sich thunderbird + enigmail ebenfalls gut. Nach ungefähr 15 Minuten ist das zum Entschlüsseln eingegebene Passwort jedoch abgelaufen gpg-agent ist zurück zu seinem alten Verhalten. Diese Sequenz ist wiederholbar.

Hier ist also eine Ausgabe, wenn es hilft, etwas aufzuklären:

Ausgabe von gpg2 -K:

/home/<username>/.gnupg/pubring.gpg
---------------------------------
sec   rsa4096/AAAAAAAA <date> [SC]
uid         [ultimate] <description of me>
ssb   rsa4096/BBBBBBBB <date> [E]

Ausgabe von gpg-connect-agent

> keyinfo --list
S KEYINFO <keygrip associated with AAAAAAAA> D - - - P - - -
S KEYINFO <keygrip associated with BBBBBBBB> D - - - P - - -
OK

Ausgabe von gpg2 -v -r <my email> -e testfile

gpg: using PGP trust model
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: This key belongs to us
gpg: reading from 'testfile'
gpg: writing to 'testfile.gpg'
gpg: RSA/AES256 encrypted for: "BBBBBBBB <description of me>"

Ausgabe von gpg2 -v -d testfile.gpg

gpg: public key is BBBBBBBB
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: encrypted with 4096-bit RSA key, ID BBBBBBBB, created <date>
      "<description of me>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

… Natürlich kann gpg2 den geheimen Schlüssel nicht finden, weil er in der falschen Datei gesucht wird.

Das ist nicht das nur Datei, die es betrachtet.

In GnuPG 1.x (und 2.0) enthielt das "Secring" auch eine Kopie der öffentlichen Daten Ihres Schlüsselblocks, so dass es vollständig in sich geschlossen war (und der einzige Unterschied zwischen gpg -k und gpg -K war die Datei, die es gelesen hatte), aber gleichzeitig schwieriger für das Programm zu pflegen.

In GnuPG 2.1 werden geheime Schlüssel jetzt unabhängig voneinander gespeichert - sie werden von verwaltet gpg-agent , das hält sie in ~/.gnupg/private-keys-v1.d/. Also beides gpg -k und gpg -K Jetzt müssen die OpenPGP-Informationen aus dem Pubring gelesen werden, letzterer fragt aber zusätzlich nach gpg-agent über welche Zertifikate geheime Schlüssel zugeordnet sind. Wenn Sie verwenden strace solltest du a connect() Rufen Sie gleich nach dem Lesen der Kneipe an.

Wenn GnuPG die Schlüssel nicht automatisch migriert hat, importieren Sie einfach den gesamten Secring direkt:

gpg2 --import ~/.gnupg/secring.gpg

So überprüfen Sie den Inhalt des Agenten manuell:

 $ gpg-connect-agent 
 & gt; keyinfo - Liste  S KEYINFO 926145FFCA32B3E6E079A0CF73EA77C40733A349 D - - - P - - -
S KEYINFO BACFB81EAFC864F4AB2926E8B1F55AD579F78D1A D - - - P - - -
S KEYINFO FF3D1DD51B9C79E148CCCEA5F7F3E25EC96048B7 D - - - P - - -
S KEYINFO 4D29EF1460F164CDB11D0FC0247214660ACDD60F D - - - P - - -
S KEYINFO 06B13685B9AA429B9CABCE480930D74B991C8DF0 D - - - P - - -
S KEYINFO B28DB8D045654E8A6A40466A07FCD9E432935E29 D - - - P - - -
OK  & gt; /Tschüss 
 $ 

Dies sind "Schlüsselgriffe" - vergleiche sie mit GnuPGs Geheimnissen:

 $ gpg --list-secret-keys --with-keygrip  /home/fred/.gnupg/pubring.kbx
--------------------------------
sec ed25519 2018-08-18 [SC]
      2357E133AD5D24F6CB2C1B0CEF4F7ED27E252632
      Keygrip = 4D29EF1460F164CDB11D0FC0247214660ACDD60F
uid [ultimative] Fred Foobar & lt; fred@example.com> 

Schließlich entschied ich, dass das Problem darin bestand, dass ich Debian Unstable verwendete, und dass eine Versionsinkongruenz von a apt-get dist-upgrade. Ich nehme an, deshalb nennen sie es "instabil".