Der GPG-Unterschlüssel scheint ein anderes Passwort zu haben

Der GPG-Unterschlüssel scheint ein anderes Passwort zu haben

Ich habe vor kurzem mit Thunderbird einen neuen OpenGPG-Schlüssel erstellt und ihn exportiert, um ihn mit GPG zu verwenden. Allerdings kann ich außerhalb von Thunderbird nichts entschlüsseln, da mein Unterschlüssel – der zur Verschlüsselung verwendet wird – anscheinend durch eine andere Passphrase geschützt ist als mein Primärschlüssel.

Wenn ich versuche, die Passphrase für den Schlüssel zu ändern, werde ich aufgefordert, meine aktuelle Passphrase für den ersten Schlüssel (FF120B...) einzugeben, und dann gebe ich eine neue Passphrase ein, nichts Ungewöhnliches. Danach werde ich jedoch weiter aufgefordert, eine Passphrase für meinen Unterschlüssel (ABC1AA...) einzugeben, die ich nicht kenne.

ich habe gelesenHier, dass es nicht möglich ist, individuelle Passphrasen für Unterschlüssel einzurichten. Was könnte also der Grund für dieses Problem sein?

>gpg --expert --edit-key 3A069C...
gpg (GnuPG) 2.2.25; Copyright (C) 2020 g10 Code GmbH
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  ed25519/FF120B...
     created: 2020-11-25  expires: 2024-11-24  usage: SC
     trust: ultimate      validity: ultimate
ssb  cv25519/ABC1AA...
     created: 2020-11-25  expires: 2024-11-24  usage: E
[ultimate] (1). Name <email>

gpg>

Antwort1

Das ist ein etwasbekannter Fehlerund hat eineFixin der noch nicht veröffentlichten Version v0.16.0 der von Thunderbird verwendeten RNP-Bibliothek.

Ich habe es geschafft, den Schlüssel zu importieren, indem ich

  • RNP selbst bauen nachhttps://github.com/rnpgp/rnp/blob/master/docs/installation.adoc
  • Wird verwendet rnpkeys --import <input-file.asc>, um die beschädigte Exportdatei zu importieren und die Schlüssel-Hashes anzuzeigen.
  • Mit rnpkeys --edit-key --check-cv25519-bits <hash-of-broken-subkey>wird der falsche Schlüssel bestätigt.
  • Wird verwendet rnpkeys --edit-key --fix-cv25519-bits <hash-of-broken-subkey>, um den falschen Schlüssel zu korrigieren.
  • Ich verwende es rnpkeys --export-key --secret --output <output-file.asc> <hash-of-primary-key>, um einen funktionierenden Schlüssel zu exportieren, den ich jetzt problemlos verwenden kann.

verwandte Informationen