5 ms·

GnuPG – post-quantum crypto landing in mainline

174 points by zdkaster 5mo ago

zdkaster 5mo ago
GnuPG Version 2.5.19 The 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.
utopiah 5mo ago
> 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.
- BoppreH 5mo ago
  It reminds me a lot of Y2K. The fix is simple, but finding the places where it's needed and doing it in a compatible way are absolutely non-trivial problems. The best we can hope is the same as Y2K: the plethora of articles convince businesses to invest large amounts of money to migrate algorithms, so that when a quantum computer arrives it won't be a big deal.
  - CatMustard 5mo ago
    > it won't be a big deal. This isn't a space I know too much about, but even if we all start using quantum-safe encryption for everything today, won't the arrival of quantum computers that can break traditional encryption not still be a big deal? Given that intelligence agencies, tech companies and various bad actors have been storing encrypted data for a long time, hoping to decrypt when (if?) that day comes?
    - BoppreH 5mo ago
      Definitely, but then the damage is limited to the encrypted data that those actors managed to intercept some years before. Compared to QC arriving to an unprepared world, that's a very limited impact.
    - parsimo2010 5mo ago
      Intelligence agencies and companies for which industrial espionage is an actual concern will re-encrypt their data storage, or have already done so. The only risk is on data that was already obtained with a vulnerable encryption. So there is some risk that a few secrets are lost, but it won’t be everything. And if you were to start now and quantum decryption isn’t viable for a decade then any secrets that do get exposed are surely less of a problem than if they were discovered today.
    - utopiah 5mo ago
      Sure it's still a big deal but it's not as if suddenly everybody get a quantum computer and can use it nilly-willy. It will be (or is) scarce enough that information has to be selected as critical in order to be deciphered a posteriori. The time between the moment the information is recorded and when it's deciphered is what matters, rarely the information itself abstracted from all context. So even if suddenly having a classical cryptography is broken, trivially, then there still need to be a way to search through it. Typically for a random person that means their credit card pin and their email password for example. Well, you chance that and if, say the NSA, can decipher your old email password even 1 minute after you changed it, no big deal. If they can decipher your old emails it might be a big deal but probably not. I would argue it depends on actionable information (e.g. a coup happening tomorrow) and legal information (e.g. the proof that a certain person was an informant and should be extradited). So... I would argue historically, huge deal, daily life... probably not much for most.
dsecurity49 5mo ago
[dead]
- jore 5mo ago
  I haven’t heard this quote before, but I am copying it here because it makes so much sense: Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden
- gtsnexp 5mo ago
  [flagged]
  - dsecurity49 5mo ago
    [dead]
- pabs3 5mo ago
  IIRC the GnuPG folks do a lot of consulting and sell additional software: https://gnupg.org/service.html https://gnupg.org/service.html https://gnupg.com/ https://gnupg.com/ https://g10code.com/ https://g10code.com/
- snthpy 5mo ago
  And they use SHA-1 for verification?
  - noosphr 5mo ago
    If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.19.tar.bz2 you would use this command: gpg --verify gnupg-2.5.19.tar.bz2.sig gnupg-2.5.19.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.19.tar.bz2, you run the command like this:
trueno 5mo ago
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?
- d1sxeyes 5mo ago
  Basically the idea is use hybrid. AES-GCM-256 or ChaCha20-Poly1305 for symmetric encryption (which is already PQ-safe), and ML-KEM looks set to become the standard for key encapsulation. ML-KEM-768 is fast as an algorithm, faster than X25519 in terms of pure computation, but uses large keys, so has higher overheads on small payloads. Most of the time, they’re about equal, or the absolute time is so slow it doesn’t matter. Most folks now are doing hybrid ML-KEM and X25519 to guard against undiscovered flaws in ML-KEM.
  - purplehat_ 5mo ago
    For people reading this, you may want to know the the NSA is allegedly trying to weaken hybrid ML-KEM and X25519 down to just ML-KEM. This is a good thing to pay attention to! Here is a 6-part article about the topic: https://blog.cr.yp.to/20251004-weakened.html https://blog.cr.yp.to/20251004-weakened.html
    - deleted 5mo ago
      [deleted]
    - throw0101a 5mo ago
      > Here is a 6-part article about the topic: https://blog.cr.yp.to/20251004-weakened.html https://blog.cr.yp.to/20251004-weakened.html * https://news.ycombinator.com/item?id=45477206 https://news.ycombinator.com/item?id=45477206 * https://news.ycombinator.com/item?id=45477206#unv_45477799 https://news.ycombinator.com/item?id=45477206#unv_45477799 See various "NSA and IETF": * https://news.ycombinator.com/from?site=cr.yp.to https://news.ycombinator.com/from?site=cr.yp.to
    - tptacek 5mo ago
      I haven't met a single cryptographer who takes this series of posts seriously and if you have I'd love to talk to them.
