How to be safe from quantum computing [LWN.net]

By Daroc Alden
August 24, 2026

Practical quantum computers have been ten years away for the last several decades. Now, however, it's beginning to look as though they will be possible in just a few years. Recent research with obfuscated results demonstrated much lower memory requirements to factor ECDSA keys on a quantum computer, with work by other researchers in the open more than halving memory use compared to the state of the art in 2023. At the same time, computer manufacturers are boasting quantum processors that retain viable superpositions over longer periods. Given how slowly software updates filter out to stable systems, it's worth looking at what configuration changes and protocol updates are needed to be safe from quantum computers now.

What is the threat?

Quantum computers are not faster than classical computers in general (although they can invert general black-box functions more quickly, which is important to some cryptographic applications). Rather, there are specific problems, such as integer factorization, that are believed to be difficult on classical computers that quantum computers can solve more efficiently. Unfortunately, much of our modern cryptographic infrastructure relies on the hardness of these problems.

Modern cryptography is generally divided into two areas: symmetric-key and non-symmetric-key cryptography. The former relies on all involved parties having a shared secret, and is not believed to be vulnerable to analysis by a quantum computer. The problem is obtaining a shared secret in the first place; users generally want to be able to connect to many different web sites, to exchange email with many different people, etc. Establishing a shared secret with each of them would be difficult.

This is where non-symmetric-key cryptography (also called public-key cryptography) comes in. These are cryptographic protocols that work without any shared secrets; instead, participants have a public key, which is known to the whole world, and a private key, which is known only to themselves. Encryption can be done with one of the keys, and then decryption is only possible with the other. Cryptographic signatures work by encrypting a known value with the private key, proving that whoever made the signature must have had the key. The security of these cryptosystems inherently depends on there being problems that are hard to solve with just the public key, but which become easy to solve with access to an additional piece of secret information.

The original public-key cryptosystem was RSA, which relies on the difficulty of factoring large numbers — a task that the scientific community theoretically knows how to do quickly on a quantum computer. Later, RSA was partially displaced by elliptic-curve cryptography, which relies on a closely related problem called the discrete log problem, but which uses much smaller keys.

Currently, the best publicly available quantum processor offers 1,121 physical qubits. IBM's published quantum-computing timeline promises that its Kookaburra processor, with 1,386 physical qubits, will be finished by the end of 2026. Even if the company is over-promising, the last few months have seen the best known quantum circuit for factoring ECDSA keys fall from 1,425 logical qubits to 1,154 logical qubits. But there is a difference between physical and logical qubits. Even the most well-isolated quantum computers are affected by noise from their environments, which adds error to the value of the computer's qubits that must be corrected or compensated for. The best known quantum error-correction techniques need about 500 physical qubits to emulate one logical qubit with reasonable fidelity; that number will go down with both additional algorithmic breakthroughs and better physical chips.

Inspired by this trend, for many years cryptographers have been working on other public-key cryptosystems based on problems that are not known to have an efficient solution on quantum computers. Recently, they've settled on and standardized a handful of cryptosystems that are believed to be robust enough for general use.

The challenge facing the open-source community, then, is deploying these new cryptosystems in all of the places that use public-key encryption and signing. Of these two tasks, encryption is more urgent: things being encrypted today may be attacked tomorrow, but signatures validated today can be trusted, because any quantum forgeries will occur in the future. Both use cases do need to be addressed eventually, however, and public-key cryptography comes up in a surprising number of places.

One slight wrinkle is that the newly invented quantum-resistant cryptosystems do not yet have a long track record of use. Cryptographers believe that they are secure, but there could turn out to be some flaw enabling classical or quantum computers to break them. While there is probably no harm in moving directly to post-quantum cryptography, the conservative approach is to use a hybrid scheme: encrypt things with both a well-known elliptic-curve cryptosystem and a newer post-quantum cryptosystem. As long as at least one of those encryption schemes remains secure, the whole construction is secure. Therefore, the encryption scheme that web browsers, OpenPGP implementations, and other encryption software are moving toward is a combination of ML-KEM-768 (the NIST-standardized post-quantum encryption scheme) and X25519 (an elliptic-curve cryptosystem in wide use today). Various government agencies have pushed for allowing the use of non-hybrid encryption schemes, but for now most software seems to be defaulting to X25519MLKEM768.

