Lattice-Based Cryptography Explained

Lattice-based cryptography is the branch of modern encryption that hides its secrets inside a grid of points in high-dimensional space. It is the mathematics underneath the two headline standards the United States published in 2024, and it is the reason most of the internet’s future key exchanges will look nothing like the ones running today.

This page is about the machinery rather than the policy. If you want the wider picture of the migration, our guide to post-quantum cryptography covers it, and the vendor landscape is mapped separately. What follows is the geometry that lattice-based cryptography is built from, the hard problems, the protocols standing on them, and an honest account of why anyone believes a quantum computer cannot break them.

What a lattice actually is

Take two arrows starting from the same point and pointing in different directions. Add them together in every whole-number combination you can, forwards and backwards, and mark every point you land on. The infinite pattern of dots you get is a lattice, and the two arrows are called a basis for it.

In two dimensions the result looks like wallpaper, a regular grid of dots that may be square, or stretched, or slanted. Ordinary graph paper is the simplest example, generated by one arrow of length one pointing right and another of length one pointing up. Nothing about the definition requires the arrows to be perpendicular or the same length, and the interesting cases are the ones where they are neither.

Chris Peikert’s standard survey of lattice-based cryptography gives the formal definition, which is the set of all integer combinations of a fixed collection of linearly independent vectors. The word integer is doing the work, because if you allowed fractional combinations you would simply fill the whole space and there would be no structure left to exploit. Restricting to whole numbers gives you a discrete set of points with gaps between them, and those gaps are where the difficulty lives.

Now raise the dimension. The lattices used in lattice-based cryptography live in several hundred or a thousand dimensions, and no visual intuition survives the trip. What does survive is the arithmetic, and questions that are trivial on wallpaper become the basis of a security claim once you cannot see the picture.

Bases, good and bad

A single lattice has infinitely many bases. If you take one basis and replace the first arrow by the sum of the first and second, you have a different pair of arrows that generates exactly the same set of points. Repeat that a few thousand times and the description becomes unrecognisable while the lattice itself has not moved at all.

The region swept out by the basis vectors, the parallelogram you get from all fractional combinations between zero and one, is called the fundamental domain. Every basis for a given lattice has a fundamental domain of the same volume, which is a fixed property of the lattice called its determinant. What changes between bases is the shape of that region, and shape is everything.

A good basis is short and close to orthogonal, with its fundamental domain a fat blob rather than a sliver. Given any point in space, you write it in that basis, round each coordinate to the nearest whole number, and you land on the closest lattice point or something very near it. A bad basis is long and skewed, with its vectors pointing almost the same way, and the same rounding step throws you many lattice steps in the wrong direction.

That asymmetry is the whole trick of lattice-based cryptography. The public key is a bad basis, published for anyone to use, and the private key is a good basis for the identical lattice. Both describe the same object, but only one of them makes the geometry easy, and turning a bad basis into a good one is precisely the problem nobody knows how to solve efficiently in high dimension.

Why lattice reduction does not finish the job

Lattice reduction is the name for trying anyway. The LLL algorithm of Lenstra, Lenstra and Lovász, published in 1982, finds a shorter and less skewed basis in polynomial time, and it is genuinely powerful. Its guarantee degrades exponentially with dimension, however, which is why parameters in lattice-based cryptography are chosen to sit far beyond its reach.

The two hard problems

Two questions about lattices carry almost all the weight in lattice-based cryptography. The Shortest Vector Problem, universally abbreviated to SVP, asks for the shortest non-zero vector in the lattice, meaning the lattice point nearest the origin without being the origin itself. The Closest Vector Problem, or CVP, hands you an arbitrary target point somewhere in space and asks for the lattice point nearest to it.

CVP is the more directly useful of the two for building schemes, because encryption naturally produces a point that is a lattice point plus a small perturbation, and decryption is the act of removing that perturbation. SVP is the more studied, and the two are closely related, with CVP being at least as hard as SVP in a precise technical sense.

Both problems are hard in the formal sense that complexity theory recognises, which is where the confidence in lattice-based cryptography originally came from. Miklós Ajtai proved in 1998 that SVP is NP-hard under randomised reductions, and Daniele Micciancio later strengthened this to show it stays hard even if you only want an answer within a small constant factor of optimal. CVP had been known to be NP-hard for longer, and neither result has been overturned.

Two variants matter as much as the originals. The Shortest Independent Vectors Problem, SIVP, asks not for one short vector but for a whole basis of them, all short. Bounded Distance Decoding, BDD, is CVP with a promise attached, namely that the target is guaranteed to sit unusually close to some lattice point, which is exactly the situation a decryption routine finds itself in.

Why approximation decides everything

The NP-hardness results sound like the end of the argument, and they are not. They apply to the exact versions of the problems, or to approximation within a small constant, and no cryptographic scheme relies on those. Every practical construction in lattice-based cryptography rests on approximate versions, where you are asked for a vector within some factor of the true optimum.

That factor is written as gamma and it is a function of the dimension in which the lattice sits. Asking for a vector within a factor of two of the shortest is a brutally hard question. Asking for one within a factor of a thousand, in a lattice of dimension one thousand, is a much softer question, and the softer the question the more likely that some clever algorithm answers it.

There is a decision version too, called GapSVP, which does not ask you to produce a vector at all. It hands you a lattice and a number, and asks only whether the shortest vector is shorter than that number or more than gamma times longer, with the promise that one of the two is true. Decision versions are easier to reason about in proofs, which is why they appear in the theorems even though nobody deploys them.

The uncomfortable part is that the approximation factors cryptography actually uses are not the ones covered by the NP-hardness theorems. Dorit Aharonov and Oded Regev showed that GapSVP with a factor around the square root of the dimension lies in NP intersect coNP, which is strong evidence it is not NP-hard, since an NP-hard problem in coNP would collapse the polynomial hierarchy. Lattice-based cryptography therefore sits in a gap, harder than anything we know how to solve and softer than the problems we know to be NP-hard.

Learning With Errors

Almost nobody builds a cipher directly out of CVP, because handling arbitrary lattices and arbitrary targets is awkward, so lattice-based cryptography works through an intermediary. What is built instead is a problem that packages the difficulty into a form that looks like ordinary algebra, and that problem is Learning With Errors, introduced by Oded Regev at the ACM Symposium on Theory of Computing in 2005 and set out at length in the Journal of the ACM four years later.

Start with a secret vector of numbers, all arithmetic being modulo some smallish prime. Generate a random vector of coefficients, take the dot product with the secret, add a small random error, and publish the coefficient vector together with the smudged answer. Do that thousands of times and hand the whole pile to an attacker.

Without the errors this is the linear algebra of a first-year undergraduate course. Collect enough equations, run Gaussian elimination, and the secret drops out in seconds. The errors ruin that completely, because elimination works by adding and subtracting rows, and every such operation adds the errors together too, so the noise grows faster than the information you are extracting.

The connection to geometry is direct. The set of all vectors you can build from the public coefficients forms a lattice, the published answers are a target point, and the small errors mean that target sits close to a lattice point without being on it. Solving Learning With Errors is Bounded Distance Decoding in disguise, which is why lattice-based cryptography can claim the hardness of lattice problems while looking like arithmetic.

Search, decision and why they are the same

Two versions of the problem appear throughout the literature of lattice-based cryptography and it is worth keeping them apart. Search-LWE is the obvious one, where you are given the noisy equations and asked to produce the secret vector. Decision-LWE is weaker, asking only whether the pile of pairs you have been handed came from the noisy-equation process at all, or whether the answers were simply drawn uniformly at random.

Decision-LWE looks much easier, because you only have to output one bit. That intuition is wrong for the parameters that matter, and Regev’s original paper proved the two are equivalent for a suitable prime modulus, in the sense that an efficient algorithm for either yields an efficient algorithm for the other.

The equivalence is not a technicality. Security proofs for encryption schemes are naturally stated as indistinguishability, meaning an attacker cannot tell a real ciphertext from random noise, which is a decision statement. The hardness assumption people actually believe, on the other hand, is the search statement, that you cannot dig the secret out. The reduction lets a designer argue in whichever language is convenient and inherit confidence from the other.

Ring-LWE and Module-LWE

Plain Learning With Errors is too expensive to deploy, which is the practical problem every implementation of lattice-based cryptography has had to solve. The public key is a whole matrix of random numbers, and in the dimensions needed for security that matrix runs to hundreds of kilobytes, which no protocol designer will accept for a routine key exchange. The fix is to impose structure so that the matrix can be generated from a short seed and multiplied quickly.

Ring-LWE, introduced by Vadim Lyubashevsky, Chris Peikert and Oded Regev at Eurocrypt 2010 and expanded in the Journal of the ACM, replaces vectors of numbers with polynomials. Instead of an unstructured matrix you carry a single polynomial, and multiplying two polynomials in the right ring reproduces the effect of a large structured matrix without ever writing it down. Keys shrink by orders of magnitude and multiplication becomes almost free.

Nothing in cryptography is free, and the cost here is that the attacker now knows a great deal about the shape of your lattice. Ring-LWE lattices are ideal lattices, invariant under a rotation operation that ordinary lattices are not, and that extra symmetry is additional information an attacker might one day learn to use. No attack exploiting it is known against the parameters in use, and the possibility is the standing reason for caution.

Module-LWE is the compromise, and it is the setting NIST chose. Its standard hardness analysis is due to Adeline Langlois and Damien Stehlé, who proved worst-case to average-case reductions for module lattices, and it uses short vectors of polynomials rather than a single long one. You keep most of the speed, because the entries are still polynomials that multiply quickly, and you dilute the algebraic structure, because the module dimension gives back some of the freedom that the ring took away.

