What do we actually know?

Post-quantum has been on a few people’s radar in crypto for years, and this year it became an industry-wide conversation. Over the last few months AI has joined it. Quantum computers are coming, and when they arrive they break factoring and discrete log, and with them RSA and elliptic curves. AI adds a different threat: better maths, found faster, that could break something we think is safe today, possibly before a quantum computer exists.

Most of the discussion is now about which cryptography to trust. One side says to use hash-based cryptography wherever possible, because structured maths gives an attacker, or an AI, more to work with, and every structured assumption you add raises the odds of a new surprise attack. The other side says lattices are smaller and faster, give you things hashes can't, and that hash-based systems carry more assumptions than people think once you build anything beyond a basic signature. A third view, held by the people who deployed post-quantum cryptography on the web, is that the choice has already been made: ML-KEM and ML-DSA are standardised, and ML-KEM already protects a large share of web traffic. On that view, if the web already trusts lattices for key exchange, it can trust them for signatures, though signatures on the web don’t sit in front of trillions of dollars of assets the way they do on a chain.

If you look at who is making each argument, it mostly lines up with what they've built. People who have spent years on hash-based signature schemes tend to argue for hashes. People who have shipped lattice-based signature schemes tend to argue for lattices. The same goes for proof systems and for aggregation. This isn't an accusation (I have positions and a company too, and I've published work on both lattice-based and hash-based schemes), and nobody is being dishonest. If you've spent a decade on one approach, you know its strengths better than anyone and you've long since made peace with its weaknesses. It does mean each argument is worth reading with the author in mind.

I don't think anyone can answer the question being argued, which assumption holds up. ML-DSA, ML-KEM, Falcon and SLH-DSA are all secure based on what we know today, and nobody knows which, if any, will fall first. What you can answer is how hard each part of your system is to move, and that should decide how conservative each part needs to be. For a blockchain, that potentially gives hashes and lattices each a place, and it means the parts that can move should start now, while the debate continues.

Safe means safe today

When cryptographers say a scheme is safe, they mean nobody knows an attack on it, given the maths we know, the hardware that exists and how the scheme is used. All three change over time. Triple DES is a good example. Its key was never broken, but its 64-bit block meant that once people encrypted tens of gigabytes under one key, block collisions started leaking plaintext, and by 2016 that was a practical attack on HTTPS. Browsers dropped it and new systems stopped using it, though parts of the payments and banking world still run it.

By that definition, the following are safe today. For symmetric encryption and hashing I've named the common choices, and other well-established ones are safe too. For post-quantum cryptography, these are the schemes standardised or close to it.

• Elliptic curves at 256 bits and up, and RSA at 2048 bits and up, against the computers that exist now;
• AES-128 and up, SHA-2 and SHA-3;
• ML-KEM, ML-DSA and Falcon (lattice-based; Falcon's standard, FN-DSA, isn't final yet);
• SLH-DSA, XMSS and LMS (hash-based; the stateful ones, XMSS and LMS, are safe as long as you never reuse state).

At the same security level, these schemes are built to cost an attacker the same amount of work, so none of them is more secure than another by design. What differs is what that cost rests on. A hash-based signature relies on its hash function. A lattice scheme relies on a lattice problem and on the hash functions it uses internally, and the cost estimates for attacking lattices are less settled than those for attacking hashes.

What quantum breaks

Quantum computers are coming. A large enough one runs Shor's algorithm, which solves factoring and discrete log efficiently (I wrote about exactly what that does and doesn't break here). That breaks RSA, every elliptic curve signature and key exchange (ECDSA, Schnorr, EdDSA, ECDH), and pairing-based cryptography like BLS and KZG. Shor's algorithm has been known since 1994, and the resource estimates for running it keep coming down. The only open question is when the hardware will arrive.

That makes quantum a known break with an unknown date, and you can plan against it: estimate the date, add margin, and finish migrating before then. This is more urgent for key exchange, because traffic recorded today can be decrypted once the machine exists. That's why browsers already use ML-KEM by default, combined with X25519.

What we can't know

Everything else on the safe list is safe until someone finds an attack that costs less than its security level assumes. Nobody knows whether there's an attack out there to find, but AI is increasing how many people, and models, are looking and how fast. A break can be anything from a few bits off the security level to a full key recovery, and you usually find out from a paper (or a lab’s blog post), unless whoever found it chooses to use it instead.

So the more useful question is whether anything tells you in advance which assumption will fall first. The hash camp's answer is structure: more algebraic structure gives an attacker more to work with, and recent breaks fit that. SIKE fell in 2022 to an attack that recovered keys in about an hour on a laptop, and took the whole SIDH approach to key exchange with it. HAWK is the other end of the range. This year an AI model found a symmetry in its lattice that pushed the submitted parameters below the security its designers claimed. Restoring the margin would have made HAWK uncompetitive, so they withdrew it from NIST's post-quantum standardisation process. Age doesn’t protect against this either: new attacks on the structure of Classic McEliece's codes, studied since 1978, cut its estimated security below its claimed levels on some cost models, and Germany's BSI now advises against new deployments.