Web browsing

The largest use of public-key cryptography in the modern world is probably web browsing. Luckily, all major browsers now support using post-quantum cryptography to encrypt TLS connections. It has been enabled by default since Firefox 132 (released in October 2024), Google Chrome 131 (released November 2024), and Safari 26 (released in September 2025). All three support the X25519MLKEM768 key-exchange mechanism.

More difficult is rolling out the use of these key-exchange mechanisms to web servers. Most web servers, such as Apache HTTP Server and NGINX, delegate cipher management to OpenSSL, which has supported post-quantum key-exchange mechanisms since version 3.5.0, released in April 2025. Users stuck on earlier versions of OpenSSL can add support for newer ciphers using the oqs-provider library from the Open Quantum Safe project. Web servers that rely on OpenSSL typically have a way to send configuration options to OpenSSL's SSL_CONF_cmd() function; in the absence of such an override, OpenSSL will default to the settings given in the openssl.cnf configuration file.

On the Red Hat family of distributions and on openSUSE, that configuration file is generated by the crypto-policies mechanism. Users add policies to /etc/crypto-policies and then regenerate the OpenSSL configuration file using update-crypto-policies. This will also generate updated configurations for other encryption libraries such as LibreSSL, and for some software that handles its own encryption formats such as OpenSSH. Releases after Fedora 43 and Red Hat Enterprise Linux 10.1 should default to preferring post-quantum cryptography. Older releases will require setting a backported default policy or manually editing the Groups directive in the appropriate policy module:

    # The policy may be named differently depending on distribution and version
    update-crypto-policies --set DEFAULT:PQ

Debian, Ubuntu, Arch Linux, and others have the user edit openssl.cnf directly. Debian and Ubuntu both have ports of crypto-policies, but they aren't enabled by default. Users of alternate encryption libraries on these distributions may need to update their configurations as well. None of the distributions currently default to preferring post-quantum cryptography in the configuration file, but installations with a new enough version of OpenSSL may end up using OpenSSL's own defaults, which do prefer it.

Some web servers, such as Caddy, use an embedded library rather than relying on the distribution's OpenSSL library. In Caddy's case, post-quantum cryptography is enabled by default whenever it is built using Go 1.24 or newer.

Overall, the safest approach to enable support for post-quantum cryptography on one's web server is to explicitly set the supported Groups given to SSL_CONF_cmd() to include "X25519MLKEM768". That only affects the individual web server, however, and may fall out of date if better post-quantum cryptosystems are found. Setting policy on a system-wide level covers other uses of OpenSSL, but has the same update problem. Relying on OpenSSL's own defaults will always result in one of the most recent ciphers, but it is easy for a changed default configuration from one's distribution to silently override.

OpenPGP

While web browsing is probably the most common activity that uses encryption, digital signatures are arguably more important to the security of modern Linux systems. Packages are typically accompanied by OpenPGP signatures to guarantee that they really do come from the distribution's package repository; individual Git commits or tags may also be signed to indicate that they come from a trusted individual. Given that many keys have a lifetime of years, it may be wise to begin moving to post-quantum signatures well in advance of any possible forgery.

Unfortunately, the OpenPGP ecosystem has been split in two since 2023. The GNU privacy guard (GPG), which is widely used by Linux distributions, started following a specification called LibrePGP, while several other tools continued to follow the IETF-standardized OpenPGP. The two standards disagree on how to implement post-quantum cryptography, which makes verifying signatures made with one set of software using the other tool slightly painful.

OpenPGP's approach is given in RFC 9980 ("Post-Quantum Cryptography in OpenPGP"). It adds seven new algorithms, four of which are hybrid algorithms. For encryption, it allows either ML-KEM-768 paired with X25519, matching the recommended default for web browsers, or ML-KEM-1024 paired with X448, which has slightly larger keys and signatures but may provide better security. For signing, the same underlying algorithms are used, but they are given different names and parameter choices that are optimized for signatures. Either ML-DSA-65 (corresponding to the security level of ML-KEM-768) and Ed25519 or ML-DSA-87 (corresponding to the security level of ML-KEM-1024) and Ed448 can be used.