The practical benefit is a dial. Raising the module rank increases security without changing the underlying polynomial arithmetic, so a single optimised implementation serves every security level. That is why ML-KEM has three parameter sets that differ chiefly in one integer, and why lattice-based cryptography at the standards level looks tidier than the theory that produced it.

NTRU, the other lineage

Not every scheme in lattice-based cryptography descends from Learning With Errors. NTRU arrived first, published by Jeffrey Hoffstein, Jill Pipher and Joseph Silverman at the Algorithmic Number Theory Symposium in 1998, several years before Regev’s problem existed. It works with polynomials with small coefficients and builds a public key as the quotient of two secret small polynomials.

The lattice appears only in the analysis rather than the design. Attacking NTRU amounts to finding an unusually short vector in a particular lattice built from the public key, so the scheme inherits the difficulty of lattice problems, but it was not derived from them and it carries no worst-case hardness reduction of the kind Regev supplied.

That difference in lineage has practical consequences. NTRU keys and ciphertexts are small and its arithmetic is fast, which made it attractive for decades of embedded use, and the absence of a reduction means confidence rests entirely on the fact that people have tried hard and failed. The Falcon signature scheme is built on NTRU lattices, so the lineage survives into the standards even though the key-exchange standard went the other way.

What a trapdoor really means

The word trapdoor is used loosely in popular writing and precisely in cryptography, and lattice-based cryptography depends on the precise version. A trapdoor function is one that anybody can compute in the forward direction and nobody can invert, except for a party holding a specific piece of extra information, at which point inversion becomes easy. Everything asymmetric, from RSA onwards, is some version of this idea.

In lattice-based cryptography the trapdoor is the good basis. Anyone with the public bad basis can take a message, turn it into a lattice point, and add a small perturbation, which is the easy forward direction. Recovering the message means finding the nearest lattice point to that perturbed target, which requires a description of the lattice with short near-orthogonal vectors, and that is what the private key supplies.

Craig Gentry, Chris Peikert and Vinod Vaikuntanathan formalised this for signatures in their 2008 work on trapdoors for hard lattices, giving a way to sample lattice points near a target that reveals nothing about the trapdoor used to find them. That framework, usually called GPV after its authors, is what Falcon implements. Learning With Errors schemes use a slightly different structure, where the trapdoor is the small secret vector rather than a full basis, but the shape of the argument is identical.

Why lattices are believed to resist quantum attack

Here is the crux, and it is the place most articles overclaim. The honest statement is that no efficient quantum algorithm for the relevant lattice problems is known, and that is a statement about the current state of human knowledge rather than a theorem about what is possible.

Understanding why lattices look different from RSA requires knowing why RSA falls. Shor’s algorithm does not attack factoring head on. It converts factoring into the problem of finding the period of a function, and a quantum computer finds periods efficiently because the quantum Fourier transform over a cyclic group turns a periodic state into a sharply peaked one. Discrete logarithms fall to the same machinery for the same reason, which is why RSA and elliptic curves die together rather than separately.

Lattice problems have no known reduction of that kind. There is no natural hidden period in a lattice for the Fourier transform to expose, and the group structure that makes Shor’s algorithm work is absent. Attempts to force the connection lead to the dihedral hidden subgroup problem, and Regev himself showed that a certain lattice problem reduces to that problem, but the best known quantum algorithm for the dihedral case is Greg Kuperberg’s, which runs in subexponential rather than polynomial time and is not fast enough to threaten anything deployed.

Where Grover helps and where it does not

The other quantum tool is Grover’s algorithm, which searches an unstructured space of size N in about the square root of N steps. That is a real speed-up and it is also a modest one, since it halves the effective bit-security of a search problem rather than collapsing it. The best classical attacks on lattices are sieving algorithms whose running time is exponential in the dimension, and known quantum versions, studied by Thijs Laarhoven, Michele Mosca and Joop van de Pol among others, shave the exponent by a small constant without changing the exponential shape of the curve.

So the case for lattice-based cryptography rests on three legs. The structure Shor exploits is not present, the generic quantum speed-up is only quadratic, and thirty years of concentrated effort by people who would very much like to publish the opposite result have not produced an attack. That is a reasonable basis for deployment and it is not a proof, and anyone selling lattice-based cryptography as provably quantum-safe is overstating what the mathematics supports.

Regev’s quantum reduction

One detail of the theory deserves its own section because it is genuinely odd. Regev’s paper did not merely propose Learning With Errors, it proved that solving the average case of the problem would let you solve worst-case lattice problems, and the proof of that connection uses a quantum algorithm as an internal step.

Worst-case to average-case reductions are the reason theorists take lattice-based cryptography seriously. Most cryptography rests on the belief that a randomly chosen instance of some problem is hard, which is a much stronger and more fragile assumption than saying the hardest instance is hard. Miklós Ajtai discovered in 1996 that lattices support the stronger guarantee, that breaking random instances of a lattice-derived problem would let you break every instance of the underlying one. Regev extended this to Learning With Errors, with the reduction running through Gaussian measures on lattices developed with Daniele Micciancio.

The quantum step sits in the middle of that argument. The reduction moves between a lattice and its dual, and the manoeuvre that makes the transition work is a quantum Fourier transform applied to a superposition over lattice points. A field whose entire purpose is to survive quantum computers therefore has a foundational theorem that only holds if quantum computers exist, which is a pleasing situation and an awkward one.

It also bothered people enough to be partially fixed. Chris Peikert gave a classical reduction in 2009 for a variant of GapSVP at the cost of an exponentially large modulus, and Zvika Brakerski, Adeline Langlois, Chris Peikert, Oded Regev and Damien Stehlé produced a broader classical hardness result in 2013. None of this affects practice, because deployed parameters are chosen against concrete attacks rather than by following the reductions, but it matters for how much the theory is really promising.

The Chen episode of April 2024

On 10 April 2024 the Cryptology ePrint Archive received a paper from Yilei Chen of Tsinghua University titled Quantum Algorithms for Lattice Problems. Its abstract claimed a polynomial-time quantum algorithm for Learning With Errors at certain modulus-to-noise ratios, and, combining that with Regev’s reductions, polynomial-time quantum algorithms for GapSVP and SIVP within approximation factors of roughly the dimension to the power four and a half.

The claim was extraordinary in a precise sense. The abstract noted that previously no polynomial or even subexponential time quantum algorithm was known for those problems at any polynomial approximation factor, so if correct the paper would have moved a boundary that had not moved in twenty years. The techniques were unfamiliar too, using Gaussian functions with complex variances and a windowed quantum Fourier transform.

Eight days later it was over. Chen appended a note to the paper dated 18 April recording that step nine contained a bug he did not know how to fix, and thanking Hongxun Wu and, independently, Thomas Vidick for finding it that day. The paper remains posted, with the author’s stated hope that the complex Gaussian and windowed transform ideas find other uses, and with the central claim explicitly withdrawn.

Two lessons are worth taking from this. The first is that the security of lattice-based cryptography is a live research claim rather than a settled fact, held up by the failure of attacks rather than by a proof, and a serious attempt from a serious researcher is exactly the kind of event that should be expected again. The second is that the review process worked, publicly and within days, which is a better outcome than a quiet flaw discovered years after deployment.

What a KEM is and why the standards use one

A key encapsulation mechanism, universally shortened to KEM, is a stripped-down form of public-key encryption that only ever transports a random key, and it is the shape every standardised construction in lattice-based cryptography takes. It has exactly three operations. KeyGen produces a public encapsulation key and a private decapsulation key, Encaps takes the public key and outputs a ciphertext together with a fresh random shared secret, and Decaps takes the ciphertext and the private key and recovers the same shared secret.

Nothing in that description lets you encrypt a message of your choosing, and that is deliberate. The shared secret goes on to key a symmetric cipher, which does the actual bulk encryption far faster and with far better understood security. FIPS 203 sets out this pattern directly, with Alice generating the keys, Bob running Encaps and sending only the ciphertext, and Alice running Decaps to arrive at the same value.

The restriction is what makes the design tractable. Encrypting attacker-chosen messages with a lattice scheme opens the door to chosen-ciphertext attacks, where an adversary submits deliberately malformed ciphertexts and learns from the pattern of decryption failures. Restricting the payload to a random value the sender generates itself removes an entire class of interactions, and the remaining gap is closed by a transformation described further down this page.

ML-KEM step by step

ML-KEM is the standardised form of CRYSTALS-Kyber, published as FIPS 203 on 13 August 2024, and the underlying scheme was described by Joppe Bos and colleagues at IEEE EuroS and P in 2018. Everything happens in a ring of polynomials of degree less than 256 with coefficients modulo the prime 3329, and the module rank is the single number that separates the three parameter sets. It is the most widely deployed piece of lattice-based cryptography in existence.

KeyGen begins by expanding a short seed into a public matrix of polynomials, so that the bulky part of the key never has to be transmitted. It then samples a secret vector and an error vector, both with deliberately tiny coefficients drawn from a centred binomial distribution, and computes the public value by multiplying the matrix into the secret and adding the error. The encapsulation key is the seed together with that result, and the decapsulation key holds the secret.

Encaps starts from a fresh 32-byte random message. That message is hashed to derive all the randomness the operation needs, then used to produce two more small vectors and a small scalar error, which are combined with the recipient’s public value to form a two-part ciphertext. One part masks the randomness and the other carries the message, scaled up so that a single bit of message becomes a coefficient near either zero or half the modulus.

