gpg2: kein geheimer Schlüssel

15598
rexroni

Ich habe enigmail seit über einem Jahr ohne Probleme verwendet und heute funktioniert es nicht.

Ich habe folgende interessante Tatsache gefunden:

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

Also ist mit gpg Version 2 auf meinem Rechner etwas kaputt.

Das brachte mich dazu, das zu sehen:

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 gpg2kann der geheime Schlüssel nicht gefunden werden, da er in der falschen Datei sucht.

Wie kann ich gpg2versagen, wenn meine gpgArbeit gut läuft? Ich sehe keine Optionen, um anzugeben, woher die geheimen Schlüssel gelesen werden.

Hat jemand Ideen?

Antwort auf @grawity :

Vielen Dank für Ihre Hilfe. Ich lief straceund ich sehe, worüber du redest.

Aber auch nachdem gpg2 --import ...ich keinen Unterschied im Verhalten sehe. Ich kann es nur dann zum Laufen bringen gpg2 --import ..., wenn ich einen Neustart durchführe (ohne den gpg-agent zu starten), und erst dann ausführen gpg2 --decrypt .... Nach dieser Sequenz verhält sich auch Thunderbird + Enigmail gut. Nach ungefähr 15 Minuten (meine Vermutung ist das zum Entschlüsseln eingegebene Passwort abgelaufen), gpg-agentist das alte Verhalten dann wieder hergestellt. 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
17
Hast du das am Ende gelöst? Ich habe genau das gleiche Problem. Volker vor 7 Jahren 0
Trotzdem habe ich es repariert. Das für die Verwendung von 'gpg-agent' und das Programm 'pinentry' musste auf 'pinentry-gtk-2' gesetzt werden. Bevor es auf "pinentry-gnome3" gesetzt war, das auf meinem System vorhanden war, funktionierte es nicht. Ich musste `pinentry-gtk-2` manuell installieren. Volker vor 7 Jahren 0

2 Antworten auf die Frage

18
grawity

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

Das ist nicht die einzige Datei, die es betrachtet.

In GnuPG 1.x (und 2.0) hatte das "Secring" früher eine doppelte Kopie der öffentlichen Daten Ihres Keyblocks, so dass es vollständig in sich geschlossen war (und der einzige Unterschied zwischen gpg -kund gpg -Kwar, welche Datei es lesen würde)., aber gleichzeitig schwieriger für das Programm zu halten.

In GnuPG 2.1 werden geheime Schlüssel jetzt unabhängig voneinander gespeichert - sie werden vom gpg-agent verwaltet, der sie aufbewahrt ~/.gnupg/private-keys-v1.d/. Also müssen beide gpg -kund gpg -Kjetzt die OpenPGP-Informationen aus dem Pubring lesen, aber der letztere fragt gpg-agent zusätzlich, welche Zertifikate geheimen Schlüsseln zugeordnet sind. Wenn Sie strace verwenden, sollten Sie connect()unmittelbar nach dem Lesen des Pubs einen Anruf bemerken.

Wenn GnuPG die Schlüssel nicht automatisch migriert, importieren Sie einfach die gesamte Verschlüsselung direkt:

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

So prüfen Sie den Inhalt des Agenten manuell:

$ gpg-connect-agent  > keyinfo - list 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 > / tschüss  $

Dies sind "Keygrips" - vergleichen Sie sie mit der GnuPG-Verschlüsselung:

$ gpg --list-secret-keys --with-keygrip /home/fred/.gnupg/pubring.kbx -------------------------------- sec ed25519 2018-08-18 [SC] 2357E133AD5D24F6CB2C1B0CEF4F7ED27E252632 Keygrip = 4D29EF1460F164CDB11D0FC0247214660ACDD60F  uid [ultimativ] Fred Foobar <fred@example.com>
Ich hatte das gleiche Problem: Ich habe versucht, einen Schlüssel zu generieren, der "gpg --gen-key" verwendet, den ich mit "gopass" verwenden wollte. Leider verwendet `gopass`` gpg2` ... `gpg2 --import` hat wie ein Zauber funktioniert! Vielen Dank! andiba vor 6 Jahren 0
Für mich hat `gpg2 --import ~ / .gnupg / pubring.gpg` das Problem behoben. Dilawar vor 6 Jahren 0
Du bist mein Held Lo-Tan vor 6 Jahren 0
1
rexroni

Schließlich entschied ich, dass das Problem darin bestand, dass ich Debian Unstable verwende und dass ein Versionskonflikt von einem eingeführt wurde apt-get dist-upgrade. Ich nehme an, deshalb nennen sie es "Unstable".

Ich habe es auch in Ubuntu LTS. Nach dem Umstieg von Ubuntu Unity auf GNOME. nerdoc vor 6 Jahren 0

Verwandte Probleme