The RFC requires these keys to be encoded in the new v6 key format specified in RFC 9580 ("OpenPGP"), which GPG does not support. There is one carve-out permitted by RFC 9980: implementations usually skip PGP subkeys that have unrecognized algorithms, so it allows creating v4 OpenPGP keys with post-quantum subkeys. Version 4 keys are compatible with GPG, so this may be the most prudent option for interoperability, if GPG ever adds support for the relevant signing algorithms.

GPG only supports using post-quantum keys for encryption; there are no separate signing key algorithms. When used to create such an encryption key, it uses the same underlying encryption algorithm (ML-KEM and an elliptic curve of choice), but stores the key and binds it to the user's identity information in an incompatible way. Specifically, ML-KEM defines a way to ensure that two devices believe they are using the same protocol in order to understand each other's keys by mixing a static set of protocol information into the key-derivation function. GPG uses a different set of static information than the IETF standards specify. Sequoia and other OpenPGP implementations cannot understand GPG's native post-quantum keys and vice versa.

Some other encryption software, such as RNP, the OpenPGP engine that powers Thunderbird's email encryption, uses GPG's LibrePGP key format, but makes an exception for understanding post-quantum v4 subkeys. To make the situation even more confusing, Sequoia provides a "GPG chameleon" which implements the GPG command-line interface, so users running gpg may actually be talking to Sequoia.

Practically, the simplest workaround is to create two separate PGP keys, one using classical signing algorithms and one using the RFC 9980 signing algorithms, and sign everything with both of them. This is the approach that Red Hat has been using for package signing, and it does work, at the cost of requiring signers to maintain two separate PGP identities. Theoretically, a v4 PGP key with a post-quantum subkey could be used, but, due to the limitations of the format, only for encryption and not for signing.

Users who want to make sure that their signatures are quantum-resistant should consider switching to Sequoia (possibly using the chameleon, to keep the interface the same), generating a v4 classical signing key (or reusing an existing key), generating a v6 post-quantum signing key, using both keys to endorse each other, and signing everything important with them both. This is certainly not ideal; we can hope that a better solution emerges before it becomes truly urgent.

For now, verifying this kind of dual-signature is straightforward: as long as either signature is valid, it can probably be trusted. But once it becomes possible to forge some RSA and elliptic-curve signatures with a quantum computer, consumers of signatures will have to either verify only the post-quantum signature, or use some kind of certificate transparency mechanism to make sure that the classical signature was made before such a quantum computer became available.

The only real solution

There is, of course, one option that offers complete protection against any kind of cryptographic attack, no matter how powerful: give up and go live in the woods. For those of us who do not have that option, we will just need to settle for hoping that configuring OpenSSL and our OpenPGP software of choice appropriately is sufficient, and keeping an eye out for the tipping point when quantum attacks become possible.

Index entries for this article
Security	Quantum computing

to post comments

Asymmetries between encryption and signing

