Subkeys of type ECDH are not rekeyed when the private key is exported
Categories
(MailNews Core :: Security: OpenPGP, defect)
Tracking
(Not tracked)
People
(Reporter: jens, Unassigned)
Details
Attachments
(1 file)
861 bytes,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Steps to reproduce:
- In Thunderbird OpenPGP key management, create a new key pair for any identity. Select ECC as key type.
- Inspect the key and note that it contains a primary EDDSA subkey #K1 for signing, and a secondary ECDH subkey #K2 for encryption. (Note that while "complex key structures are unsupported", this is what Thunderbird itself has generated.)
- Export the private key through the appropriate command in the file menu.
- Enter a secure passphrase ("#P") for the exported key.
- Import the key into GPG, e.g. using latest Gpg4win's Kleopatra app.
Actual results:
While changing the key's passphrase, GPG will ask for two passphrases. First: for the primary subkey #K1; this key can be decrypted using passphrase #P chosen when the key was exported from Thunderbird. Second: for the encryption subkey #K2; this key CAN NOT be decrypted with #P, and GPG rejects #P as invalid, aborting after three attempts, showing in its log that private key material for #K2 was missing. (This is most likely refers to the decrypted key, which cannot be obtained from the encrypted key on disk because its encryption passphrase is unknown to the user.)
As documented, Thunderbird protects all PGP key material with a randomly generated passphrase #T that, in turn, is encrypted by the profile's master password. Given that #K2 can be used by Thunderbird to encrypt emails, was exported from Thunderbird's key store, but cannot be decrypted with the chosen passphrase #P, Thunderbird has either:
- not re-keyed #K2, decrypting with #T and encrypting with #P, during the export,
- mangled the ECDH subkey #K2 while encrypting it with #P,
- mistakenley used some other passphrase to encrypt #K2.
I have successfully reproduced this behaviour several times by creating ECC key pairs for "Test", "test@example.com" (sample attached below), as well as my actual identity (name: 10 characters, email: 15 characters). Keys for other names, e.g. "TEST - DO NOT USE", "example@example.com", as well as RSA keys, were exported correctly.
Expected results:
Thunderbird should have exported the previously generated ECC keypair so that all contained subkeys can be unlocked with the passphrase provided during the backup.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
This one is the duplicate of this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1713621
Comment 2•3 years ago
|
||
Thanks for the report. Sorry we haven't fixed it yet, but work is in progress, see the duplicate bug, and the discussion in the gnupg ticket (see bug 1713621 comment 7).
Description
•