Decaps uses the secret to compute a quantity that cancels almost all of the large masking term, leaving the scaled message plus an accumulated pile of small errors. Because the message bits were pushed to the extremes of the coefficient range, rounding each coefficient to whichever extreme is nearer recovers the message exactly, provided the accumulated noise stays under a quarter of the modulus. The parameters are chosen so that failure happens with probability far below any rate an attacker could exploit, and FIPS 203 treats a decapsulation failure as a defined and quantified event rather than an impossibility.

The Fujisaki-Okamoto transform

The scheme described above, called K-PKE inside the standard, is only secure against a passive eavesdropper, which is not enough for anything that faces the open internet. FIPS 203 states plainly that K-PKE is not secure against chosen-ciphertext attack and shall not be used on its own, and the gap between the two is closed by a variant of a transformation Eiichiro Fujisaki and Tatsuaki Okamoto introduced for integrating asymmetric and symmetric encryption.

The idea is to make encryption deterministic given the message. Rather than drawing fresh randomness from the machine, the sender hashes the message to obtain the randomness, so that any given message always produces exactly one valid ciphertext. That single change turns a loose relation between plaintexts and ciphertexts into a function that can be checked.

Decapsulation then performs a re-encryption check. Having recovered a candidate message, the receiver runs the entire encryption procedure again on it, using randomness derived from that candidate, and compares the ciphertext it produces with the one that actually arrived. If they match, the ciphertext was honestly generated and the derived key is returned. If they differ, the ciphertext was malformed.

What happens on a mismatch is subtle and matters enormously. ML-KEM does not return an error, because an error message is itself information an attacker can farm across many queries. Instead it performs what FIPS 203 calls implicit rejection, returning a pseudorandom value derived from the ciphertext and a secret stored in the decapsulation key, so that a malformed query yields a key that is wrong but indistinguishable from a right one. The attacker learns nothing from the response, which is precisely the property chosen-ciphertext security demands.

ML-DSA and signing without leaking

Signatures in lattice-based cryptography work differently, because there is no shared secret to agree on and no ciphertext to check. ML-DSA, published as FIPS 204 and derived from CRYSTALS-Dilithium, follows a design template called Fiat-Shamir with Aborts, set out by Vadim Lyubashevsky at Asiacrypt 2009.

The classical Fiat-Shamir idea converts an interactive identification protocol into a signature. In the interactive version the signer commits to a random value, the verifier sends a random challenge, and the signer replies with something that only a key holder could produce. Fiat-Shamir replaces the verifier with a hash function, so the challenge is computed from the commitment and the message, and the whole exchange becomes a single non-interactive object.

In ML-DSA the key generation samples a public matrix from a seed and two short secret vectors, publishing the matrix together with their combination. Signing starts by drawing a masking vector with coefficients spread over a wide range, computing its image under the matrix, and hashing the high-order part of that image together with the message to obtain a challenge polynomial with exactly a few dozen non-zero entries. The response is the masking vector plus the challenge multiplied into the first secret vector.

Verification recomputes the image from the response and the published values, extracts the high-order part, and checks that hashing it with the message reproduces the challenge. A hint, a compact record of a small number of carry corrections, is shipped alongside so that the verifier’s rounding lands where the signer’s did. The signature is the challenge, the response and the hint.

Rejection sampling, the counter-intuitive part

There is a problem with the scheme just described, and it is the most interesting mechanism in all of lattice-based cryptography. The response is the masking vector plus the challenge times the secret. Every signature therefore contains the secret, shifted by a mask, and if the mask is not chosen carefully then thousands of signatures let an attacker average the shifts away and read the key straight out.

The fix is called rejection sampling and it is genuinely counter-intuitive. After computing a candidate response the signer inspects it, and if any coefficient falls outside a narrow permitted band, the signer throws the whole thing away, draws a fresh mask, and starts the signature over. Nothing about the discarded attempt is transmitted or reused.

The purpose is not to catch errors. It is to force the distribution of published signatures to be exactly a fixed distribution that does not depend on the secret key at all. The rejected candidates are precisely the ones that would have leaked, because they are the ones whose value could only have arisen from a particular secret, and by discarding them the signer arranges that what remains could have come from any key. This is why the technique is called Fiat-Shamir with Aborts, the abort being a deliberate feature.

The cost is measured in repetitions and it is not small. FIPS 204 lists the expected number of times the signing loop runs as 4.25 for ML-DSA-44, 5.1 for ML-DSA-65 and 3.85 for ML-DSA-87, so a typical signature is produced on roughly the fourth or fifth attempt. Signing is therefore several times slower than the arithmetic alone would suggest, which is the price of a signature that provably tells you nothing.

The Number Theoretic Transform

Both standards spend most of their time multiplying polynomials, and doing that naively costs a number of operations proportional to the square of the degree. The Number Theoretic Transform is the trick that brings it down to something close to linear, and it is where the speed of lattice-based cryptography comes from.

It is the fast Fourier transform with the complex numbers replaced by arithmetic modulo a prime. The transform needs a root of unity of the right order to exist in that modular world, and whether one exists depends entirely on the prime you picked. This is why the moduli in these schemes look arbitrary and are not, since each was selected so the transform works and so that reduction modulo it is cheap on ordinary processors.

ML-KEM uses the prime 3329, which FIPS 203 writes as two to the eighth times thirteen, plus one. That form guarantees a primitive 256th root of unity, and the standard names it as the integer 17. It does not guarantee a 512th root, and none exists, so the transform cannot split the polynomial all the way down to individual coefficients. Instead it splits it into 128 pairs, and the standard describes the transformed object as a tuple of 128 polynomials of degree one, with multiplication of two transformed elements handled pairwise.

ML-DSA chose differently. Its modulus is 8380417, written in FIPS 204 as two to the twenty-third minus two to the thirteenth plus one, and the standard names 1753 as a 512th root of unity in that field. Because the higher root exists, the transform splits the polynomial completely into 256 independent numbers, so multiplication in the transformed domain is 256 ordinary multiplications. The larger modulus is needed anyway for the signature arithmetic, and getting a complete transform out of it is a bonus the designers took.

Falcon and the price of Gaussian sampling

The third lattice scheme NIST selected in July 2022 was Falcon, to be standardised under the name FN-DSA. Unlike the other two it had not appeared as a final FIPS at the time of writing, and NIST’s own project page lists it as still coming.

Falcon is the compact corner of lattice-based cryptography. It is built on NTRU lattices inside the GPV framework, so it signs by finding a lattice point near a target derived from the message rather than by the commit-and-respond structure of ML-DSA. Its appeal is compactness, since its signatures are markedly smaller than ML-DSA’s at comparable security, and NIST’s own third-round report gives Falcon-512 a public key of 897 bytes and a signature of 666 bytes.

The difficulty is in the sampling. To avoid leaking the trapdoor, the lattice point must be drawn from a discrete Gaussian distribution centred on the target, and doing that correctly requires floating-point arithmetic over a recursive tree structure. Implementing it so that the running time and memory access pattern reveal nothing about the secret is far harder than the integer arithmetic of ML-DSA, and getting it wrong has produced practical key-recovery attacks on earlier Gaussian-sampling signature schemes.

That is the trade, and it is a reasonable one to make deliberately. Falcon suits situations where bandwidth is the binding constraint and the implementation can be audited carefully, while ML-DSA suits everything else because it is much harder to implement badly.

Parameter sets and what they cost

NIST rates candidates against five security categories, defined by comparison with breaking a block cipher or a hash function of a stated size rather than by a single bit count. Category 1 corresponds to the difficulty of exhausting a 128-bit key, category 3 to a 192-bit key and category 5 to a 256-bit key, with categories 2 and 4 pegged to collision-finding on hash functions of 256 and 384 bits.

ML-KEM’s three sets map cleanly onto the odd-numbered categories. FIPS 203 claims ML-KEM-512 in category 1, ML-KEM-768 in category 3 and ML-KEM-1024 in category 5, the numbers in the names being the dimension of the underlying module lattice. ML-DSA is slightly different, with FIPS 204 claiming ML-DSA-44 in category 2 rather than category 1, and ML-DSA-65 and ML-DSA-87 in categories 3 and 5.

What the extra bytes cost in practice

The comparison is unflattering for lattice-based cryptography in one direction and not in the other. An ML-KEM-768 exchange moves about 2.3 kilobytes where X25519 moves 64 bytes, a factor of roughly thirty-five, and that traffic lands in the very first round trip of a connection where latency is most visible. Against RSA-2048 the gap is narrower, since RSA already costs 256 bytes each way, and ML-KEM is dramatically faster to compute than RSA key generation.

Where it hurts most is at the edges of the network. A handshake that no longer fits in a single network packet may need an extra round trip, which is a measurable delay on a slow link, and this concern is why the question was studied carefully well before standardisation, notably in the 2015 analysis of Ring-LWE key exchange for TLS by Joppe Bos, Craig Costello, Michael Naehrig and Douglas Stebila. Constrained devices face a different version of the problem, since a smart card with a few kilobytes of working memory may struggle to hold a signature that a browser does not notice at all.

What SIKE proved about surviving

The strongest argument against complacency about lattice-based cryptography comes from a scheme that was not lattice-based at all. SIKE was built on supersingular isogenies, a construction proposed by David Jao and Luca De Feo in 2011, and it was prized for having by far the smallest keys of any post-quantum candidate. It survived a decade of public scrutiny and advanced to the fourth round of the NIST process.

On 30 July 2022 Wouter Castryck and Thomas Decru posted an efficient key recovery attack to the Cryptology ePrint Archive. Their published version reports that a Magma implementation broke SIKEp434, the parameter set aiming at security category 1, in about ten minutes on a single core. An independent attack by Luciano Maino, Chloe Martindale, Lorenz Panny, Giacomo Pope and Benjamin Wesolowski followed, and both were presented at Eurocrypt 2023.

