Current private PGP key got lost
Categories
(MailNews Core :: Security: OpenPGP, defect)
Tracking
(Not tracked)
People
(Reporter: fbrenk, Unassigned)
Details
(Keywords: regression, Whiteboard: [regression 91.7->91.8])
Attachments
(1 file)
|
25.92 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
Steps to reproduce:
Sending e-mails results in error message "no valid private pgp key available" since yesterday.
I am running TB on different computers with the same pgp keys (3x Windows 10 Home 21H2 or 21H1, 3x openSuSE Leap 15.3, 1x MacOS Monterey). My profile-folder does not reside in the usual "user"-folder (regarding Windows) but on drive d:.
openSuSE Linux doesn't seem to be affected so far.
I did not have the chance to check MacOS yet.
Actual results:
My current private PGP-key (valid until 2023) got lost within my Windows 10 setup! There is only an outdated key available in TB currently from 2020. This means that I can't sign my e-mails anymore, neither encrypt.
It's also not possible to import the key from an existing backup (no error message).
PGP key was originally created in 2007 and extended several times within recent years.
Expected results:
My setup has been working fine initially since the migration to built in pgp encryption (and even before for years with Enigmail add-on and Kleopatra).
Comment 1•4 years ago
|
||
Is the key using SHA-1? Bug 1763641
Comment 3•4 years ago
|
||
Same problem here after update to version 91.8.0 (64-Bit) (using ubuntu 18.04 LTS as OS but not the distro version of thunderbird) with most of my round about 100 private keys. The keys just lost the information about the existing expiry extensions.
When I try to extend the expiration again I get the "openpgp-cannot-change-expiry" message ("This is a key with a complex structure, changing its expiry date isn’t supported.")
Seems that my key mostly use the following specs.
Algorithm: RSA
Key length: 4096
Would be great to get at least an explanation for this phenomenon.
Comment 4•4 years ago
|
||
Please check whether your keys use SHA-1 hash algorithm for self-signatures (especially the latest one). Not sure how to do that with Kleopatra, but with GnuPG you may use gpg --list-packets your-key.asc, and look for digest algo: 2 (or post listing here, removing all the privacy-sensitive information).
Comment 5•4 years ago
|
||
...explanation is available here: https://bugzilla.mozilla.org/show_bug.cgi?id=1763641#c5
Comment 6•4 years ago
|
||
Thanks for your help @Nickolay Olshevsky.
I had to search for 'algo: 9' instead of 'algo: 2'. But with that I found out, that this keys really are based on SHA1.
I used the following line in terminal:
gpg --list-packets your-key.asc | grep "algo: 9"
and got the following result
iter+salt S2K, algo: 9, SHA1 protection, hash: 8, salt: 1111111111111111
iter+salt S2K, algo: 9, SHA1 protection, hash: 8, salt: 2222222222222222
Good to know that the keys where still based on SHA1 and of course I will now change that.
But I would suggest that Thunderbird offers some more specific information about what is happening. I guess there aren't a lot of 'normal' users that search for responses in Bugzilla - or even know what SHA1 is and how using may be a security risk.
Comment 8•4 years ago
|
||
Thanks for the dump.
S2K text is a bit different - it tells which algo and hash is used to encrypt secret key/derive encrypting key from the password.
Offending signatures should be as following:
:signature packet: algo 17, keyid BC6278A552423440
version 4, created 1578763389, md5len 0, sigclass 0x13
digest algo 2, begin of digest 8e 9a
hashed subpkt 27 len 1 (key flags: 23)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 25 len 1 (primary user ID)
hashed subpkt 33 len 21 (issuer fpr v4 39FC1BBFD3F83FDFBBA99BA0BC6278A552423440)
hashed subpkt 2 len 4 (sig created 2020-01-11)
hashed subpkt 9 len 4 (key expires after 15y79d9h32m)
subpkt 16 len 8 (issuer key ID BC6278A552423440)
data: [160 bits]
data: [160 bits]
digest algo 2 means SHA1, and sig was created at 2020-01-11 (Current TB version allows SHA1 sigs created before the 2019-01-15).
Could you please also specify for which email key doesn't work, i.e. fbrenk at gmx, or felix.brenk at gmx, or both? At the current logic of RNP at least first one should work.
| Reporter | ||
Comment 10•4 years ago
|
||
Is there a guide available about how to convert my keys to SHA-2? Or is this not possible?
| Reporter | ||
Comment 11•4 years ago
|
||
| Reporter | ||
Comment 12•4 years ago
|
||
I just updated my keys according to this digest (with openSuSE Linux 15.3). In Kleopatra they seem to look fine. But in Thunderbird I can't import them (TB has its own key management when I am right?) - no specific error-message.
While Uploading to the keyserver I get this error-message:
"Die Ausgabe von /usr/bin/gpg2 lautet: gpg: WARNUNG: Unsichere Zugriffsrechte des Home-Verzeichnis `/home/fips/.gnupg' gpg: sende Schlüssel CEF760F286FAEF27 auf hkps://hkps.pool.sks-keyservers.net gpg: Senden an Schlüsselserver fehlgeschlagen: Server zeigt einen unbestimmten Fehler "
After a reboot I couldn't log in to openSuSE until I restored the .gnupg directory with the old settings.
WHAT DO YOU THINK ABOUT THAT?
| Reporter | ||
Comment 13•4 years ago
|
||
Key still seems to contain algo 2?
| Reporter | ||
Comment 14•4 years ago
|
||
Problem solved: there is no gpg.conf. in standard installation. So I edited gpg-agent.conf instead. With Windows 10 this resulted in an error-message while starting Kleopatra. With correct gpg.conf everything is fine now as described by Heise.de. At least with Windows. I will check Linux later on...
| Reporter | ||
Comment 15•4 years ago
|
||
Linux is OK, too.
| Reporter | ||
Comment 16•4 years ago
|
||
We have got a discussion in the TB-forum: is it really necessary to build a completely new key with no SHA-1? I would rather like to keep my key from 2007 in order to decrypt older mails?
Comment 17•4 years ago
|
||
(In reply to Felix B. from comment #9)
The key doesn't work for both addresses.
Thanks for replying. Re-checked - it is intended behaviour due to the SHA-1 deprecation.
We have got a discussion in the TB-forum: is it really necessary to build a completely new key with no SHA-1? I would rather like to keep my key from 2007 in order to decrypt older mails?
This is not neccessary due to SHA-1, since you may generate new self-signature with stronger hash algorithm, extending key expiration. However, you should generate newer key as your old key is a 1024-bit RSA key, which is not considered as strong enough nowadays.
| Reporter | ||
Comment 18•4 years ago
|
||
Thank you!
Comment 19•2 years ago
|
||
I assume the issue has been fixed for everyone in newer Thunderbird versions.
| Reporter | ||
Comment 20•2 years ago
|
||
Issue has been fixed! TB is working fine currently on all platforms.
Description
•