Betamax v. VHS, and the future of PQ-PGP

[Robert J. Hansen]

> A disquisition could here ensue on the long-term security reasons why 
> everyone should start using ky1024_cv448 encryption subkeys RIGHT NOW.

This could only be true if everyone holds to a threat model in which 
their data being collected by the MDR and potentially decrypted by a 
First World nation-state actor is a risk that needs mitigation.  Most of 
us do not.

If you're a Linux distribution that uses a new distro signing key every 
year, then who really cares if someone in ten years breaks this year's 
key?  What will they do with it, release a kernel patch for a system so 
old no one is using it and forge a timestamp so old everyone wonders why 
no one ever saw this patch before?

MDRs are definitely a risk for some people and groups.  They are not a 
universal risk necessitating immediate change.  Few things are.

Don't pull a Chicken Little, please.  The sky is not falling.  Claims to 
the contrary are unwise, scaremongering, and unprofessional.

> Fifty years ago, a format war was brewing between the videocassette 
> formats Betamax and VHS...

Betamax and VHS were competing for the pool of money found in the home 
video recorder market.  The market was posed for explosive growth, and 
whoever became the dominant role in the early moments would reap more 
from the ensuing explosion.  Those were the incentives driving action. 
You are describing the battle; I am describing why the battle existed.

None of this applies to GnuPG.

GnuPG is not competing for a pool of money.  It seeks to be a high 
quality implementation of the RFC4880 standard and subsequent LibrePGP 
standards.  That's it.  It's not in competition with any other group, 
not BouncyCastle, not Sequoia, nothing.  It's in competition with 
itself.  So long as Werner sees merit in the LibrePGP standard, he'll 
keep working to provide a high quality implementation of it.

> The standards split will foreseeably lead to a world in which your 
> choice of \*PGP software determines with whom you can exchange post- 
> quantum encrypted mail.

Ludicrous.  Absurd.  Ridiculous.  These are not words I use lightly. 
These are words I use because this claim is all of those.

Assuming you're right and the worst case scenario does come to pass and 
your choice of software determines with whom you can communicate, well...

... how is that different from today?

To demonstrate, this message is signed with my S/MIME certificate.  I 
use Thunderbird.  It lets me easily choose between competing email 
cryptography packages.  If I have to add a third possible suite, I'm 
sure Thunderbird will make that easy, too.  I'm sure you've noticed it 
wasn't any inconvenience for you to verify my signature, either.

> The lowest common denominator will remain plain ECC or RSA, as it 
 > is today.  That’s bad.

Why?  Breaking RSA-4096 via Shor's algorithm is straight out of science 
fiction.  It requires 8k qubits for the computation alone: once you take 
into account error correction, 40k or more qubits, all in an ensemble 
with a decoherence time orders of magnitude beyond what we have today. 
Go, check out how many qubits we have today, and project out into the 
future how long we have.

You are looking at Goddard's rocket and talking about the urgent need to 
establish our mining claims in the asteroid belt right now before all 
the good sites are taken.  Relax.  Slow down.  Goddard's rocket is 
really cool and yes, someday we'll be living in The Expanse mining 
asteroids.  But that's a long way off.

Incidentally, I call dibs on Cruithe.

> In 2025, it is *unethical and irresponsible* to publish any encryption 
> software or offer an encrypted communication service that does not 
> support post-quantum cryptography.

Let me get this straight: you believe Signal is acting unethically and 
irresponsibly by giving people a superb and secure alternative to SMS 
messaging, just because they don't support PQC.

You literally believe that.

I hope to be as unethical and irresponsible as them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4583 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250102/5e5c9c45/attachment-0001.bin>