The attack was classical. No quantum computer was involved, no new hardware was needed, and the mathematics turned on a criterion of Ernst Kani from the 1990s that nobody had thought to point at the problem. A candidate that had been examined for over a decade fell in an afternoon to a machine anyone owns.

Nothing about that episode says lattices are fragile, and it says something important about what survival means. Lattice-based cryptography has been attacked for longer and harder than isogenies were, which is genuine evidence and not a guarantee, and the sensible reading is the one NIST itself took by standardising the hash-based SLH-DSA in FIPS 205 alongside the lattice schemes. Hash-based signatures are slow and bulky and they rest on completely different mathematics, which is exactly the point of keeping one in the toolkit.

The other post-quantum families

Lattice-based cryptography only makes sense in contrast. Lattice-based cryptography won the standards because of what it costs and what it can do, not because it is the only mathematics that resists Shor’s algorithm, and the schemes it beat are still standing behind it as insurance. Four other families were in the running, each resting on a completely different hard problem, and each with a profile of strengths that lattices do not have.

The families are conventionally named after their underlying object rather than their inventor. Codes, hashes, multivariate polynomial systems and isogenies of elliptic curves each supply a one-way operation that nobody knows how to reverse efficiently, with or without a quantum computer. Two of them have lost a flagship scheme to a classical attack in the past few years, none of them lattice-based cryptography, which is the strongest available argument for keeping more than one.

What follows is an honest account of each, including the trade against lattices. None of these is a replacement for the lattice-based cryptography in a browser, and several of them are better than ML-KEM at something specific.

Code-based cryptography and the longest survival record

The oldest post-quantum scheme in existence predates the phrase by decades. Robert McEliece published a public-key cryptosystem based on algebraic coding theory in the Deep Space Network Progress Report for January and February 1978, and its central idea has never been broken.

The construction hides a structured error-correcting code, a binary Goppa code, inside a scrambled generator matrix that looks random. Encryption means encoding a message and then deliberately adding a fixed number of bit errors to it. Anyone holding the scrambling can strip it away, run the code’s fast decoder and remove the errors, while an attacker faces the problem of decoding what appears to be an arbitrary linear code, which is the hard problem the whole family rests on.

Nearly half a century of concentrated attack has improved the constants and left the structure intact. That record is the reason Classic McEliece reached the fourth round of the NIST process and the reason Germany’s federal information security office recommends it today, and the reason it is not in a browser is arithmetic rather than doubt.

The public key is the scrambled matrix, and it is enormous. NIST’s fourth-round report lists 261,120 bytes for the smallest parameter set and 1,357,824 bytes for the largest, against 1,184 bytes for ML-KEM-768. The ciphertexts are tiny by comparison, 96 and 208 bytes respectively, which makes Classic McEliece attractive wherever a key can be installed once and used for years and terrible wherever a key must be sent in a handshake.

HQC and the second key encapsulation mechanism

NIST wanted a KEM that did not rest on lattices at all, and in March 2025 it chose one. HQC, standing for Hamming Quasi-Cyclic, is code-based like Classic McEliece but built on a different principle, and the fourth-round status report describes it as a KEM in which no trapdoor is hidden in the code at all.

That distinction matters. Classic McEliece has to argue that a scrambled Goppa code is indistinguishable from a random one, whereas HQC generates its secret independently of the code used for decryption, so its security reduces to decoding a quasi-cyclic code with no hidden structure to find. NIST notes that the only coding-theory assumption HQC’s proof needs is a parameterisation of the decisional quasi-cyclic syndrome decoding problem, where its rival BIKE needs a second assumption and Classic McEliece needs assumptions about Goppa codes.

Quasi-cyclic structure buys back most of the size. An HQC encapsulation key at the lowest security level is 2,249 bytes and its ciphertext 4,497 bytes, roughly twice ML-KEM-768 rather than two hundred times it. The decapsulation key is only 40 bytes.

The deciding factor against BIKE was not speed. NIST reported persistent uncertainty in BIKE’s decryption failure rate analysis, and since a sufficiently low failure rate is a precondition for the chosen-ciphertext security proof, that uncertainty was fatal. HQC’s failure rate has a closed-form bound, and the report says plainly that this stable analysis was the decisive factor.

Hash-based signatures and the Merkle idea

Hash-based signatures make the smallest security assumption in cryptography. They need nothing except that a hash function behaves like a hash function, with no number theory, no lattices and no structure an algebraist could attack, which means they inherit whatever confidence the community has in SHA-256 and nothing more.

The building block is a one-time signature, a construction in which a key pair can sign exactly one message safely and leaks the private key if it signs two. Ralph Merkle’s contribution, credited by RFC 8391 to work he proposed in 1979 and published as A Certified Digital Signature in the Crypto 1989 proceedings, was to hash many one-time public keys into the leaves of a binary tree and publish only the root. A signature then carries the one-time signature, the one-time public key and the path of sibling hashes up to the root, which is why hash-based signatures are large.

Two of these schemes are already IETF standards and NIST-approved. XMSS is specified in RFC 8391 and the Leighton-Micali scheme in RFC 8554, and NIST approved both in Special Publication 800-208 in October 2020, four years before the lattice standards appeared. They were available early precisely because they needed no new mathematics.

Why statefulness is the dangerous part

The catch in the Merkle construction is that every leaf may be used once, so the signer has to remember which leaves are spent. That memory is part of the private key, which changes every time it signs, and the entire security argument collapses the moment a state is reused.

RFC 8391 puts it without hedging, warning that if a secret key state is used twice then no cryptographic security guarantees remain and it becomes feasible to forge a signature on a new message. The same document tells implementers not to use these schemes except in systems that prevent the reuse of secret key states, and observes that ordinary signature interfaces cannot be used unchanged because the API has to return an updated state.

This is an operational hazard rather than a mathematical one, and operational hazards are the ones that actually happen. Restoring a virtual machine from a snapshot, replicating a key to a standby, or crashing between signing and writing the counter to disk will all silently reuse a state. NIST’s response was to restrict where the schemes may be used, requiring key generation and signing to happen inside hardware modules validated at FIPS 140 level 3 or higher that never export secret keying material.

Special Publication 800-208 states directly that stateful hash-based signature schemes are not suitable for general use because they require careful state management that is often difficult to assure. The application NIST has in mind is signing firmware for constrained devices that will be deployed for decades and cannot have their verification code replaced, which is exactly the case where waiting for a better standard was not an option.

SLH-DSA and the price of forgetting nothing

The stateless variant removes the hazard by removing the counter. Instead of walking through leaves in order, the signer picks a leaf pseudorandomly from a tree so vast that collisions are negligible, and replaces the one-time signature at the bottom with a few-time scheme that tolerates a small number of repeats. That design was published as SPHINCS at Eurocrypt in 2015 and standardised as SLH-DSA in FIPS 205.

Statelessness is paid for in bytes and in seconds, and the comparison with lattice-based cryptography is unflattering. FIPS 205 lists a public key of 32 bytes for the smallest parameter set, which is smaller than ML-DSA’s, alongside a signature of 7,856 bytes for the slow variant and 17,088 bytes for the fast one. The largest parameter set signs in 29,792 or 49,856 bytes depending on the same trade-off, which is six to eleven times an ML-DSA-87 signature.

Nobody expects SLH-DSA to carry ordinary web traffic. It exists so that if lattice-based cryptography fell tomorrow there would already be a standardised, implemented, validated signature scheme resting on assumptions the break could not touch, and that is a rational thing for a standards body to buy even at ten times the size.

Multivariate schemes and a weekend on a laptop

Multivariate cryptography hides a system of quadratic equations in many variables over a small field. Solving a random such system is NP-hard, and the trapdoor is a specially chosen system that is easy to invert, disguised by composing it with secret linear maps at both ends. The appeal is signature size, because a multivariate signature can be a few dozen bytes when a lattice signature is a few thousand.

Rainbow, proposed by Jintai Ding and Dieter Schmidt at the Applied Cryptography and Network Security conference in 2005, was the family’s candidate and a NIST third-round finalist. Its numbers were remarkable in both directions, with a signature of 66 bytes at the lowest security level and a public key of 161,600 bytes according to NIST’s third-round report.

In February 2022 Ward Beullens posted a paper whose title said everything. Breaking Rainbow Takes a Weekend on a Laptop reported new key recovery attacks that outperformed everything known for every parameter set submitted to NIST, and for the lowest security level returned the secret key from the public key after an average of 53 hours of computation on a standard laptop. Rainbow did not advance.

The family survived the loss of its champion. Unbalanced Oil and Vinegar, the older and simpler design Rainbow had generalised, is untouched by the attack and is one of nine schemes still in NIST’s signature process, alongside the newer MAYO, QR-UOV and SNOVA. Multivariate cryptography is now the best-represented family in that process, which is a strange fate for a family whose flagship fell in a weekend.

Isogenies after SIKE

The isogeny family has had the roughest decade and has not left the field. Its objects are supersingular elliptic curves and the maps between them, and its selling point was always size, since an isogeny public key could be a few hundred bytes when everything else was measured in kilobytes.

The 2022 break described earlier removed SIKE and the key-exchange construction it was built on, and it did not remove the underlying problem. Finding an isogeny between two given supersingular curves is still believed to be hard, and what Castryck and Decru exploited was the auxiliary information SIDH publishes about how the secret isogeny acts on a known torsion subgroup, which is an artefact of that particular protocol rather than a property of isogenies.