immanuwell 5mo ago
cool, now my emails that nobody's reading anyway are safe from quantum computers that don't exist yet
- PunchyHamster 5mo ago
  it's mostly to make clowns repeating "It's not PQ secure therefore bad" happy I think
aborsy 5mo ago
Does it implement the hybrid version ML-KEM-768 + X25519 or ML-KEM-768 only ? The X25519 key could remain in hardware keys for a while til manufactures catch up.
- darkamaul 5mo ago
  If I understood the code correctly, it always use the hybrid version. > Kyber is always used in a composite scheme along with a classic ECC algorithm.
sipsi 5mo ago
[flagged]
growse 5mo ago
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. https://floss.social/@hko/116459621169318785 https://floss.social/@hko/116459621169318785
- capitol_ 5mo ago
  As far as I understood it: GnuPG started to implement stuff from the standard before it was finished, the standard continued to improve and GnuPG refused to change code already written. Combined with some personal drama.
  - em-bee 5mo ago
    it's not that simple. the new standard is a complete rewrite of the old one. they are not even compatible anymore. things the old standard used to support are not supported in the new standard. that makes any implementation of the new standard incompatible with implementations of the old one. GnuPG simply refused to stop supporting the old standard and decided to fork the standard itself. on the personal drama my interpretation is that it resulted from people backing the new standard being unhappy that GnuPG didn't go along. my opinion is that rewriting standards like that is the result of design by committee. everyone wants to put their mark on it. designing a new standard is fine, but the new standard should have also received a new name, or it should at least have been acknowledged that the old standard still needs to be supported until enough time has passed that the old standard is no longer in use. (which could take decades if not more if we want to be realistic and consider that encrypted data at rest could linger around pretty much forever unless actively re-encoded.) (source: i talked to a GnuPG developer)
    - singpolyma3 5mo ago
      LibrePGP is also a rewrite. To keep supporting legacy v4 you have to keep having v4 code no matter if the new thing you add is v5 (LibrePGP) or V6 (the RFC)
Hendrikto 5mo ago
[flagged]
- LtWorf 5mo ago
  I see it as the usual push from sw companies to replace important copyleft projects with company directed ones with business-friendly (user unfriendly) licenses.
- em-bee 5mo ago
  woha, this is totally twisted and the opposite of what really happened: https://news.ycombinator.com/item?id=47909640 https://news.ycombinator.com/item?id=47909640 GnuPG did not unilaterally implement new non-OpenPGP formats. it kept supporting the old version of the OpenPGP standard. it unilaterally decided to NOT CHANGE its implementation. it's not trying to derail anything. the lack of engagement came from everyone else refusing to listen to the idea that you can't just break compatibility like that.
  - Hendrikto 5mo ago
    > source: i talked to a GnuPG developer Of course they would say that. See also the responses to your comment: > My honest first reaction to this statement would get me permabanned from this site, so here’s the polite version: > This is nonsense on stilts. It is so ill-informed and baseless I struggle to understand how anyone who has read the RFCs in question could possibly come to this conclusion. It is hooey.
    - em-bee 5mo ago
      i have addressed some of the issues raised in a comment here: https://news.ycombinator.com/item?id=48058065 https://news.ycombinator.com/item?id=48058065 i hope you'll notice this reply and get a chance to read it.
tokenhub_dev 5mo ago
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.
- BoppreH 5mo ago
  Some Hardware Security Module manufacturers were smart enough to include FPGAs in their products, which they can now use to accelerate PQC algorithms without a hardware refresh. The trouble is that PQC already has inherent size/performance downsides, and it won't benefit from the decades of optimizations that classical algorithms had. Expect a hefty performance tax for some time.