Posted Aug 24, 2026 17:42 UTC (Mon) by dkg (subscriber, #55359) [Link]

Thanks very much for this summary, Daroc. A lot of work has gone into this transition (and will continue to go into it), but hopefully most users won't have to think much about it.

In the best case, their software's defaults will change, and hopefully that happens before the quantum apocalypse arrives. LWN readers are more likely than others to be responsible for setting those defaults, so i'm glad you give the heads up here.

The summary mentions how encryption and signing have different needs, but it might be worth expanding on that a little bit.

In particular, the confidentiality goal of encryption faces what's called a "harvest now, decrypt later" attack. So if Alice emits a confidential message today, even if a cryptographically relevant quantum computer (CRQC) isn't available today, an adversary could store Alice's encrypted message and then decrypt it when the CRQC becomes available. For signing, the the goal is authenticity, and a forged signature can't be generated until the CRQC is already available.

So the folks working on these schemes have prioritized the confidentiality goal, because we all have to emit confidential messages today that could be captured without our knowledge.

One example of this in OpenPGP is the so-called Autocrypt v2 certificate profile (on which i'm one of the contributing editors), which explicitly aims to defend against "harvest now, decrypt later", but leaves authenticity defense for future work. That future work would be pretty straightforward: just swapping in a PQC primary key; but it would inflate the size of the OpenPGP certificate significantly, because the certificate itself contains at least three signatures. Hopefully we can get enough experience with Autocrypt v2 before a CRQC is plausible that we can move on to handling the authenticity goals (and dealing with the expense of larger certificate sizes) in some future certificate profile.

HSMs for me are a missing link

Posted Aug 24, 2026 17:42 UTC (Mon) by tchernobog (subscriber, #73595) [Link] (11 responses)

My biggest problem is lack of widespread post-quantum algorithm support in HSMs, and computing power required even to do an initial TLS handshake.

Even if we wanted to, my company and I couldn't adopt PQC right now, for things as secure boot of embedded devices: where would we store the offline private keys?

Nor for most of operations that need to be secured there. We still use an ARMv5 from 2003... doing connections via PQC would put a real strain on the device, as there is no hardware acceleration.

And this stuff will be in use for the 10 years after production ends, so well inside the 2030s...

I hope somebody starts offering quantum-capable HSMs soon, both USB (for offline usage) and to be soldered on the board.

The German BSI keeps telling us to adopt PQC before 2030, but I don't see it happening. It takes up to three years for a new HW revision to hit the market...

HSMs for me are a missing link

Posted Aug 24, 2026 19:38 UTC (Mon) by neverpanic (subscriber, #99747) [Link] (8 responses)

> My biggest problem is lack of widespread post-quantum algorithm support in HSMs, and computing power required even to do an initial TLS handshake.

HSMs exist, but are probably out of most people's price range. Large organizations can afford them, but even projects like Arch Linux are still looking for an affordable option last I checked.

> Even if we wanted to, my company and I couldn't adopt PQC right now, for things as secure boot of embedded devices: where would we store the offline private keys?

Post-quantum support Secure Boot isn't ready yet anywhere, as far as I know. It'll be a few years before that becomes available. For constrained devices, it may also make more sense to go for something based on hashing instead of asymmetric crypto, e.g., using an HMAC that's computed on-device. That changes the security properties of Secure Boot and may not work for every use case, but for devices where the owner also has administrative/root access anyway, it should be an acceptable tradeoff.

> Nor for most of operations that need to be secured there. We still use an ARMv5 from 2003... doing connections via PQC would put a real strain on the device, as there is no hardware acceleration.

ML-KEM-512 is about as fast as X25519, so the issue here is rather the additional RAM and storage cost of the larger key sizes. Also, nobody deploys ML-KEM-512 in protocols as far as I can see. Also, in a hybrid, you need the ML-KEM *on top* of the existing computing cost. For extremely constrained devices, going directly to pure ML-KEM-512 may be an option, but should be carefully weighed against the downsides.

For signatures, this is a real problem. Hardware acceleration for the SHAKE family of hashes (i.e., SHA-3) should bring some speedup, but that will need new silicon. There may also be options in the near future around the FALCON/FN-DSA cryptosystem which has smaller keys. On the other hand, it also uses floating point, which is something we've never used for cryptography before, so there will likely be quite a few implementation pitfalls (and problems we don't yet know about). If the path towards more efficient algorithms and larger quantum computers keeps accelerating as it does currently, it's also questionable whether there will be sufficient time to get all these newer algorithms standardized, implemented, and the protocols updated to use those algorithms in time.

In other words: Yep, there aren't any great options here.

> I hope somebody starts offering quantum-capable HSMs soon, both USB (for offline usage) and to be soldered on the board.

They're on the horizon. Pre-production hardware exists today.

HSMs for me are a missing link

Posted Aug 25, 2026 7:07 UTC (Tue) by taladar (subscriber, #68407) [Link] (5 responses)

What kind of downsides does pure ML-KEM-512 have that could be weighed by someone who isn't an expert on quantum computing and/or cryptographic algorithms who can make better decisions on the topic than the industry consensus?

HSMs for me are a missing link

Posted Aug 25, 2026 8:03 UTC (Tue) by neverpanic (subscriber, #99747) [Link]

> that could be weighed by someone who isn't an expert on quantum computing and/or cryptographic algorithms who can make better decisions on the topic than the industry consensus

None, because of this part. You should talk to a cryptographer if that's something you'd consider. If you don't have one on speed dial (or your payroll), don't use pure ML-KEM-512.

Pure PQ vs. Hybrid

Posted Aug 25, 2026 11:00 UTC (Tue) by chris_se (subscriber, #99706) [Link] (2 responses)

> What kind of downsides does pure ML-KEM-512 have that could be weighed by someone who isn't an expert on quantum computing and/or cryptographic algorithms who can make better decisions on the topic than the industry consensus?

It basically boils down to the following (assuming the implementations themselves are all correct and side channel free):

If ML-KEM-512 remains secure against attacks (both classical and quantum): the pure implementation will have no downsides whatsoever.

If someone manages to break ML-KEM-512 (or comes so close to it that a state actor might reasonably break it): then it's worse than any hybrid cipher.

Hybrid ciphers are the conservative option that doesn't deteriorate the security with respect to the non-PQ option in use _right now_. (i.e. ECC + ML-KEM is at least as secure as ECC alone).

I'm not a cryptographer myself, so I can't intelligently comment on how likely it is whether people will be able to break ML-KEM. Even cryptographers won't be able to tell you with any degree of certainty whether that'll be the case. The longer it remains unbroken the unlikelier it becomes that someone will break it. The fact that a lot of very smart people have agreed upon ML-KEM as the next standard speaks in favor of its security, but it's no guarantee.

I personally would err on the conservative side and use a hybrid scheme, but I have the luxury of not being in your shoes and potentially not having any constraints you might have the might want to make one consider other options.

Pure PQ vs. Hybrid

Posted Aug 26, 2026 7:28 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

> I'm not a cryptographer myself, so I can't intelligently comment on how likely it is whether people will be able to break ML-KEM. Even cryptographers won't be able to tell you with any degree of certainty whether that'll be the case.

That was entirely my point, unless someone is one of the leading researchers on the topic there just isn't much to weigh here. What you describe in the first few paragraphs of your post is the industry consensus and there is very little case-by-case information that anyone, layman or expert, could weigh to change anything about that.

Pure PQ vs. Hybrid

Posted Aug 27, 2026 7:59 UTC (Thu) by chris_se (subscriber, #99706) [Link]

> > I'm not a cryptographer myself, so I can't intelligently comment on how likely it is whether people will be able to break ML-KEM. Even cryptographers won't be able to tell you with any degree of certainty whether that'll be the case.
>
> That was entirely my point, unless someone is one of the leading researchers on the topic there just isn't much to weigh here. What you describe in the first few paragraphs of your post is the industry consensus and there is very little case-by-case information that anyone, layman or expert, could weigh to change anything about that.

The only standard we have to really vet cryptography algorithms is "how long have they withstood under how much scrutiny?". Experts in the field will probably be better at filtering out obviously bad candidates (where a layperson won't be able to see the obvious weaknesses), but in the end even experts rely on this very simple principle.

ML-KEM hasn't had as much scrutiny compared to e.g. ECC or RSA - but it's now seeing a lot more of it. If you want the same level of confidence in ML-KEM as in e.g. ECC, you'll have to wait another 5 to 10 years.

HSMs for me are a missing link

Posted Aug 25, 2026 17:46 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

What kind of downsides does pure ML-KEM-512 have that could be weighed by someone who isn't an expert on quantum computing and/or cryptographic algorithms

The big downside with ML-KEM is just that we have way less experience with it. With any cryptosystem, we generally don't say that it's unbreakable, just that nobody has broken it yet. The more effort people have put into breaking it without success, the greater our confidence that it really isn't breakable, but it never reaches certainty. Because the technology underlying ML-KEM is newer and hasn't received as much testing as conventional cryptography, we just don't have the same degree of confidence yet.

The other downside is that it isn't as efficient, at least with current generation chips. Curve25519 is extremely efficient and uses something like half the processing power of the ML-KEM implementation that's supposed to give comparable security. Because of that, you aren't saving that much time or energy by relying on ML-KEM alone compared to using a hybrid scheme.

HSMs for me are a missing link

Posted Aug 27, 2026 17:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> HSMs exist, but are probably out of most people's price range.

You can get an HSM for about $120: https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7?cat...

HSMs for me are a missing link

Posted Aug 28, 2026 7:36 UTC (Fri) by chris_se (subscriber, #99706) [Link]

> > HSMs exist, but are probably out of most people's price range.
>
> You can get an HSM for about $120: https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7?cat...

I suspect the person you are replying to meant HSMs with PQ algorithm support. And the prices for HSMs that support those algorithms I could find are in the high 4 digits (USD) or even higher.

HSMs for me are a missing link

Posted Aug 25, 2026 10:21 UTC (Tue) by epa (subscriber, #39769) [Link] (1 responses)

I thought that public key cryptography was often used to communicate a shared secret, and then you use symmetric encryption based on that secret. So it shouldn't matter that much if the initial public-key part is slower than before?

HSMs for me are a missing link

Posted Aug 25, 2026 12:18 UTC (Tue) by daroc (editor, #160859) [Link]

Yes, that's exactly how TLS and other similar systems work. The problem is the scale of how much slower TLS handshakes are with post-quantum cryptography. Whether the additional latency is reasonable depends on the particular application. In an earlier article about the standardization process, I looked at what the increase in public key and signature size are for ML-DSA. A TLS handshake using ML-DSA is going to be at least 29,856 bits (3,732 bytes) larger. At the speed of my home internet, that adds one milisecond to the handshake in the best case, but in practice the signatures are now too large for a single packet so there's some overhead from fragmenting the key exchange across multiple TCP packets. For places with worse internet connectivity, the overhead is worse. If you're suffering under a 1 Kbps connection, ML-DSA adds an entire 30 seconds to the handshake.

Might be panic-mongering

Posted Aug 24, 2026 17:45 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (12 responses)

https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf is an interesting related read.

And https://lists.gnupg.org/pipermail/gnupg-users/2026-April/... and https://lists.gnupg.org/pipermail/gnupg-users/2026-April/... seem to indicate the same.

Meanwhile, there are deficiencies in the currently proposed PQC algorithms, and some spooks *did* recommend to use only them (as opposed to hybrid: both PQC and classic)… makes you wonder.

Might be panic-mongering

Posted Aug 24, 2026 18:14 UTC (Mon) by daroc (editor, #160859) [Link] (1 responses)

Yes, I covered the fight about allowing PQC-only profiles of TLS at the time: https://lwn.net/Articles/1048978/

Personally, I think that switching to a hybrid scheme is a sensible precaution — there are lots of places where I'd be willing to give up a little extra computing power for more peace of mind, actually — but I do recognize that not everyone will want to.

Might be panic-mongering

Posted Aug 24, 2026 23:55 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

Agreed that switching to a hybrid scheme (*if* that is designed well enough) is a good precaution, but at the current point in time, I see several problems with that (old hardware, software ossification (specifically, if you introduce new schemata now, you can use them in about five to ten years at the earliest), and the split into mutually incompatible variants).

So I guess that most ordinary users, without a threat model that specifically includes decrypt-much-later-by-nationstate-size-attacker as a problem, are currently better served not switching. PGP is already splintered enough (and Goddess knows the amount of scorn I got for sticking to Lutz Donnerhacke’s PGP over GPG for a while longer than many).

Might be panic-mongering

Posted Aug 24, 2026 19:46 UTC (Mon) by neverpanic (subscriber, #99747) [Link] (2 responses)

It might be panic-mongering, but for anybody bound by requirements from governments and regulatory bodies (and by now it almost doesn't matter which government or regulatory body exactly), it doesn't matter whether the danger is real.

For example, the EU (in the PDF linked downloadable from https://digital-strategy.ec.europa.eu/en/library/coordina..., page 7) says:

> By 31.12.2030:
> […]
> Quantum-safe software and firmware upgrades are enabled by default.

and

> An integral part of a transition plan beyond 2030 is a quantum-safe upgrade path. It is therefore highly recommended to ensure that products entering the market with an expected lifetime beyond 2030 should be upgradable to PQC and that the upgrade mechanism for software and firmware upgrades should incorporate post-quantum signature schemes for integrity and authenticity.

If you're developing a car, or even just a smart lightbulb now, you better plan with ML-DSA signatures, or this will be a tight deadline to meet.

Might be panic-mongering

Posted Aug 24, 2026 23:57 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (1 responses)

> anybody bound by requirements from governments and regulatory bodies

That’s large companies, who have their own lawyers, not your ordinary LWN reader who uses and maybe even develops on/for Linux-like systems.

Companies can do their parts on their own (like that “supply chain” paperwork and all that).

Might be panic-mongering

Posted Aug 25, 2026 8:00 UTC (Tue) by neverpanic (subscriber, #99747) [Link]

I estimate there might be one or two LWN readers who work for such companies.

Might be panic-mongering

Posted Aug 25, 2026 12:38 UTC (Tue) by dd9jn (✭ supporter ✭, #4459) [Link] (2 responses)

It is also worth viewing Peter's talks. For example at
https://media.gnupg.org/misc/Peter_Gutmann-Why_Quantum_Cr...

Might be panic-mongering

Posted Aug 29, 2026 23:17 UTC (Sat) by acolin (subscriber, #61859) [Link] (1 responses)

This talk by Peter Gutmann is weak. A well-composed crowd-pleasing routine. He is correct to criticize complexity. Not much else of substance is said. Criticizing 'quantum analysis' based on how many integers have been factored to date is missing the point of preparedness.

His plug for Dr. Sabine Hossenfelder is the proverbial nail. The mutually attractive force between a certain kind of public science figure is remarkable. You'd think any one of them would be trying to dissociate from the others to avoid being categorized into the same conspiracy bucket, but actually the opposite happens: they plug each other, endorse each other books, interview each other on podcasts, etc. Hossenfelder, Weinstein, Krauss... and apparently Gutmann wants to be on the same list. And, transitively, the author of GnuPG, too, then.

Might be panic-mongering

Posted Aug 30, 2026 1:42 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

He's not entirely wrong, though. There had been a HUGE wave of investment into QC around 10 years ago, and it completely fizzled.

Moreover, Shor's algorithm so far remains the _only_ real breakthrough. The other often-given example is quantum simulation of matter, and apparently there are (as of now) there is just one algorithm for time-dependent simulation of a quantum system with true exponential advantage. But a more important question of the ground state computation is unsolved.

That being said, the gap between the current quantum SOTA and Shor for practical bit sizes is around 10000x. That's a significant number, but it's also not outlandishly large.

Might be panic-mongering

Posted Aug 25, 2026 13:51 UTC (Tue) by MarcB (subscriber, #101804) [Link] (3 responses)

While entertaining to read, it really does not seem overly scientific.

A worthwhile counter-position, from someone who is not known as a panic-monger: https://blog.cr.yp.to/20250118-flight.html

Might be panic-mongering

Posted Aug 26, 2026 9:30 UTC (Wed) by muase (subscriber, #178466) [Link] (2 responses)

Yeah, this is a general problem in this topic – every time I see a new Quantum Computers Cannot Work, it is just really bad quality and not scientific; and that should already be worrying enough.

If it is supposedly so obvious that it cannot work, we should see quite a few sound papers about this. Instead, all we get is pseudo-scientific and often outright polemic work, riddled with gut feelings, non-sequitur-"arguments", and a lot of overconfident confirmation bias.

I am not saying we will get reasonably capable quantum computers anytime soon™ – there are quite a few reputable subject matter experts, scientists, and engineers who are skeptical about this. But at the same time, I also don’t know any of them who is confident that we won’t get them.

And this is an important distinction: being skeptical about the timeline is totally fine (I’m too btw); but being confident that this won’t happen is not backed by any evidence whatsoever. And it is fine to run a personal bet on that; but in my opinion, it is not professional to just deny the need for PQ-crypto and state it as "fact", when in reality, you cannot cite any scientifically sound/accepted/peer-reviewed backings for it.

A side note on the topic of fear mongering: cryptography always has to reside a bit on the side of being overly cautious, because it is very hard (to outright impossible) to fix things ex-post.
This does not mean that every deus-ex-machina claim should be taken seriously; stuff still has to be somewhat rooted in reality. But usually, we don’t wait until shit hits the fan and stuff is broken, but we improve and iterate upfront once we have some evidence that certain attacks might be coming. And "might" is a pretty weak thing, because it also might very well never happen – but if you are wrong, and shit indeed happens to hit the fan, it’s too late. As said, you can’t easily fix things ex-post anymore – you can’t patch a harvested cipher text to use a new algorithm.

Also, and this is a bit of a second level consideration to the previous one: you don’t want to wait until the impacts are already visible on the horizon before you start to design and roll-out new cryptographic algorithms; it is much better if you have lots and lots of time to gain experience with them before they are actually needed. If ML-KEM is broken today, it will be quite a fail, but it won’t have too much impact – the legacy algorithms are still there and strong, and most stuff that has enough computational power/bandwidth is doing a hybrid scheme anyways, and we will have plenty of time to learn from our mistake and develop a better successor. However, if you wait until a quantum computer is just foreseeable 20 years away, you probably have only one realistic shot – if you need a second iteration then, decrypt-now-harvest-later will bite you in the ass.

Might be panic-mongering

Posted Aug 26, 2026 13:21 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

> This does not mean that every deus-ex-machina claim should be taken seriously; stuff still has to be somewhat rooted in reality. But usually, we don’t wait until shit hits the fan and stuff is broken, but we improve and iterate upfront once we have some evidence that certain attacks might be coming.

Perfect example - the Germans thought the Naval Enigma was unbreakable. And the Admiralty made sure they always had evidence to re-inforce that belief. But how come there were always air patrols in the Bay of Biscay exactly when U-boats were leaving and returning to port? How come a destroyer patrol just happened to be patrolling the same area as a milch-cow?

And even if the Germans had suspected, and done something about it, what would they have done about all the boats at sea? They would probably never make it home.

Cheers,
Wol

Might be panic-mongering

Posted Aug 26, 2026 20:52 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Perfect example - the Germans thought the Naval Enigma was unbreakable.

Not exactly. Apparently German cryptographers believed a cryptanalytic attack on Enigma was possible but impractical. They were more worried about practical attacks from things like the Allies capturing the list of rotor positions for each day or operators re-using the same rotor positions for multiple messages*. Those practical attacks got a lot of attention because they were a big weak spot, but they kept improving Enigma, too. They expanded the set of rotors, added the plugboard, and for the Naval version even added a fourth rotor. They kept trying to defend themselves from a theoretical attack they didn't believe would happen because they understood the potential consequences if they were wrong.

*It was possible to extract information by comparing two messages encrypted with the exact same settings even without breaking the whole system, so operators had to be careful about the details. Each Enigma network shared a set of rotor and plugboard settings for the day, but the daily rotor settings were only used for the first few characters of each message. Those first few characters gave the rotor settings used for the rest of the message.

Quantum Landscape

Posted Aug 24, 2026 19:05 UTC (Mon) by paulbarker (subscriber, #95785) [Link]

I recommend following the annual updates from Samuel Jaques at https://sam-jaques.appspot.com/quantum_landscape. There's a graph and everything. And the analysis is relatively understandable, Sam is an academic with relevant interest and knowledge but this is pitched to a more general technical audience.

GnuPG RFC 9980 support may be on the horizon

Posted Aug 24, 2026 19:24 UTC (Mon) by neverpanic (subscriber, #99747) [Link] (1 responses)

> The RFC requires these keys to be encoded in the new v6 key format specified in RFC 9580 ("OpenPGP"), which GPG does not support.

It seems the German government agencies that fund parts of GnuPG development are demanding support for RFC 9980, and Werner Koch (the primary maintainer of GnuPG) seems to be planning to support it:

https://mailarchive.ietf.org/arch/msg/openpgp/B7ytSFXTVW8...

There's apparently some work in progress code already: https://github.com/gpg/gnupg/commits/wk/rfc9980/ (link goes to GitHub mirror, development isn't happening on GitHub).

Previous discussion at https://floss.social/@hko/117127125465768501 and replies.

GnuPG RFC 9980 support may be on the horizon

Posted Aug 25, 2026 12:34 UTC (Tue) by dd9jn (✭ supporter ✭, #4459) [Link]

Just my usual comment on the "German government funds the GPG development": We have seen only one funding for GnuPG in 1999/2000 with a total amount of ~300k DM. The aim was to port GnuPG to Windows and to provide a lighthouse project for the new crypto master plan of the then new government. After that my company ran usual business, looking for customers and bidding on tenders.

Sure, we (g10 Code / gnupg.com) do quite some work with the public administration. Unfortunately, we sometimes have to bite bullet and do things we would not suggest for the open source community because some things don't make any sense from a privacy, security, or engineering POV. For example PQC resistant algorithms; see @mirabolis reply and the papers and talks by Peter Gutmann et al.

Werner <wk@gnupg.org>