SQIsign is the family’s answer, a signature scheme rather than a key exchange, and it makes a point of not publishing that information. NIST’s report on the second round of the additional-signature process says explicitly that SQIsign is resilient against the SIDH-related attacks because it avoids the auxiliary torsion-point information those attacks exploited, and that no polynomial-time attack on its core assumptions was reported during the round.

Its case is compactness. NIST records the smallest combined public key and signature of any second-round candidate, with signatures as low as 148 bytes at the lowest security level after a redesign that also made signing roughly twenty times faster and verification six times faster. The cost is that signing remains mathematically intricate and slow, and NIST asks for work on making it fully constant-time.

How the families actually compare

The honest summary is that lattice-based cryptography is the only one of the five that is simultaneously small enough, fast enough and general enough to be a default. Every other family beats it at exactly one thing and loses badly at another, which is why the standards portfolio has one lattice KEM, one lattice signature and a set of deliberate exceptions around it.

Reading across the rows explains the shape of the portfolio. A browser needs the first row, which is lattice-based cryptography, a firmware signer can live with the third, and a satellite that will be in orbit for twenty years might reasonably prefer the second.

The call that started it in 2016

Nothing about the current standards of lattice-based cryptography is accidental, and the process that produced them ran for the better part of a decade in public. NIST published proposed requirements in a Federal Register notice in August 2016, revised them on the strength of public comment, and issued the real call for submissions on 20 December 2016.

The design of that call did more work than any single decision inside it. Submissions had to arrive with a written specification, reference and optimised C implementations, known-answer tests and intellectual property statements, and everything had to be public so that anyone could attack anything. The evaluation criteria were security first, then cost and performance, then algorithm and implementation characteristics, which is the order in which those three things actually matter.

Submissions closed on 30 November 2017. NIST received 82 packages, and by comparison the competition that produced the Advanced Encryption Standard in 1998 attracted 21 and the SHA-3 competition in 2008 attracted 64, so the response was the largest the field had seen.

Sixty-nine candidates and the first cull

Of those 82 packages, 69 met the submission requirements and the minimum acceptability criteria, and NIST announced them as first-round candidates on 20 December 2017. The split was 20 digital signature schemes and 49 public-key encryption schemes or key encapsulation mechanisms, and every package went online for public review.

It is worth being precise about what the first cut measured. The 13 rejected packages were not judged insecure or slow, because NIST’s own account of the round records that completeness was the sole criterion at that stage and that cryptanalysis and performance played no part in acceptance. The competition proper began afterwards.

It began badly for a number of candidates. Several first-round submissions were attacked successfully during the round, which is precisely the outcome an open process is designed to produce, and the field narrowed to 26 second-round candidates in January 2019.

Finalists, alternates and the shape of the decision

July 2020 brought the structure that decided the outcome. NIST named 7 finalists and 8 alternate candidates, a division that let it keep working on schemes it was not going to standardise immediately without pretending they were front runners.

The finalists were the schemes NIST expected to standardise, and the alternates were held back either because they needed more analysis or because they filled a niche the finalists already covered. Classic McEliece was a finalist, and being a finalist did not save it. NIST’s third-round report notes its unusual performance profile of slow key generation and very large public keys against very small ciphertexts, and concluded that it was not being standardised at that time.

Two years of the third round produced the announcement of July 2022. NIST selected CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium, Falcon and SPHINCS+ for signatures, and moved BIKE, Classic McEliece, HQC and SIKE into a fourth round for further consideration. Three of the four selections were lattice-based cryptography.

Why NIST reopened the process for signatures

The concentration in that result was recognised immediately as a problem. Of the four selected algorithms, only SPHINCS+ was not built on structured lattices, and while several non-lattice key encapsulation mechanisms were still alive in the fourth round, no signature scheme outside lattice-based cryptography was left anywhere in the process.

NIST’s report on the round that followed states the motive without euphemism. In July 2022 it announced a forthcoming call for additional digital signature proposals to diversify its post-quantum signature portfolio, and since two lattice signature schemes had already been selected it expressed particular interest in general-purpose schemes built on a security assumption that did not use structured lattices, as well as in schemes with short signatures and fast verification.

The call published in September 2022 encoded that preference as a rule. A lattice-based submission had to offer at least one large performance advantage over both Dilithium and Falcon to be considered at all, while a non-lattice submission only had to offer one large advantage over the existing selections. The process was explicitly weighted against more of the same.

Fifty packages arrived by the deadline of 1 June 2023 and NIST accepted 40 of them as first-round candidates in July 2023. Fourteen advanced in October 2024, and in May 2026 the second-round report named nine third-round candidates, of which exactly one is lattice-based and its own submission team has since withdrawn it.

The March 2025 decision and what remains

The fourth round closed in March 2025 with the selection of HQC and nothing else. NIST stated that the algorithms not selected are no longer under consideration as part of the current process, which retired BIKE, Classic McEliece and SIKE from the American standards track in a single sentence.

That announcement also closed the standardisation process that began with the 2016 call. A draft standard for HQC will be published for comment and a final version is expected roughly two years afterwards, so the second key encapsulation mechanism is not a shipping product yet. The signature on-ramp continues separately.

The other loose end is Falcon. It was selected in July 2022 and, at the time of writing, no initial public draft of FIPS 206 has appeared, so FN-DSA remains a chosen algorithm without a published standard more than three years after selection. NIST’s project page describes Falcon and HQC as selected for ongoing standardisation with that process underway, which is accurate and not a schedule.

Key and signature sizes across the standards

The numbers behind all of this are worth seeing together and on one scale, because the spread is four orders of magnitude and no verbal description survives it. What follows is drawn from the FIPS documents and NIST’s own status reports rather than from the submission teams.

Two things fall out of the picture. The schemes built on lattice-based cryptography cluster within a factor of four of each other in the low kilobytes, which is why a single set of protocol changes accommodates all of them, and the classical schemes they replace are one to two orders of magnitude smaller, which is the whole of the migration cost.

The classical baselines are worth stating from their own specifications rather than from folklore. RFC 7748 defines X25519 with inputs and outputs that are 32-byte strings and scalars that are 32 random bytes, and RFC 8032 states that EdDSA uses small public keys of 32 or 57 bytes and signatures of 64 or 114 bytes for Ed25519 and Ed448 respectively. An Ed25519 signature is therefore 64 bytes against 3,309 for ML-DSA-65.

Falcon’s figures can now be given from a NIST source rather than the submission’s own site. NIST’s third-round report lists Falcon-512 at security level 1 with a public key of 897 bytes, a private key of 7,553 bytes and a signature of 666 bytes, and Falcon-1024 at level 5 with 1,793, 13,953 and 1,280 bytes respectively.

What a security estimate actually is

Every parameter set in lattice-based cryptography carries a stated number of bits attached to it, and those numbers are not measurements. They are the output of a model of the best known attack, evaluated at the chosen parameters, with a stack of assumptions underneath about which algorithm an adversary would run and what each step of it costs.

That is a different kind of claim from the one attached to AES. Nobody has a better attack on AES-128 than trying all the keys, so its 128 bits is close to a statement about the design itself. A bit count in lattice-based cryptography is a statement about the state of cryptanalysis, and it moves when the cryptanalysis moves, in either direction.

Understanding which direction it moves in requires knowing the pieces. An attack on the Learning With Errors problem underneath lattice-based cryptography turns the noisy equations into a lattice problem and then runs a reduction algorithm on that lattice, and essentially all the cost is inside the reduction. Two families of attack matter, called the primal and the dual, and both are driven by a single tuning parameter.

LLL and what polynomial time buys

Reduction in lattice-based cryptography begins with the algorithm of Arjen Lenstra, Hendrik Lenstra and László Lovász, published in Mathematische Annalen in 1982 in a paper ostensibly about factoring polynomials with rational coefficients. It takes any basis and returns a shorter, less skewed one in time polynomial in the dimension, which is a remarkable guarantee and a weak one.

The weakness is in the quality. What LLL promises is a vector no longer than roughly two to the power of the dimension times the true shortest, and that bound decays exponentially, so in dimension eight hundred the guarantee is worthless. LLL is nevertheless the workhorse underneath everything, because it is what larger algorithms call to tidy up.

The practical significance of LLL for lattice-based cryptography is that it draws the floor. Any parameter set that LLL alone could handle is dead on arrival, and no deployed set is anywhere near that line, so the real question is what happens when you spend more than polynomial time.

BKZ and the block size dial

The answer is the Block Korkine-Zolotarev algorithm, introduced in the practical form everyone uses by Claus-Peter Schnorr and Michael Euchner in Mathematical Programming in 1994 and refined by Yuanmi Chen and Phong Nguyen as BKZ 2.0 in 2011. It generalises LLL by working on overlapping windows of the basis rather than on pairs of vectors.

The width of that window is the block size, written b, and it is the only dial that matters. Inside each block the algorithm solves the shortest vector problem exactly, using an oracle that is exponentially expensive in b and nothing else, and the number of times it calls that oracle stays polynomial. So the cost of the whole attack is essentially the cost of one call at block size b, and the quality of the output improves as b grows.

Choosing parameters in lattice-based cryptography therefore reduces to a single question, which is how large b would have to be before BKZ solved your instance. Answer that and multiply by the cost of the oracle, and you have a security estimate.

Sieving against enumeration

There are two ways to build the oracle inside BKZ, and they have opposite shapes. Enumeration searches a tree of candidate coordinate vectors, taking time superexponential in the block size but only a polynomial amount of memory. Sieving keeps an exponentially large list of lattice vectors and repeatedly combines them into shorter ones, taking exponential time and exponential memory.

