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 supp...@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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to