maqp 5mo ago
Could we finally get SHA256 fingerprints. Or BLAKE2, or SHA3-256, or SHAKE256, or BLAKE3, or LITERALLY ANYTHING BUT SHA-1, pretty please?
- upofadown 5mo ago
  Yes. Both standards proposals have SHA256 fingerprints. Not that there is anything wrong with SHA1 fingerprints in practice. The sort of collisions that SHA1 is susceptible to are not an issue in this particular application. With SHA256 fingerprints people would still be using 64 bit key IDs, just like they are doing now.
  - Valodim 5mo ago
    Rfc9580 is not a proposal anymore, it's a published RFC. (I suppose strictly speaking it's still a "proposed standard" vs "internet standard", but so is basically everything else)
  - maqp 5mo ago
    Thank goodness. Finally. Yeah I'm just not comfortable with 80-bit complexity against Grover, even if it's practically infeasible.
Malcomwillis21 5mo ago
[dead]
Gergerobert 5mo ago
[dead]
kstzv 5mo ago
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?
em-bee 5mo ago
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 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 changes to are very interesting but pretty baseless. i mean how do you even make a claim that the codebase is full of assumptions and premature optimisations? what is the evidence for this claim? same for lack of tests. a claim like that would be very easy to verify. so please show your evidence, and don't make up stuff. in my opinion this whole controversy is caused by people not listening to each other, and it is embellished by people who only follow one side of the argument and take everything that side claims as the truth. i am not exactly neutral myself, as i consider the GnuPG devs my friends, but i have a strong interest in resolving conflicts and misunderstandings and harmonizing different viewpoints. so i hope that my comments here are not adding fuel to the fire, but rather help to douse out the fire or at least cool it down. it is also my hope that at some point in the future the differences between the new OpenPGP RFC and LibrePGP can be resolved, and the standards can be merged. (i don't know, it might be as simple as reinstating support for the old key format). forking a project in the face of controversy is not unknown in the FOSS community. it famously happened with GCC for example and a few other well known projects, which managed to overcome their differences and merge again. but to make this happen we need to stop throwing around accusations and actually listen to people to learn the reasons for their choices and opinions. as long as we fight, we will just hinder each other in making progress. only if we collaborate and resolve our differences are we able to learn from our mistakes and move forward. this, btw, is the mantra that i live for, and this is why i chose to get involved in this discussion. please share this comment with anyone who needs to see it.

174 points by zdkaster 5mo ago

GnuPG Version 2.5.19 The 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.

utopiah 5mo ago

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

BoppreH 5mo ago
It reminds me a lot of Y2K. The fix is simple, but finding the places where it's needed and doing it in a compatible way are absolutely non-trivial problems. The best we can hope is the same as Y2K: the plethora of articles convince businesses to invest large amounts of money to migrate algorithms, so that when a quantum computer arrives it won't be a big deal.
- CatMustard 5mo ago
  > it won't be a big deal. This isn't a space I know too much about, but even if we all start using quantum-safe encryption for everything today, won't the arrival of quantum computers that can break traditional encryption not still be a big deal? Given that intelligence agencies, tech companies and various bad actors have been storing encrypted data for a long time, hoping to decrypt when (if?) that day comes?
  - BoppreH 5mo ago
    Definitely, but then the damage is limited to the encrypted data that those actors managed to intercept some years before. Compared to QC arriving to an unprepared world, that's a very limited impact.
  - parsimo2010 5mo ago
    Intelligence agencies and companies for which industrial espionage is an actual concern will re-encrypt their data storage, or have already done so. The only risk is on data that was already obtained with a vulnerable encryption. So there is some risk that a few secrets are lost, but it won’t be everything. And if you were to start now and quantum decryption isn’t viable for a decade then any secrets that do get exposed are surely less of a problem than if they were discovered today.
  - utopiah 5mo ago
    Sure it's still a big deal but it's not as if suddenly everybody get a quantum computer and can use it nilly-willy. It will be (or is) scarce enough that information has to be selected as critical in order to be deciphered a posteriori. The time between the moment the information is recorded and when it's deciphered is what matters, rarely the information itself abstracted from all context. So even if suddenly having a classical cryptography is broken, trivially, then there still need to be a way to search through it. Typically for a random person that means their credit card pin and their email password for example. Well, you chance that and if, say the NSA, can decipher your old email password even 1 minute after you changed it, no big deal. If they can decipher your old emails it might be a big deal but probably not. I would argue it depends on actionable information (e.g. a coup happening tomorrow) and legal information (e.g. the proof that a certain person was an informant and should be extradited). So... I would argue historically, huge deal, daily life... probably not much for most.