As a prior, that's reasonable, and decades of study don’t remove it. What it doesn't give you is a ranking to plan around. The HAWK attack exploits a problem only used in cryptography since 2022 and doesn't carry over to ML-KEM or ML-DSA, and nobody can say how much more likely a break in their problems is than a break in SHA-256. Structure also can't be avoided everywhere. Public-key encryption can't be built from hash functions alone, so anything that encrypts, private transfers included, already depends on a structured assumption, which in practice means ML-KEM (or HQC, a code-based alternative also being standardised).

Aggregation doesn't settle it either. Hash-based signatures can't be combined algebraically, so aggregating them means proving thousands of signature checks inside a proof system. Lattice aggregation runs through a proof system too: Aerie, released this month for Falcon, is a lattice SNARK. Either way the aggregate rests on the proof system as well as the signatures, and a flaw in the proof system lets someone produce an aggregate that verifies for signatures nobody made. Proof systems have had flaws like that in the last two years, in their theory and in deployed code.

Being able to move

If nobody can say which assumption fails next, the thing you can control is how long you stay exposed when one does: the time between the break and your system no longer accepting the broken scheme. I've written before that crypto-agility is the ability to delete crypto. Adding a new scheme is the easy part. The test is whether you can name the date you'd stop accepting the old one.

How long you'd be exposed should decide how much each part of a system relies on. Every scheme relies on a few things being true: a maths problem being hard, any proof system built on top being sound, and the code being correct. A conservative choice relies on as few of those as possible, and only on ones that have had years of analysis. The longer a part of a system would take to move, the longer it relies on them holding, and the more it's worth paying in size and speed to rely on fewer.

A blockchain doesn't move at one speed. Its parts range from things that can never move to things that can move in a day, so we can consider a different approach for each.

Encrypted data that has already been recorded can never move. Nothing done after the break protects it, so this is where the most conservative choice belongs. There is no hash-based option for encryption, so that choice is ML-KEM combined with a classical key exchange, which keeps the data safe unless both are broken. This is also the part that can't wait.

Coins whose keys are already public, or whose owners are gone, can't move on their own either. Once a signature scheme is broken, a signature under it proves nothing, so ownership has to be shown another way: an address that commits to the hash of a key that was never revealed, or a proof of knowledge of the seed the key came from. Both rely on a hash function staying secure, and both have to be built in before the break happens. So whichever signature scheme a chain uses, it has to set up its way out in advance.

Anything that only changes by hard fork, such as the signatures validators use to reach consensus and the way they are aggregated, moves slowly and should be chosen to last. For the signatures alone, fewest assumptions means hash-based signatures, potentially paid for in size. They are also the easiest to rebuild. On a critical open network, the people who might one day have to reimplement or audit the client under pressure are ordinary developers. A hash-based signature can be written and checked from a short specification. Lattice schemes need more specialist knowledge to implement safely. Aggregating signatures adds a proof system for whichever family you pick, so the remaining choice is which proof system you expect to stay sound for as long as a fork cycle.

Accounts that name the scheme that verifies them, held by owners who are paying attention, are the fastest-moving part. A user can switch schemes without a fork, so there's little reason to pay for conservatism and no reason to wait. ML-DSA is standardised and deployed and can sign alongside ECDSA until the chain stops accepting ECDSA on its own. Falcon gives smaller signatures once its standard is final, and threshold ML-DSA works for small groups. A chain that accepts schemes from both families lets users choose, and leaves them a second path if one family weakens. Cold storage and dormant accounts sit on the slow side.

The hash camp has a fair reply to all of this. Hash-based signatures and proof systems keep getting smaller and faster, and if they reach lattice sizes, why not use hashes for every signature? If they get there, they should be used. Schemes in both families are improving quickly, and AI is now speeding up the design work as well as the attacks. That is a reason to build for movement and start now. The schemes we have today are good enough to migrate to, and a system that can move picks up each better scheme as it matures, in the same way it leaves one that breaks. A scheme shipped today doesn't have to be the one a system keeps. A system that waits for the best one has nothing deployed in the meantime, and a newly designed scheme still needs years of analysis before it counts as well studied.

Choosing the algorithm is the short part of a migration. Hardware wallets need new firmware and recertification, HSMs need vendor support before custodians can use a scheme, threshold signing for post-quantum schemes is still maturing (faster than most people expect, and we’ll have more to share shortly), and key ceremonies and recovery procedures have to be rebuilt around new keys. That work takes years whichever scheme is chosen, and a system has to go through it once before it can move quickly the second time.

Start now

Everything on the safe list is safe today. Quantum computers will break the RSA and elliptic curve schemes on it, and the only open question is the date. Cryptanalysis, sped up by AI, may break something else on it, and nobody on any side of this argument can tell you which.

What you can work out is how long each part of your system would take to move, and that decides how many assumptions it can afford. Where you can’t move, that means the fewest assumptions: hash-based signatures, the most conservative encryption you can carry, and recovery paths set up in advance. Where you can move, you have room to optimise for size, cost and user experience, and to switch when something better arrives. Either way, the work should start now, because the first migration is what builds the scheme identifiers, deprecation paths and recovery commitments the next one will need.