Sieving as a provable technique dates to Ajtai, Kumar and Sivakumar in 2001, and for a long time it lost in practice. Enumeration was faster in every dimension anyone could reach, which is why security estimates in the 2000s were set against enumeration and were consequently aggressive.

That flipped. Nearest-neighbour techniques brought the heuristic cost of sieving down, with the analysis of Becker, Ducas, Gama and Laarhoven giving an exponent of about 0.292 times the block size, and implementation work brought the crossover point where sieving overtakes enumeration down to a block size of roughly eighty. Current shortest-vector records are held by sieving.

The memory question is not settled and it is the largest soft spot in every estimate. Sieving assumes free access to exponentially large memory, which no real machine offers, and the CRYSTALS-Kyber specification notes candidly that no study yet investigates the practical performance of sieving using slow background storage. An attacker who has to page an exponential list to disk is slower than the model says, by an amount nobody has quantified.

The core-SVP methodology and why it is deliberately pessimistic

The convention that most NIST submissions use for their headline numbers is called core-SVP, and it was introduced in the New Hope key exchange paper of Erdem Alkim, Léo Ducas, Thomas Pöppelmann and Peter Schwabe, published at USENIX Security in 2016. Its logic is to be indefensibly generous to the attacker on purpose.

The method counts the cost of exactly one call to the shortest-vector oracle at the required block size and throws away everything else. It ignores the polynomial number of calls BKZ actually makes, ignores all sub-exponential factors in the sieve, and assumes memory access is free. Whatever an attack really costs, it costs at least this, so a parameter set that is safe under core-SVP is safe under the real attack.

Applied to Kyber the arithmetic is simple. The submission reports block sizes of 406, 626 and 878 for the three parameter sets, and multiplying by 0.292 gives 118, 183 and 256 bits of classical core-SVP hardness, which is where the security-category claims come from. The corresponding figures against an attacker with Grover’s algorithm inside the sieve are 107, 166 and 232.

The designers do not present these as accurate. The Kyber specification says in terms that the core-SVP methodology, having pushed designers to be more conservative than before, now appears too coarse to produce accurate security estimates, and it offers a refined gate-count analysis giving 151.5 bits for the smallest parameter set rather than 118. The published number is a floor that the authors themselves believe is well below the truth, which is exactly what a floor should be.

The dual attack dispute of 2023

Security estimates move, and the clearest recent example of how is a dispute that has still not fully closed. The dual attack is the second of the two families, working with the dual lattice rather than the primal one, and in 2021 and 2022 two independent groups claimed to have improved it substantially by bolting a fast Fourier transform onto the front.

Qian Guo and Thomas Johansson published the first of these at Asiacrypt in 2021, explicitly targeting the CRYSTALS schemes, and a 2022 technical report from MATZOV reached similar conclusions independently. Taken at face value the claims narrowed the margin on the smallest Kyber parameter set, and they were debated in public at length.

In February 2023 Léo Ducas and Ludo Pulles submitted a paper asking whether the attack even works. Their analysis found that the heuristics underneath all of this line of work contradict formal unconditional theorems in some regimes and well-tested heuristics in others, that the specific instantiations in the recent literature fall into the second case, and that experiments show behaviour the analysis does not predict, including a waterfall-and-floor pattern reminiscent of decoding failures in error-correcting codes.

Their conclusion, published at Crypto in 2023, was that the success probability of the recent dual-sieve attacks is presumably significantly overestimated. That is not a claim that the attacks are worthless, and the paper also contributes a genuine generalisation of the technique, but it withdrew most of the ground the estimates had appeared to lose.

The episode is a fair picture of how cryptanalysis of lattice-based cryptography actually works. A claimed improvement arrives, the numbers in everyone’s tables shift, a careful re-analysis finds the underlying heuristic unjustified, and the numbers shift back. Anyone reading a bit count for lattice-based cryptography should understand that it is a snapshot of an argument rather than a property of the algorithm.

Ajtai’s reduction, stated carefully

The single most misquoted fact about lattice-based cryptography is its worst-case to average-case reduction, and the misquotation always takes the same form, which is to present it as a proof of security. It is not one, and understanding exactly what it does say is worth the effort because the thing it does say is genuinely unusual.

Start with the problem it solves. Cryptography needs random instances of a hard problem to be hard, because a key generator produces random instances, and that is a much stronger requirement than a problem merely having hard instances somewhere. Factoring is believed to be hard on random inputs of the right shape, but nothing proves it, and a scheme built on a problem that is hard in the worst case and easy on average is worthless.

Miklós Ajtai showed in a 1996 paper at the Symposium on Theory of Computing that lattices escape this bind. He constructed a distribution of random instances with the property that an algorithm solving a random instance with non-negligible probability could be turned into an algorithm solving every instance of a standard lattice problem. Randomly generated lattice keys are therefore as hard as the hardest case, which is a guarantee no other major family offers.

What the reduction does not give you

Three things follow that most summaries leave out. Taken together they explain why nobody sets parameters using the reduction, and why treating it as a security proof is a category error rather than a small exaggeration.

The first is that the worst-case problem is itself only conjectured hard. The reduction says average-case difficulty follows from worst-case difficulty for an approximate lattice problem at a particular factor, and as established earlier on this page, at the approximation factors cryptography uses that problem sits in NP intersect coNP and is therefore almost certainly not NP-hard. The reduction transfers confidence, it does not create it.

The second is that the reduction is loose. It relates the two problems up to polynomial factors in the dimension, and those polynomials are large enough that following them honestly would demand parameters far bigger than anything deployed. If ML-KEM’s parameters were derived from Regev’s theorem rather than from cryptanalysis, its keys would not fit in a handshake.

The third follows from the second. Deployed parameters are set against concrete attacks, which is why the previous sections of this page are about BKZ block sizes and sieving exponents rather than about theorems. The CRYSTALS-Kyber specification derives its parameter claims from core-SVP and gate counts, and the worst-case reduction appears in the security discussion as a structural argument rather than as a source of numbers.

What the reduction genuinely provides is a sanity check on the design. It says that the distribution the key generator samples from has no weak instances hiding in it, that there is no equivalent of a weak RSA modulus waiting to be generated by accident, and that the problem the attacker faces is not a special easy case of the problem the theorists study. That is worth having and it is not a proof of security.

Where lattice-based cryptography actually breaks in the field

No deployed instance of lattice-based cryptography has ever been broken by lattice reduction. Every real compromise of a real deployment has come from the implementation, from the gap between the mathematical object in the specification and the machine instructions that stand in for it, and that has been true of RSA and elliptic curves for thirty years as well.

The mechanism is always the same in outline. A secret value influences something an observer can measure, and the observer measures it enough times to reconstruct the secret. What varies is the channel, which may be how long the operation takes, how much current the chip draws, what noise it emits, which cache lines it touches, or how it behaves when something is deliberately made to go wrong.

Schemes built on lattice-based cryptography are not unusually fragile, and they do have a distinctive risk profile. They perform a great deal of arithmetic on secret polynomials with small coefficients, they use rejection or comparison steps whose outcome depends on secret data, and in Falcon’s case they need floating-point arithmetic, which is the hardest thing in cryptography to make constant-time.

KyberSlash and a division that leaked

The clearest recent example is a pair of timing vulnerabilities named KyberSlash, found in several implementations of Kyber including the official reference code. The flaw was a division by the modulus q whose operands depended on secret data, in the routines that convert between polynomial coefficients and message bits.

On processors where integer division takes a variable number of cycles depending on its inputs, and many embedded cores are exactly like that, the time taken to run those routines carries information about the secret. The consequence is not theoretical. The paper by Daniel Bernstein and colleagues, posted as Cryptology ePrint Archive report 2024/1049 and published in the transactions of the cryptographic hardware and embedded systems conference, demonstrates key recovery on a Raspberry Pi 2 and an Arm Cortex-M4, reporting that secret keys were reliably recovered within minutes for one variant and a few hours for the other.

What makes the episode instructive is what the authors did next. They patched the dynamic analysis tool Valgrind so that it could detect variable-time instructions operating on secret data, then pointed it at more than a thousand implementations of cryptographic primitives in a standard benchmarking suite and reported multiple further findings. The vulnerabilities were disclosed to library maintainers and patched.

The specification was never wrong. Nothing in FIPS 203 asks anyone to divide by q in variable time, and the published standard does not discuss side channels at all, because a specification describes an algorithm rather than a machine. An algorithm that is sound on paper and implemented in a way that leaks timing is an insecure system.

Why Falcon’s sampler is so hard to write

Falcon deserves its own treatment here because its difficulty is structural rather than accidental. Signing requires drawing a lattice point from a discrete Gaussian distribution centred on a target derived from the message, and the distribution has to be right to a high degree of precision or the signatures leak the trapdoor.

The reason precision matters is a specific attack. Phong Nguyen and Oded Regev showed at Eurocrypt in 2006 that if a signature scheme samples from a region shaped like the fundamental parallelepiped of the secret basis, then a few hundred thousand signatures were enough to learn that shape and recover the private key. Their attack broke the GGH and NTRUSign schemes outright. The Gaussian is used because it is the one distribution whose shape betrays nothing about the basis that produced it.

Getting that shape correct in practice requires floating-point arithmetic over a recursive tree structure, and floating point is a hostile environment for constant-time code. The time a processor takes on a floating-point operation can depend on whether an operand is subnormal, rounding behaviour differs between platforms, compilers reorder and contract floating-point expressions, and vector units may or may not be used depending on the data.

Attacks have followed. Emre Karabulut and Aydin Aysu demonstrated a side-channel attack recovering Falcon keys at the Design Automation Conference in 2021, targeting the floating-point multiplications inside the sampler. None of this makes Falcon insecure as a design, and it does mean that the number of people who can implement it safely is much smaller than the number who can implement ML-DSA safely.