dsecurity49 5mo ago

[dead]

jore 5mo ago
I haven’t heard this quote before, but I am copying it here because it makes so much sense: Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden
gtsnexp 5mo ago
[flagged]
- dsecurity49 5mo ago
  [dead]
pabs3 5mo ago
IIRC the GnuPG folks do a lot of consulting and sell additional software: https://gnupg.org/service.html https://gnupg.org/service.html https://gnupg.com/ https://gnupg.com/ https://g10code.com/ https://g10code.com/
snthpy 5mo ago
And they use SHA-1 for verification?
- noosphr 5mo ago
  If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.19.tar.bz2 you would use this command: gpg --verify gnupg-2.5.19.tar.bz2.sig gnupg-2.5.19.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.19.tar.bz2, you run the command like this:

trueno 5mo ago

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?

d1sxeyes 5mo ago
Basically the idea is use hybrid. AES-GCM-256 or ChaCha20-Poly1305 for symmetric encryption (which is already PQ-safe), and ML-KEM looks set to become the standard for key encapsulation. ML-KEM-768 is fast as an algorithm, faster than X25519 in terms of pure computation, but uses large keys, so has higher overheads on small payloads. Most of the time, they’re about equal, or the absolute time is so slow it doesn’t matter. Most folks now are doing hybrid ML-KEM and X25519 to guard against undiscovered flaws in ML-KEM.
- purplehat_ 5mo ago
  For people reading this, you may want to know the the NSA is allegedly trying to weaken hybrid ML-KEM and X25519 down to just ML-KEM. This is a good thing to pay attention to! Here is a 6-part article about the topic: https://blog.cr.yp.to/20251004-weakened.html https://blog.cr.yp.to/20251004-weakened.html
  - deleted 5mo ago
    [deleted]
  - throw0101a 5mo ago
    > Here is a 6-part article about the topic: https://blog.cr.yp.to/20251004-weakened.html https://blog.cr.yp.to/20251004-weakened.html * https://news.ycombinator.com/item?id=45477206 https://news.ycombinator.com/item?id=45477206 * https://news.ycombinator.com/item?id=45477206#unv_45477799 https://news.ycombinator.com/item?id=45477206#unv_45477799 See various "NSA and IETF": * https://news.ycombinator.com/from?site=cr.yp.to https://news.ycombinator.com/from?site=cr.yp.to
  - tptacek 5mo ago
    I haven't met a single cryptographer who takes this series of posts seriously and if you have I'd love to talk to them.

immanuwell 5mo ago

cool, now my emails that nobody's reading anyway are safe from quantum computers that don't exist yet

PunchyHamster 5mo ago
it's mostly to make clowns repeating "It's not PQ secure therefore bad" happy I think

aborsy 5mo ago

Does it implement the hybrid version ML-KEM-768 + X25519 or ML-KEM-768 only ? The X25519 key could remain in hardware keys for a while til manufactures catch up.

darkamaul 5mo ago
If I understood the code correctly, it always use the hybrid version. > Kyber is always used in a composite scheme along with a classic ECC algorithm.

sipsi 5mo ago

[flagged]

growse 5mo ago

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. https://floss.social/@hko/116459621169318785 https://floss.social/@hko/116459621169318785

capitol_ 5mo ago
As far as I understood it: GnuPG started to implement stuff from the standard before it was finished, the standard continued to improve and GnuPG refused to change code already written. Combined with some personal drama.
- em-bee 5mo ago
  it's not that simple. the new standard is a complete rewrite of the old one. they are not even compatible anymore. things the old standard used to support are not supported in the new standard. that makes any implementation of the new standard incompatible with implementations of the old one. GnuPG simply refused to stop supporting the old standard and decided to fork the standard itself. on the personal drama my interpretation is that it resulted from people backing the new standard being unhappy that GnuPG didn't go along. my opinion is that rewriting standards like that is the result of design by committee. everyone wants to put their mark on it. designing a new standard is fine, but the new standard should have also received a new name, or it should at least have been acknowledged that the old standard still needs to be supported until enough time has passed that the old standard is no longer in use. (which could take decades if not more if we want to be realistic and consider that encrypted data at rest could linger around pretty much forever unless actively re-encoded.) (source: i talked to a GnuPG developer)
  - singpolyma3 5mo ago
    LibrePGP is also a rewrite. To keep supporting legacy v4 you have to keep having v4 code no matter if the new thing you add is v5 (LibrePGP) or V6 (the RFC)

