Your evidence has an expiry date and nobody printed it on the label
By Dylan Wolpe
The short version
- Encryption and signatures age differently under quantum attack. AES-256 loses half its bits to Grover and 128 remains out of reach; Ed25519 is broken outright by Shor, so the signature is the part with the shelf life.
- This matters most for evidence rather than confidentiality: a certificate is meant to be checked years after it was issued, and an unverifiable signature makes it worthless retroactively.
- The standardised answer is hash-based signatures, SLH-DSA, FIPS-205, which rest only on hash security and are therefore not threatened by Shor's algorithm.
- We ship SLH-DSA dual-signing in the public CLI, validated against NIST's ACVP vectors: `at1 century pq-migrate` for existing certificates, and `at1 erase --pq` for erasure certificates from version 0.1.80.
Most quantum-computing discussion in security concerns confidentiality, the worry that encrypted traffic captured today will be readable later. For anyone whose product is evidence rather than secrecy, the more immediate exposure runs the other way, and it has an awkward property: you cannot fix it retroactively.
Two different clocks
Symmetric encryption is in reasonable shape. Grover’s algorithm gives a quadratic speed-up against a key search, which costs AES-256 roughly half its bits. The remaining 128 are not practically attackable, so a well-encrypted archive stays well encrypted.
Signatures are a different matter. Ed25519, RSA and ECDSA all rest on problems Shor’s algorithm solves efficiently. A sufficiently capable quantum computer does not weaken them; it ends them.
| Under quantum attack | Can you fix it later? | |
|---|---|---|
| AES-256 payload | ~128 bits remaining, fine | Yes, re-encrypt |
| Ed25519 signature | Broken | No, the claim was about the past |
You can re-encrypt data. You cannot re-sign history. A 2026 certificate re-signed in 2040 proves something about 2040.
Why this bites evidence specifically
A certificate exists to be checked later, often much later, by someone with no relationship to its issuer, in a dispute nobody anticipated. That is the entire value proposition.
Once the signature scheme is broken, two things happen at once, and the second is worse. The certificate can no longer be relied upon as genuine. And it can no longer be relied upon as not genuine either, because anyone can now forge one that looks identical. The whole class of document stops carrying information, retroactively, including every honestly issued instance.
For a seven-year financial obligation this is probably manageable. For medical records, long-lived regulatory archives, or anything where a claim must survive into the 2040s, the decision has to be made at issuing time.
What we actually did
The public CLI ships dual-signing: SLH-DSA, the stateless hash-based scheme standardised as FIPS-205, alongside Ed25519, exposed as at1 century pq-migrate. A verifier can rely on either, so a migrated certificate stays checkable by conventional tooling today and remains meaningful if the elliptic-curve half falls.
The implementation is validated byte-exact against the NIST ACVP known-answer vectors for FIPS-205, which matters more than it sounds: hash-based signature schemes have a great deal of internal structure, and an implementation can be subtly wrong in ways that still produce self-consistent signatures. Checking against the standard body’s own vectors is the only way to know you implemented the standard rather than something adjacent to it.
The envelope also refuses to downgrade, an attacker cannot strip the stronger signature and present the result as validly single-signed, which is the obvious attack on any dual-signing scheme and the one that makes such schemes worthless if they get it wrong.
A correction we owe this article
Two earlier pieces stated that hash-based certificate signing was on our roadmap and not done. Finding an implementation in the codebase, we corrected them to say it shipped. Then we installed the released binary and ran it, and discovered the first correction was also wrong: the capability ships, and it does not reach erasure certificates.
Three positions in one day, two of them wrong, and the sequence has a clear moral. The first claim came from memory. The second came from reading source code. Only the third came from running the artefact a customer would actually install, and only the third was right. The rule we already apply to benchmark numbers, re-run it rather than remember it, turns out to govern claims about our own product too, and reading your own code is not a substitute for running your own release. The fourth position, which is the one above, is that we fixed it.
What to ask any vendor
- What signs your certificates and attestations today?
- If that scheme is broken in 2035, what happens to certificates issued in 2026?
- Is there a post-quantum option, is it on by default, and if not, why not?
- Is the implementation validated against the standard’s published test vectors?
Most vendors in this category have not been asked any of these. The answers, and the speed with which they arrive, tell you a good deal about whether the product was designed for the length of obligation you are about to place on it.
Questions people ask about this
Will quantum computers break my encrypted archive?
Symmetric encryption holds up well. Grover's algorithm effectively halves the key strength, so AES-256 retains about 128 bits of security, which is not practically attackable. The exposed component is asymmetric cryptography, the signatures used for attestation, which Shor's algorithm breaks outright.
Why do signatures matter more than encryption here?
Because of when they are checked. Encryption protects data now; you can re-encrypt later if the algorithm weakens. A signature is a claim about the past that must still verify in ten or fifteen years, and you cannot retroactively re-sign a certificate that was meant to prove what someone asserted in 2026.
What is SLH-DSA and why use it?
SLH-DSA is the stateless hash-based signature scheme standardised as NIST FIPS-205. Its security rests only on the underlying hash function rather than on factoring or discrete logarithms, so Shor's algorithm does not apply. Signatures are large, kilobytes rather than 64 bytes, which is an acceptable cost on a certificate and a poor one on high-volume traffic.
Do I need this now, or is it a future problem?
It depends entirely on your retention horizon. For a two-year record it is not urgent. For evidence that must be checkable in 2040, the decision has to be made at issuing time, because you cannot go back and re-sign a fifteen-year-old certificate without undermining exactly what makes it evidence.