That asymmetry is the practical reason ML-DSA is the general-purpose signature standard and Falcon is the specialist one. ML-DSA works entirely in integer arithmetic modulo a prime, and while its rejection step also has to be handled carefully, there is no floating point anywhere in it.

Fault injection and the signature that gives itself away

A passive attacker listens. An active one with physical access can do better by making the device compute the wrong thing on purpose, using a voltage glitch, a clock glitch, a laser pulse or focused electromagnetic radiation, and then reading the answer.

Signatures in lattice-based cryptography have a characteristic vulnerability to this, and it was described early. Thomas Espitau, Pierre-Alain Fouque, Benoît Gérard and Mehdi Tibouchi showed in work presented at Selected Areas in Cryptography in 2016 that interrupting the loop which generates the random masking vector, so that only part of it is filled in, produces a signature that is still valid but that no longer hides the secret. A small number of such faulted signatures is enough to recover the key.

The defence is the same as everywhere else in this area and it is not free. Signing operations have to be checked before they are released, ideally by verifying the signature the device just produced, and the masking generation loop has to be structured so that an early exit is detectable. Every countermeasure costs time and code, and each one is a place where an implementation can be wrong.

Single-trace attacks close the gap further. Robert Primas, Peter Pessl and Stefan Mangard demonstrated at the cryptographic hardware conference in 2017 that a masked lattice encryption implementation could be attacked from a single power trace by targeting the number theoretic transform, which is unwelcome because masking is the standard countermeasure and single-trace attacks defeat the assumption that an attacker needs many observations.

Why constant time matters more than hardness in practice

Put the two halves of this page side by side and the practical conclusion is uncomfortable. On one side sits a hardness assumption that has survived thirty years of attack by people strongly motivated to break it, with the best known algorithm exponential in the dimension. On the other sits a division instruction that took a few extra cycles on a Cortex-M4 and gave up the key in minutes.

The gap between those two is where security is actually won and lost. An attacker facing a correctly implemented ML-KEM has to run a sieve in dimension a thousand, and an attacker facing a carelessly implemented one has to run a stopwatch. Nothing in the mathematics helps with the second case.

This is why the serious work in deploying lattice-based cryptography is not algorithm selection. It is formally verified implementations, constant-time discipline enforced by tooling rather than by review, test suites that measure timing variation as a first-class property, and the willingness to prefer a scheme that is harder to get wrong over one that is a few hundred bytes smaller. NIST’s choice of ML-DSA over Falcon as the general-purpose signature is exactly that preference expressed as a standard.

The homomorphic encryption connection

Learning With Errors carries more than the post-quantum standards. The same assumption underneath lattice-based cryptography is also the foundation of fully homomorphic encryption, the technique that lets a server compute on data it cannot read, and the fact that both rest on the same assumption is the strongest indication of how much weight that assumption is being asked to bear.

The connection is not a coincidence of history. Homomorphic encryption needs a ciphertext that can be added and multiplied while still decrypting correctly, and an LWE ciphertext is a lattice point plus a small error, so adding two of them adds the errors and multiplying them multiplies the errors. The scheme works for as long as the accumulated noise stays below the decryption threshold, which is exactly the budget that governs an ML-KEM decapsulation, used deliberately rather than avoided.

Craig Gentry’s 2009 construction, the first fully homomorphic scheme, used ideal lattices and introduced bootstrapping, the trick of homomorphically evaluating the scheme’s own decryption circuit to reset the noise. Everything practical since then has moved to Learning With Errors over rings.

BFV, BGV and CKKS

Three schemes account for almost all deployed homomorphic encryption, and all three are Ring-LWE constructions. They differ in what they encode and how they manage noise rather than in what they assume.

BGV, from Zvika Brakerski, Craig Gentry and Vinod Vaikuntanathan at the Innovations in Theoretical Computer Science conference in 2012, showed that a levelled homomorphic scheme could be built without bootstrapping by switching to a smaller modulus after each multiplication, trading circuit depth for a fixed parameter budget. BFV, which Junfeng Fan and Frederik Vercauteren obtained by porting Brakerski’s scale-invariant scheme to the ring setting in a 2012 preprint, keeps the modulus fixed and scales the plaintext instead. Both compute exactly on integers.

CKKS is the one that changed what homomorphic encryption is used for. Jung Hee Cheon, Andrey Kim, Miran Kim and Yongsoo Song proposed at Asiacrypt in 2017 that the noise be treated as part of the message rather than as something to be removed, encoding real numbers approximately and accepting a small error in the result. That turns homomorphic encryption from exact integer arithmetic into approximate arithmetic on vectors of reals, which is what machine learning workloads actually want.

The approximation carries a subtlety that took several years to surface. Baiyu Li and Daniele Micciancio showed at Eurocrypt in 2021 that the standard security notion is not sufficient when decryption results are approximate, because the error in a decrypted result depends on the secret and can be used to recover it if an adversary sees decryptions of ciphertexts it chose. The fix is to add noise before releasing a decryption, and the episode is another instance of the pattern running through this page, where the assumption held and the way it was used did not.

How much the LWE assumption is carrying

Add it up. The key exchange standard for the American federal government and, through browser deployment, for a majority of internet traffic rests on Module-LWE. The general-purpose signature standard rests on Module-LWE. The compact signature scheme awaiting its standard rests on NTRU lattices. The main homomorphic encryption libraries rest on Ring-LWE. Several of the leading candidates in NIST’s signature on-ramp rest on multivariate or code assumptions specifically to avoid adding to that pile.

This concentration is not an argument that the assumption behind lattice-based cryptography is wrong. It is an argument that the consequences of it being wrong are much larger than they would be for any single scheme, and that a break would not be contained by switching one algorithm for another.

It is also why the 2024 preprint discussed earlier drew the reaction it did. A polynomial-time quantum algorithm for Learning With Errors at cryptographic parameters would not have been a problem for ML-KEM. It would have been a problem for ML-KEM, ML-DSA, every homomorphic encryption library in production and a decade of academic constructions built on top of them, all in the same week.

Hybrid key exchange and why it exists

Almost nobody deploying lattice-based cryptography for key exchange today deploys it alone. The dominant pattern is hybrid, running a classical key agreement and a post-quantum one side by side in the same handshake and combining both outputs into the session key, so that the connection stays confidential as long as at least one of the two survives.

The reasoning is stated plainly in the IETF specification. RFC 9954, published in July 2026 by Douglas Stebila, Scott Fluhrer and Shay Gueron, describes a hybrid key exchange as letting early adopters have the potential of post-quantum security, possibly from a less-well-studied algorithm, while still retaining at least the security currently offered by traditional algorithms.

Read that against everything above and it is obviously the right call for now. Lattice-based cryptography is the youngest of the five families, its security estimates have moved twice in the past four years for reasons of cryptanalysis rather than mathematics, and the classical algorithms it replaces are only broken by a machine that does not yet exist. Combining them costs a few hundred microseconds and a couple of kilobytes.

Hybrids also solve a compliance problem for lattice-based cryptography that has nothing to do with mathematics. An organisation with a validated classical implementation and a regulatory requirement to use it cannot simply switch it off, and a hybrid lets the post-quantum component be added without removing anything.

X25519MLKEM768 and how the internet actually does it

One combination has become the de facto standard for the web. X25519MLKEM768 pairs the elliptic-curve Diffie-Hellman function of RFC 7748 with ML-KEM-768, and it holds codepoint 4588, written 0x11EC, in the IANA TLS supported groups registry, where it is marked as recommended.

The construction is deliberately plain. Both key exchanges run in the same round trip, the client sends both key shares in its first message, and the final shared secret is the concatenation of the ML-KEM shared secret and the X25519 shared secret fed into the usual key schedule. The ML-KEM component is placed first for a compliance reason rather than a cryptographic one, so that the approved scheme leads the concatenation.

Getting to that codepoint took an awkward detour. Chrome shipped a hybrid using the pre-standard Kyber under codepoint 0x6399, and when Kyber became ML-KEM the technical changes made the two incompatible. Google’s Chrome team explained in September 2024 that the codepoint was therefore changing to 0x11EC, that Chrome 131 would switch from Kyber to ML-KEM, and that Chrome would not support both simultaneously because post-quantum key shares are too large to offer two of them at once.

The size of that first message is the whole engineering story. A ClientHello carrying an ML-KEM-768 key share no longer fits in one network packet, and although the TLS specification always permitted a larger one, middleboxes and load balancers had quietly assumed otherwise. Protocol ossification, not cryptography, was the obstacle.

What the deployment numbers show

Post-quantum key exchange is no longer an experiment. The figures below come from the network operators rather than from standards bodies, so they should be read as company measurements of their own traffic rather than as independent survey data.

Cloudflare, which enabled post-quantum key agreement on its server side by default in October 2022, reported in its state of the post-quantum internet review of 28 October 2025 that over half of human traffic reaching it was protected against store-now-decrypt-later attacks, and described post-quantum key agreement as the new security baseline for the web. Its timeline places Chrome’s default rollout on desktop in March 2024, Go’s default in August 2024, Chrome on Android and Firefox on desktop in November 2024, OpenSSL in April 2025 and Apple’s platforms in October 2025.

Server-side adoption lags and is moving. The same review cites Jan Schaumann’s regular scans of the top hundred thousand domains, reporting 39 per cent supporting post-quantum key agreement in September 2025 against 28 per cent six months earlier. Origin servers behind content delivery networks are further behind still.