Hendrikto 5mo ago

[flagged]

LtWorf 5mo ago
I see it as the usual push from sw companies to replace important copyleft projects with company directed ones with business-friendly (user unfriendly) licenses.
em-bee 5mo ago
woha, this is totally twisted and the opposite of what really happened: https://news.ycombinator.com/item?id=47909640 https://news.ycombinator.com/item?id=47909640 GnuPG did not unilaterally implement new non-OpenPGP formats. it kept supporting the old version of the OpenPGP standard. it unilaterally decided to NOT CHANGE its implementation. it's not trying to derail anything. the lack of engagement came from everyone else refusing to listen to the idea that you can't just break compatibility like that.
- Hendrikto 5mo ago
  > source: i talked to a GnuPG developer Of course they would say that. See also the responses to your comment: > My honest first reaction to this statement would get me permabanned from this site, so here’s the polite version: > This is nonsense on stilts. It is so ill-informed and baseless I struggle to understand how anyone who has read the RFCs in question could possibly come to this conclusion. It is hooey.
  - em-bee 5mo ago
    i have addressed some of the issues raised in a comment here: https://news.ycombinator.com/item?id=48058065 https://news.ycombinator.com/item?id=48058065 i hope you'll notice this reply and get a chance to read it.

tokenhub_dev 5mo ago

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.

BoppreH 5mo ago
Some Hardware Security Module manufacturers were smart enough to include FPGAs in their products, which they can now use to accelerate PQC algorithms without a hardware refresh. The trouble is that PQC already has inherent size/performance downsides, and it won't benefit from the decades of optimizations that classical algorithms had. Expect a hefty performance tax for some time.

maqp 5mo ago

Could we finally get SHA256 fingerprints. Or BLAKE2, or SHA3-256, or SHAKE256, or BLAKE3, or LITERALLY ANYTHING BUT SHA-1, pretty please?

upofadown 5mo ago
Yes. Both standards proposals have SHA256 fingerprints. Not that there is anything wrong with SHA1 fingerprints in practice. The sort of collisions that SHA1 is susceptible to are not an issue in this particular application. With SHA256 fingerprints people would still be using 64 bit key IDs, just like they are doing now.
- Valodim 5mo ago
  Rfc9580 is not a proposal anymore, it's a published RFC. (I suppose strictly speaking it's still a "proposed standard" vs "internet standard", but so is basically everything else)
- maqp 5mo ago
  Thank goodness. Finally. Yeah I'm just not comfortable with 80-bit complexity against Grover, even if it's practically infeasible.

Malcomwillis21 5mo ago

[dead]

Gergerobert 5mo ago

[dead]

kstzv 5mo ago

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?

em-bee 5mo ago

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 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 changes to are very interesting but pretty baseless. i mean how do you even make a claim that the codebase is full of assumptions and premature optimisations? what is the evidence for this claim? same for lack of tests. a claim like that would be very easy to verify. so please show your evidence, and don't make up stuff. in my opinion this whole controversy is caused by people not listening to each other, and it is embellished by people who only follow one side of the argument and take everything that side claims as the truth. i am not exactly neutral myself, as i consider the GnuPG devs my friends, but i have a strong interest in resolving conflicts and misunderstandings and harmonizing different viewpoints. so i hope that my comments here are not adding fuel to the fire, but rather help to douse out the fire or at least cool it down. it is also my hope that at some point in the future the differences between the new OpenPGP RFC and LibrePGP can be resolved, and the standards can be merged. (i don't know, it might be as simple as reinstating support for the old key format). forking a project in the face of controversy is not unknown in the FOSS community. it famously happened with GCC for example and a few other well known projects, which managed to overcome their differences and merge again. but to make this happen we need to stop throwing around accusations and actually listen to people to learn the reasons for their choices and opinions. as long as we fight, we will just hinder each other in making progress. only if we collaborate and resolve our differences are we able to learn from our mistakes and move forward. this, btw, is the mantra that i live for, and this is why i chose to get involved in this discussion. please share this comment with anyone who needs to see it.