EXPKEYSIG - Error GPG key Whonix

Support
14

Why the key expired? It was an oversight.

Given the current state of available resources, I am not a fan of any kind of legacy / oldstable support. However, in decide availability of Kicksecure, and Whonix 18 (Debian trixie based) on Qubes R4.2 versus R4.3 · Issue #10219 · QubesOS/qubes-issues · GitHub I got a request to do this in Qubes and concluded “it’s simple enough”, since CVEs in Kicksecure / Whonix haven’t been recorded yet. Formally saying “we push a security upgrade for the unlikely case that someone reports a security bug against oldstable” seemed simple enough.

However, once a new stable version is released, I am using that new version and not oldstable. So all my focus shifts to the new stable version.

And there isn’t a contributor spending brain cycles on oldstable making sure it keeps churning around. I don’t have any free mental bandwidth to keep oldstable in mind.

Size “for the most part” doesn’t matter.

Someone posted an SSH private key as example on the internet. (Source: [1]) It’s even shorter.

# cat .ssh/id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABClhk1367
G8CQYpo/0c7UShAAAAZAAAAAEAAAAzAAAAC3NzaC1lZDI1NTE5AAAAIIJiwIymcly4s66p
za/IL3ZNyT5CiMPj0R+/LnMDmABUAAAAoMJIakdbIL7TOAmX8n4xGSrtp8mc/Mr6qimZAZ
zGB7iRhNUXT+isPdf0YuC9mh5NbX43ZYFl+/sWdi2hVmJxbGTwrjaSdNzF3ZnSpi/aVlzF
t3bUCtdwhHLaLqy9unw0zPHlfcQsB700GS/bf4VKRmm1+imj3cAldUm2RF3VdI0U9/04yX
Mj+VBOmevM0i7R/0d6xUFTH3zj99xxeLI2J6A=
-----END OPENSSH PRIVATE KEY-----

Or even more beautiful in cryptocurrency there are mnemonic phrases. Example [2]:

hotel obvious agent lecture gadget evil jealous keen fragile before damp clarify

These are literally used to protect value worth millions of $ USD. These short keys aren’t considered factor X less secure just because they are factor X smaller in size than OpenPGP.

Debian trixie comes with gpg version 2.4, a newer version than previously. Gpg 2.4 introduced a lot of improvements. Among these are “v5 keys”.

I didn’t investigate the file size of the key. Instead, I assumed that gpg was previously less optimized for small key sizes because it’s a much older project that was invented long before very short yet very secure keys were common. Now it has improved with more space efficient encoding.

I only checked that the key fingerprint is the same, that signing/encrypting/decryption is functional, and that third-party signatures on the key are being retained and still verifiable. Only a basic functionality test, not a deep dive into the internals of gnupg.

An expected reply could be “but you should have checked that”. I am afraid, this isn’t how this works. For instance, if you asked the gnupg developers if they fully understand and regularly audit the Linux kernel or the C compiler - because if these were backdoored, then their work would be in vain - I suspect the answer would also be “no”. There’s a number of issues making a full end-to-end audit unrealistic.

So realistically, what one can do is either a deep dive and become a cryptographer, or more or less trust that the cryptographers do an okay job in the field of cryptography.

Also applicable:

Same key fingerprint, different expiration date.

It’s the very same key.

Non-technical users often struggle with these concepts. This is complicated stuff, and as early as 1999 the Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0 paper has been published.

That’s why it’s worded kinda nebulously:

Users can check Kicksecure Signing Key for better security.

The word “can” was deliberately chosen to make it optional. Perhaps it should say “Optional: Advanced Users can …” instead. It’s not very realistic for non-technical users to grasp this. Why that is so, see:

It used to happen only when the key got extended, which wasn’t for every release.

[1] https://stackoverflow.com/questions/49083709/how-to-convert-ed25519-private-key-to-putty-ppk
[2] https://bitcoinwiki.org/wiki/mnemonic-phrase

1 Like