Signatures have barely started, and the reason is bandwidth. Cloudflare notes that around 18 million TLS connections are established with its network every second and estimates that upgrading each to ML-DSA-44 authentication would consume 2.1 terabits per second, which it puts at about half a per cent of its total network capacity. The capacity is affordable; the per-connection latency of a certificate chain that no longer fits in the initial congestion window is the difficulty.

That split is worth holding onto. Key exchange has migrated because it had to, since traffic recorded today can be decrypted later, and authentication has not migrated because a signature forged in 2040 cannot retroactively compromise a session in 2026.

CNSA 2.0 and the American national security position

The National Security Agency runs its own algorithm suite for national security systems, and its post-quantum version diverges from ordinary practice in an instructive way. The Commercial National Security Algorithm Suite 2.0 comprises ML-KEM-1024, ML-DSA-87, AES with 256-bit keys, SHA-384 and SHA-512, and the stateful hash-based signature schemes LMS and XMSS.

Two features stand out. The suite goes straight to the highest parameter sets, taking ML-KEM-1024 and ML-DSA-87 rather than the middle options most of the internet uses, which is a defensible choice for traffic that must stay secret for decades. It also includes the stateful hash-based schemes, restricted as NIST restricts them, for signing software and firmware.

The more striking feature is what it excludes. The NSA-authored profile for TLS 1.3, published as an IETF draft by Alison Becker and Michael Jenkins of the NSA Center for Cybersecurity Standards, requires ML-KEM-1024 to be the first and most preferred key exchange offered and states that any algorithm other than ML-KEM-1024 offered by the client must not be selected. A compliant connection uses post-quantum key establishment alone, with no classical component at all.

That is the opposite of the hybrid consensus described above. The NSA has not adopted hybrid key exchange for national security systems, and its published profiles require the post-quantum algorithm on its own rather than alongside a classical one. Whatever the reasoning, the effect is to place the American national security position on the far side of a real disagreement from its European counterparts.

The deprecation dates in NIST IR 8547

For ordinary American federal systems the timetable lives in a different document. NIST Internal Report 8547, issued as an initial public draft in November 2024, sets out when the quantum-vulnerable algorithms stop being acceptable, and it is the closest thing to a hard deadline that exists.

The scheme is simple once the vocabulary is clear. Deprecated means an algorithm may still be used with a stated risk, and disallowed means it may not be used at all. The draft places ECDSA, EdDSA and RSA signatures at the 112-bit security level, and finite-field and elliptic-curve Diffie-Hellman and RSA key establishment at the same level, as deprecated after 2030 and disallowed after 2035. Everything at 128 bits of classical security or above is disallowed after 2035 as well.

The 2035 date is not NIST’s invention. It follows National Security Memorandum 10, which set 2035 as the target for mitigating as much of the quantum risk to American systems as is feasible, and the report is explicit that widespread adoption by that year is the goal.

One detail of the draft is worth noticing because it represents a change of plan. Existing guidance had projected disallowing 112-bit public-key schemes on 1 January 2031, and NIST states that it now intends to deprecate rather than disallow them at that point, precisely because organisations need the room to migrate. The deadline moved outward to make the migration achievable, not because the risk receded.

Crypto-agility as the actual deliverable

The most useful thing to take from all of this is that the algorithm is not the deliverable. The particular flavour of lattice-based cryptography in ML-KEM will be replaced eventually, HQC is coming as a second key encapsulation mechanism, FIPS 206 will arrive, the signature on-ramp will produce something, and any system that treats its current algorithm as permanent will have to be rebuilt each time.

Crypto-agility means the ability to change algorithm without changing the system around it, whether the replacement is more lattice-based cryptography or something else, and it is mostly an inventory and architecture problem rather than a cryptographic one. It requires knowing where every key, certificate and protocol negotiation lives, being able to negotiate rather than hard-code, sizing buffers and message formats for objects larger than the ones in use, and having a tested path for rotating a key type rather than a key.

The migration to post-quantum cryptography is the first time most organisations will exercise any of this. Doing the work in a way that only reaches ML-KEM misses the point, because the next transition, whether it is prompted by HQC, by a new signature standard or by an attack, will arrive against systems that have just proved they can move.

Standards beyond NIST

It is easy to read the post-quantum transition as an American programme with international spectators, and that reading is wrong in a way that matters to anyone deploying across borders. NIST sets the algorithms of lattice-based cryptography, and it does not set the rules for how they are used, and on the question that most affects real deployments the European agencies disagree with the American position.

Three layers of standardisation need separating. There are algorithm standards, which is what FIPS 203, 204 and 205 are. There are protocol standards, which say how an algorithm is carried inside TLS or IPsec or S/MIME, and those come from the IETF. Then there are national recommendations, which say what an organisation subject to a particular regulator is expected to do, and those are where the disagreement lives.

The IETF and the protocol layer

An algorithm in lattice-based cryptography without a protocol binding is unusable, and most of the work of actually shipping post-quantum cryptography has happened in IETF working groups rather than at NIST. The hash-based signature schemes reached the IETF first, with XMSS specified in RFC 8391 in May 2018 and the Leighton-Micali scheme in RFC 8554 in April 2019, both years before the lattice standards existed.

For TLS the central document is RFC 9954 on hybrid key exchange, which defines how two key exchange outputs are combined and what the resulting groups look like on the wire. The specific hybrid groups follow in a companion document, which at the time of writing has been approved and is with the RFC Editor, and its three named groups are already registered with IANA as X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024.

The NSA is publishing its own profiles through the same process, with CNSA 2.0 documents in preparation for TLS 1.3, SSH, IPsec, S/MIME, certificate management and certificate profiles. That is the mechanism by which a national policy becomes something an implementer can code against, and it is why those documents are worth reading even for organisations that are not national security systems.

Where Germany’s BSI differs

The German federal office for information security publishes its recommendations as a technical guideline, TR-02102-1. The current version is dated January 2026, and it differs from American practice on three points, each of them deliberate rather than incidental.

The first is hybridity. The guideline states that it currently only recommends the hybrid use of quantum-safe methods in combination with classical methods, and gives the reason plainly, which is that the quantum-safe methods are comparatively new and less investigated, especially with regard to implementation security. Where the NSA’s TLS profile forbids anything other than pure ML-KEM-1024, the BSI recommends against pure post-quantum deployment entirely.

The second is which KEMs are acceptable. The BSI recommends four, and it recommended two of them in March 2020, four years before FIPS 203 existed. FrodoKEM and Classic McEliece came first, ML-KEM was added after standardisation, and HQC is to be added once its standard is final.

The third is the reason FrodoKEM is on that list at all. NIST declined to standardise FrodoKEM because ML-KEM, resting on the same Learning With Errors problem, is more efficient. The BSI’s guideline says that because FrodoKEM is based on unstructured lattices where ML-KEM is not, it is considered the more conservative choice, which is the algebraic-structure worry described earlier on this page turned into a national recommendation.

One further detail is easy to miss. The BSI recommends ML-KEM only at the parameter sets corresponding to NIST security categories 3 and 5, which is to say ML-KEM-768 and ML-KEM-1024. ML-KEM-512, the set whose security margin the dual-attack dispute narrowed, is not in the German recommendation at all.

Where France’s ANSSI differs

The French agency reached the same place by a different route and stated it more forcefully. Its follow-up position paper on post-quantum cryptography, dated 21 December 2023, says that ANSSI still strongly emphasises the necessity of hybridation wherever post-quantum mitigation is needed, in both the short and the medium term.

The justification is empirical rather than theoretical. The paper observes that post-quantum algorithms are not yet mature enough to ensure security on their own and points at the classical attacks that have broken post-quantum schemes in recent years, which is to say Rainbow and SIKE, and notes that its position is aligned with that of other European agencies including the BSI.

ANSSI has also made hybridity a certification requirement rather than advice. Its security visa process runs in three phases, and in the second phase the cryptographic evaluation covers post-quantum algorithms with mandatory hybridation, so a product that implements post-quantum mitigation without a classical component cannot pass. There is a carve-out for hash-based signatures, where hybridation is optional, which is consistent with the argument, because the hash assumption is the one nobody doubts.

ETSI and the wider standards ecosystem

The European Telecommunications Standards Institute has been working on quantum-safe cryptography through its cyber security committee since well before the NIST selections, and its output is mostly about how to migrate rather than what to migrate to. Its technical report TR 103 619 on migration strategies and recommendations to quantum-safe schemes appeared in July 2020, and its technical specification TS 103 744 on quantum-safe hybrid key exchanges followed in December 2020.

That the hybrid specification predates the NIST selections by eighteen months is the point. The European institutional view that hybridity is the default was formed before there were any post-quantum standards to be hybrid with, and it has not changed since.

NIST is not opposed to any of this, which is worth stating clearly because the disagreement is about defaults rather than about permission. Its recommendations for key encapsulation mechanisms, published as Special Publication 800-227 in September 2025, includes an approved treatment of multi-algorithm schemes and post-quantum and traditional hybrids, sets out approved key combiners, and observes that a well-designed multi-algorithm scheme will be secure if at least one of its components is secure.

The practical result for anyone deploying lattice-based cryptography internationally is that hybrid is the safe choice almost everywhere. It satisfies the European recommendations, it satisfies NIST, it is what the browsers already do, and the only place it is actually prohibited is inside American national security systems following CNSA 2.0. Building for the hybrid case and treating pure post-quantum as the special case is the configuration that ages best.

A glossary of the terms used here

The vocabulary of lattice-based cryptography is dense and much of it is used loosely elsewhere. The definitions below are the ones this page has been using, gathered so that they can be found again without rereading the argument.

Frequently asked questions