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

[have at anonymous.sex]

A disquisition could here ensue on the long-term security reasons why 
everyone should start using ky1024_cv448 encryption subkeys RIGHT NOW.  
https://en.wikipedia.org/wiki/Massive_Data_Repository  But if you 
understand security well enough to read this list, why waste your time?  
Instead, let’s talk about format wars and network effects.

Fifty years ago, a format war was brewing between the videocassette 
formats Betamax and VHS.  Today, you can still find people debating on 
the Internet whether or not Betamax was technically superior, and why 
VHS won, and so forth.  For anyone who didn’t try both in the late 1970s 
to early 1980s, all that’s clear is that VHS (0) won decisively when it 
attained (1) network effects in the (2) consumer market.  The format war 
concluded when Sony, the producer of Betamax, adopted VHS themselves.

As we now enter the year 2025, a format war is brewing in PGP.  This 
message is not the place for me to opine on the technical merits of 
LibrePGP v. IETF OpenPGP, or whose fault the standards split is, or 
whether so-and-so is a very mean person or not.  Today, here and now, I 
am more worried about something else.

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.  The lowest common denominator will remain 
plain ECC or RSA, as it is today.  That’s bad.  For the sake of user 
security, one side or the other needs to win so decisively that its 
standard is universally adopted.

Ever since 1993, PGP has been driven by its individual users.  Although 
corporate security use is nice and important, and GnuPG has a key role 
in securing the open-source software supply chain, it’s reasonable to 
anticipate that the format war will be decided by keys in the wild:  Not 
merely which side has more users with keys, but which side has more 
significant keys for people *you* want to talk to privately.

The first mover has an advantage here...

In terms of user base, GnuPG was the first major \*PGP implementation to 
offer post-quantum encryption that you can actually use *right now*.  
Although this feature is still only in a “public testing” branch, GnuPG 
since v2.5.1 (2024-09-12) has supported “the final FIPS-203 and LibrePGP 
specifications”.[0]  For a \*PGP implementation, the long-term stability 
of keys and messages is obviously of paramount importance.

...and the first mover deserves to win on that basis alone.

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.  It’s interesting to see who’s been 
on top of this—or not.  If, after the long-delayed US NIST standards 
process, you offer encryption without PQ crypto as we enter 2025, then 
you should delete your git repositories and stop making crypto.

Most software features are a matter of user patience for added 
happiness.  PQC is a safety issue.  It’s a long-term safety issue that 
most users do not understand, and do not know how to evaluate.  The onus 
is on cryptographic software developers.

For better or for worse, everyone knew since 2022 that Kyber probably 
would be declared The Standard.  A draft standard was available in 2023, 
and a final standard in 2024.  There is no excuse to fail to offer users 
post-quantum protection in 2025.

GnuPG couldn’t move ahead with “nonstandard” PQC, as some others did 
with sntrup or Classic McEliece:  It needs to maintain stable long-term 
support for keys and messages.  It had draft Kyber support in May 2024, 
and final standard support in September, 30 days after the final 
standard was published.  That’s how to protect users.

So please, let’s see some usage.  Not only will that improve security, 
but it will establish a user base of keys in the wild—thus encouraging 
user demand for compatibility with GnuPG.

###

# Addendum

In preparation to send this message, I attempted to upload a 
post-quantum key created with GnuPG v2.5.1 to keys.openpgp.org.  The 
result of the POST to <https://keys.openpgp.org/upload/submit>:

>HTTP/2 400
>server: nginx/1.18.0
>date: Wed, 01 Jan 2025 23:02:25 GMT
>content-type: text/html; charset=utf-8
>content-length: 1839
>[...]
>
>[...]
>   <p><strong>Error</strong>: Parsing of key data failed.</p>
>[...]

I promptly reached out to support at keys.openpgp.org to ask when the 
infrastructure will support distribution of these keys to help users 
protect their long-term security.  I anticipate that the real answer 
will depend on when there are significant numbers of people trying to 
distribute their v5 packet format keys.

###

[0] https://lists.gnupg.org/pipermail/gnupg-announce/2024q3/000485.html

-- 
# Remember these on Wednesday, January 15, 2025:
https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html
https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce
https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250101/ff383b4d/attachment.sig>