> introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption
algorithm
Funny to read 1-liner changelog versus the plethora of articles just few years ago along the line of "Quantum computer, it might just change our entire lives and make privacy impossible!".
The simple addition (of a not so simple algorithm) to the software (and few others, e.g. OpenSSL) and voila, me can move on with our daily lives. Cryptography and computational complexity are truly amazing.
been thinking about this a bit. someone just tell me what algo to use and ill start using it now. are the quantum-resistant cryptos significantly slower?
I don't know enough about either the technical nuance or the political drama, but some observers have noted that GnuPG's implementation is (deliberately?) incompatible with the IETF's standards. It's not clear why.
Short version: Werner Koch personally hates some people involved with the RFC9580 standardization, and cannot emotionally bear working with anything even loosely associated. He also struggled accepting anyone's opinion but his own while editor of the draft back then.
Search for "asking the editor to step down" to find the moment when the working group decided he was more trouble than it's worth (and GnuPG's support was obviously worth a lot in the openpgp community).
For people wondering whether to migrate now: the practical question isn't "is a CRQC imminent" (it isn't), it's whether your encrypted messages have a useful lifetime longer than the optimistic deployment timeline.
If you encrypt a one-off email with a 5-year confidentiality requirement, harvest-now-decrypt-later actually matters. If you're encrypting backups that get rotated every 90 days, it doesn't.
The hybrid construction (Kyber/ML-KEM + X25519) is nice precisely because it's a no-regret move — you don't lose anything by adopting early. If Kyber turns out to have a structural flaw, X25519 still protects you. If a CRQC arrives, ML-KEM still protects you. The only real cost is key/ciphertext size, which for OpenPGP isn't a hot path anyway.
The interesting question is what happens to long-lived smartcard/HSM-backed keys. Those typically have a 5–10 year lifecycle and most hardware won't grow ML-KEM support without a hardware refresh. That's where I'd expect the first real compatibility headaches.
Does ML-KEM support all three NIST security levels (512/768/1024) in this integration? And is there any hardware acceleration planned or used for NTT, or is it purely software-based for now?
in some of the comments here accusations have been made against GnuPG and their developers. one of the comments has been flagged and killed. i had the opportunity to talk to one developer for a few hours and learn a few things. there are still some open questions, but i want to do some research of my own before i talk to them again. let me share what i learned so far. since this response is addressing points made in various comments i decided to post it as a top level comment without quotes, just writing what i found out.
someone asked me to name the developer i talked to. i won't do that because in the past devs have been verbally attacked and threatened. justified or not, this is not acceptable behavior, and i am not going to expose anyone to that.
on the question of LibrePGP being the work of one person, i already mentioned that i found that the old OpenPGP RFC 4880 is 90% unchanged in LibrePGP. turns out it goes even further. almost all of the LibePGP RFC was already created by the OpenPGP committee. until some people pushed for massive changes. it was only at that point that werner koch decided to fork the standard and publish the old, already agreed upon, almost ready for publication, version of OpenPGP as LibrePGP with minimal changes. so this whole idea that LibrePGP is the work of one person is simply not true. this is documented in the timeline on https://librepgp.org/#timeline
the key issue with the new OpenPGP standard is not the changes in the supported crypto standards, but the incompatible key format, including the removal of the old keyformat. think about this for a moment please. clearly crypto algorithms need to be revised and improved over time, but there should be very little need to revise the key format, and especially remove support for the old format. i haven't verified this, but with the support for an old format gone, any old documents written in that format can no longer be decrypted by software following the new standard. the unreasonableness of this change is likely what set werner off, because he could not possibly remove support for the old format from GnuPG without breaking things for almost every user.
LibrePGP therefore is not an incompatible fork of OpenPGP, but OpenPGP RFC5980 is an incompatible revision of OpenPGP RFC4880 and of the latest consensus before people decided to massively change the OpenPGP RFC.
on the claim that GnuPG keeps silently releasing 2.2 versions, there is a simple explanation for that: GnuPG 2.2 is certified by the German Federal Office for Information Security (BSI). until a new version of GnuPG gets that certification, certain institutions that require this certification are not able to upgrade. think of 2.2 as an LTS release only intended for those that need it. there is nothing malicious about it, and insinuating that stopping support for 2.4 is in bad faith when 2.2 is still supported is simply missing the point. projects that have LTS releases do that all the time.
that mentioned refusal to backport something to 2.4 was not a refusal but an oversight. it has since been fixed.
the issue with the supposedly removed systemd support was a surprise to the person i talked to. but he could not confirm either way. we'll research that and follow up (feel free to email me if there is no reply here before the time to reply expires in two weeks. my email is in the profile). what my contact did tell me is that the systemd integration somehow made it more difficult to use GnuPG without that integration on machines running systemd. i didn't quite understand why though. if i learn more about this, i'll post it.
claims that the problem is the age of gnupg's codebase, which supposedly bakes in a lot of assumptions and premature optimisations, and which also supposedly doesn't have any unit tests or continuous integration, that it's a codebase that few outsiders understand and which few insiders are confident about making major ...
16 comments
[ 2.7 ms ] story [ 48.0 ms ] threadThe 2.5 series are improvements for 64 bit Windows and the introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption algorithm.
The old 2.4 series reaches end-of-life in just two months.
Funny to read 1-liner changelog versus the plethora of articles just few years ago along the line of "Quantum computer, it might just change our entire lives and make privacy impossible!".
The simple addition (of a not so simple algorithm) to the software (and few others, e.g. OpenSSL) and voila, me can move on with our daily lives. Cryptography and computational complexity are truly amazing.
The X25519 key could remain in hardware keys for a while til manufactures catch up.
https://floss.social/@hko/116459621169318785
Search for "asking the editor to step down" to find the moment when the working group decided he was more trouble than it's worth (and GnuPG's support was obviously worth a lot in the openpgp community).
If you encrypt a one-off email with a 5-year confidentiality requirement, harvest-now-decrypt-later actually matters. If you're encrypting backups that get rotated every 90 days, it doesn't.
The hybrid construction (Kyber/ML-KEM + X25519) is nice precisely because it's a no-regret move — you don't lose anything by adopting early. If Kyber turns out to have a structural flaw, X25519 still protects you. If a CRQC arrives, ML-KEM still protects you. The only real cost is key/ciphertext size, which for OpenPGP isn't a hot path anyway.
The interesting question is what happens to long-lived smartcard/HSM-backed keys. Those typically have a 5–10 year lifecycle and most hardware won't grow ML-KEM support without a hardware refresh. That's where I'd expect the first real compatibility headaches.
someone asked me to name the developer i talked to. i won't do that because in the past devs have been verbally attacked and threatened. justified or not, this is not acceptable behavior, and i am not going to expose anyone to that.
on the question of LibrePGP being the work of one person, i already mentioned that i found that the old OpenPGP RFC 4880 is 90% unchanged in LibrePGP. turns out it goes even further. almost all of the LibePGP RFC was already created by the OpenPGP committee. until some people pushed for massive changes. it was only at that point that werner koch decided to fork the standard and publish the old, already agreed upon, almost ready for publication, version of OpenPGP as LibrePGP with minimal changes. so this whole idea that LibrePGP is the work of one person is simply not true. this is documented in the timeline on https://librepgp.org/#timeline
the key issue with the new OpenPGP standard is not the changes in the supported crypto standards, but the incompatible key format, including the removal of the old keyformat. think about this for a moment please. clearly crypto algorithms need to be revised and improved over time, but there should be very little need to revise the key format, and especially remove support for the old format. i haven't verified this, but with the support for an old format gone, any old documents written in that format can no longer be decrypted by software following the new standard. the unreasonableness of this change is likely what set werner off, because he could not possibly remove support for the old format from GnuPG without breaking things for almost every user.
LibrePGP therefore is not an incompatible fork of OpenPGP, but OpenPGP RFC5980 is an incompatible revision of OpenPGP RFC4880 and of the latest consensus before people decided to massively change the OpenPGP RFC.
on the claim that GnuPG keeps silently releasing 2.2 versions, there is a simple explanation for that: GnuPG 2.2 is certified by the German Federal Office for Information Security (BSI). until a new version of GnuPG gets that certification, certain institutions that require this certification are not able to upgrade. think of 2.2 as an LTS release only intended for those that need it. there is nothing malicious about it, and insinuating that stopping support for 2.4 is in bad faith when 2.2 is still supported is simply missing the point. projects that have LTS releases do that all the time.
that mentioned refusal to backport something to 2.4 was not a refusal but an oversight. it has since been fixed.
the issue with the supposedly removed systemd support was a surprise to the person i talked to. but he could not confirm either way. we'll research that and follow up (feel free to email me if there is no reply here before the time to reply expires in two weeks. my email is in the profile). what my contact did tell me is that the systemd integration somehow made it more difficult to use GnuPG without that integration on machines running systemd. i didn't quite understand why though. if i learn more about this, i'll post it.
claims that the problem is the age of gnupg's codebase, which supposedly bakes in a lot of assumptions and premature optimisations, and which also supposedly doesn't have any unit tests or continuous integration, that it's a codebase that few outsiders understand and which few insiders are confident about making major ...