Two papers came out last week that suggest classical asymmetric cryptography might indeed be broken by quantum computers in just a few years.
That means we need to ship post-quantum crypto now, with the tools we have: ML-KEM and ML-DSA. I didn't think PQ auth was so urgent until recently.
@jornfranke I encourage you to reread the article because it addresses all your objections, especially the "why did they not break a small key".
I will add that the cryptography experts are actually very confident in the security of lattices. https://keymaterial.net/2025/12/13/a-very-unscientific-guide-to-the-security-of-various-pqc-algorithms/
Google says that it will fully transition to post-quantum cryptography by 2029. I think this is a good move, not because I think we will have a useful quantum computer anywhere near that year, but because crypto-agility is always a good thing. Slashdot thread.
@filippo @jornfranke I wouldn't say they are necessarily easier, but we stand on the shoulder of giants, these days we have tools and knowledge the RSA pioneers hadn't even dreamt of yet, so a lot of the pitfalls are much easier to avoid.
The cryptography community also builds bullet proof algorithms these days, not just primitives everyone has to figure out how tp make secure by themselves.
All that said ML-KEM and ML-DSA's power and timing side-channel analysis is much harder, but doable!
This is a tricky question because the definitions shift. A lot of these algorithms require all of the qubits to be in the same quantum circuit, but not all devices allow this and two smaller quantum computers do not combine to make a single large one in the way classical ALUs can. A lot of the recent publications have been focused around using multiple physical qubits to handle the various error conditions and present as a single logical qubit, so a system with a thousand qubits may only be one qubit from the perspective of a quantum computing algorithm that’s modelled on a perfect quantum computer.
@david_chisnall what about quantum gates? Aren’t they as important as the number of required bits?
Considering the stakes, combined with the scope of resources some superpowers possess, plus the "disclose this and it might cost you your _life_" level of "nda" they enforce, I wouldn't count on "a few years". Might already be here?
I suspect anyone who might have the actual info as to what the state-of-the-art crypto-breaking capabilities are at the level of a military superpower, they certainly aren't in a position to talk openly about it.
@neverpanic @filippo
We inventoried _everything_ once for Y2K and once for DST 2007 🇺🇸 , at least here.
We _can_ and _will_ do it again.
(Doing it for both CRQC and Y2038 simultaneously would be a cost-savings.)
(If you can't make a 100% inventory, ask your Red Team or contact a gray-hat hacker, see if they'll take $ for becoming white-hat red-vest on Red Team.)
@filippo @robpike Here's an NSA publication on this topic, from 10 years ago. What I love about this is how they describe their requirements: they have to field systems and guarantee their security for 30 years into the future.
https://archive.org/details/cnsa-suite-and-quantum-computing-faq/mode/2up
@filippo What about WebAuthn, Passkeys, etc?
I don't see any movement in that side of the pond. Just as we are convincing everyone to switch to them
@filippo
> In symmetric encryption, we don’t need to do anything, thankfully
Ok. So the IoT garden must rewind to the Kerberos or physical provisioning. I can't imagine lattices on small silicon yet.
Thank you, Filippo.
@KoosPol @filippo @mikaeleiman
> should be behind a gateway/proxy anyway
IoT devices are not expected to have any external protection. This is a consumer market. We can not expect home owner to provide secure environment before they change old dumb LED-bulb for a new one equipped with BLE, motion sensors and microphones. Whether they use "smart" features of this bulb or not.
Then we have many mandated by law devices that must be put in the car for safety and for national security reasons. A prime example are the direct TPMS sensors. E.g. a hackable TPMS in the tire will not deny our abilities to accurately monitor the good actors movements, but it may afflict our ability to track movements of the bad actors were they able to tamper with emitted by the tire IDs to mimic a secure-facility employee's car.
@mikaeleiman
> there”s RAM and CPU on small embedded devices.
This. You can think of attesting just KDC with ML signature, likely, on some bigger silicon, but not on a half of coming cheap STM lines for example.
Time to study rfc4120 and siblings :(
I'd like to ask whether migrating Ed25519 to Ed448 makes any sense? At least temporarily. Setting aside all that owful implementation disadvantages of Ed448.
@neverpanic @filippo
> LMS/XMSS
I'd bet only on something that will get the most attention of the cryptographers community. And certainly I am quite in shock having past gossips coming to the reality now.
If Ed448 is off, and larger NIST curves too, then small cpus over the slow links are toasted at least re authentication. Likely. We need to sit, think, cool down.
And I think that now the threat model assessment will be the most important part of the design procedures. Do we need secure against the gov/corporate adversary of a big country, or small one. Do breach afflict just one site or all users and so on.
@filippo I still think hybrid is the way to go. PQ crypto algorithms and their implementations are still very new, with undiscovered flaws. If you use hybrid and PQ is broken by a bug or flaw, no problem, you still have the same protection or better than the classical one.
Even when quantum computers exist you'd have to break both the classical one (with a quantum computer) and the PQ one (with an implementation flaw, or mathematical breakthrough).
If you deploy only PQ and a flaw is found you are *worse* than classical, depending on how bad the flaw is you might not be much better from transmitting in plain text.
IOW a PQ crypto algoritm protects against an attack from a machine which doesn't yet exist. Deploying it standalone makes you vulnerable against a bug that doesn't yet exist. *But* we've seen a steady stream of bugs in OpenSSL, and it is very likely that there will be one in the PQ implementation too.
I think it is more likely that such a bug is discovered before a quantum computer is built that is capable of a practical attack.
For example there could be side channel attacks if you forget to implement protections similar to RSA blinding (constant time CPU instructions are not side-channel free, see latest Hertzbleed attack from 2025 about remote power analysis leaks). And there probably plenty of other "classical" attacks that will work on PQ algorithms too, since they execute on a classical computer...
Of course implementation flaws in a classical+PQ hybrid could be worse off than just classical too (e.g. some C memory bug), but that might be an acceptable risk.
I'm not sure what the best ordering for a hybrid would be, but I guess PQ encryption first, then classical? So you always have to break the classical first (which won't be instant, even with quantum computers).
There is of course a performance cost, but AFAICT encryption isn't really the bottleneck in TLS, from some testing with 'curl' and 'stunnel' they achieve much lower speeds than what 'openssl speed' reports, so increasing encryption time may not affect overall time that much.
@KoosPol @edwintorok @filippo @djb
I think he's saying that non-hybrid ML-KEM is the NSA's wet dream, in this post and others: https://blog.cr.yp.to/20260221-structure.html
@filippo you mentioned that file encryption is particularly vulnerable to store-now-decrypt-later – do i understand correctly that e.g. an old passage database which uses pre-quantum recipients is vulnerable if the encrypted files are leaked or compromised?
the mitigation here would be to migrate to a new passage db using *only* post-quantum-proof recipients *and then also* rotate all the passwords in the database, right?
@filippo Thanks for the post!
Regarding AES128: is it safe *for the moment* or do you think it should be safe for a long time yet ?
And what's your opinion on pre-shared keys ?
I often work on web push, and its encryption (RFC8291) uses an "authentication secret" that if, I understand correctly, works as a pre-shared key (cf. bellow), and AES128. I wonder if it's safe to continue with this protocol
PRK_key = HMAC-SHA-256(auth_secret, ecdh_secret);
IKM = HMAC-SHA-256(PRK_key, key_info || 0x01)
@S1m it's as safe as it always was, and as safe as if QCs were impossible. (Which is to say very safe, no one really thinks AES will get surprise broken.)
\PSKs are fine if you can keep them from being compromised. The scheme you excerpted should be fine if auth_secret is not known to the attacker.
@filippo Thanks a lot for the answer!
So, that's nearly what I had in mind. I wasn't sure for the AES key length: I remember reading that 128 was enough in some places, and that we should move to 256 in some others
@filippo Is anything pointing to actual quantum computers being made?
Dr Hossenfelder has made a few videos on the topic that at least convinced me they're likely never going to be able to scale as much as needed.
Adrian Cockcroft
Filippo Valsorda
Tristan Colgate-McFarlane
Craig Stuntz
Jörn Franke
Simo ✔️
Andreas K
David Chisnall (*Now with 50% more sarcasm!*)
پویان Pouyan 
Toni Aittoniemi
grrl_aex
Clemens
Garrett Wollman
Chris Palmer
Bill Ricker
slash
Arian
Tim Bray
ohir
m_eiman
Koos Pol 🇺🇦
Edwin Török
miniBill (Leonardo)
multi
S1m
Alex
Troed Sångberg