Harvest now, forge later: why every receipt carries ML-DSA-65

Some records matter for minutes. Others need to stand up for years: contracts, authorisations, regulatory evidence, and receipts for consequential actions taken by AI agents. For that second kind, "is this signature secure today?" is necessary but not enough. The question is whether it will still mean something when someone finally needs to rely on it.

That is why every R-Series receipt carries two signatures, Ed25519 and ML-DSA-65. This post explains the threat behind that decision, and what it does and does not change.

Harvest now, decrypt later

The phrase comes from encryption. An adversary records encrypted traffic today, stores it, and waits. Nothing can be read yet. But if a cryptographically relevant quantum computer arrives, the stored traffic can be decrypted after the fact.

The reason is Shor's algorithm. On a large enough quantum computer it solves integer factorisation and discrete logarithms efficiently. Those two problems underpin almost all of today's public-key cryptography:

RSA rests on factorisation.
ECDSA and Ed25519 rest on the elliptic-curve discrete logarithm.
X25519 and other Diffie-Hellman key exchanges rest on the same family of problems.

For confidentiality, the damage is retrospective. Anything protected only by RSA or X25519 key exchange and captured today could be read once the capability exists. This is why NIST standardised ML-KEM in FIPS 203 for key establishment, and why the IETF has standardised hybrid ML-KEM key exchange for TLS 1.3 (RFC 10024).

The signature version: harvest now, forge later

Signatures face a different problem, and for evidence it is the one that matters.

A signature does not hide anything. It proves who signed and that nothing has changed. If an attacker can derive a private key from its public key, which Shor's algorithm allows for RSA, ECDSA and Ed25519, they can produce new signatures that verify perfectly under that key.

For a live system, you rotate keys and move on. For an archive, the problem is worse. A forger with a recovered key can produce a receipt that looks as if it was signed years ago, for an action that never happened, and it would verify. Or they can alter a genuine record and re-sign it. The moment that becomes possible, every archive protected only by classical signatures loses its value as evidence, including records signed long before the attack.

Public keys are, by design, public. They can be collected today. That is the harvest.

Nobody knows when

No responsible team can give a reliable date for a cryptographically relevant quantum computer. Serious engineering barriers remain and estimates vary widely. Archive design does not need a prediction, though. It needs a decision about whether evidence meant to last should depend on a single classical assumption.

What a hybrid signature changes

NIST standardised ML-DSA, a module-lattice signature scheme, in FIPS 204. Its security rests on a different mathematical family from elliptic curves, one that Shor's algorithm does not address.

R-Series signs every receipt with both Ed25519 and ML-DSA-65, and the verifier requires both to pass. That gives two properties:

Forging a receipt means breaking both. Recovering an Ed25519 key with a future quantum computer is not enough on its own.
The classical leg still counts. ML-DSA is young compared with elliptic-curve cryptography. If an unexpected weakness is found in it, Ed25519 still stands.

A stronger defence profile using ML-DSA-87 is in development.

The costs

Hybrid signing is not free. An Ed25519 signature is 64 bytes; an ML-DSA-65 signature is 3,309 bytes. Receipts are larger, storage and bandwidth rise, and verification has more steps. Lattice libraries and tooling are less mature. For short-lived, low-value records that trade may not be worth it. For long-lived evidence of consequential actions, we think it is.

What it does not solve

Two algorithms do not make a system secure by themselves. Security also depends on canonicalisation, key management, downgrade resistance and implementation quality. A durable signature cannot show that a signed statement was true, and it cannot protect a key that was stolen or mishandled. Nothing here is a guarantee against future cryptanalysis.

What it does is narrower: it reduces the chance that the long-term value of an agent's record depends on one family of mathematics.

You can check both signatures on a receipt yourself with the in-browser verifier, and read the full sequence of checks on how proof works.