Planning the post-quantum migration for long-lived signatures
The urgency for encryption is clear, because encrypted traffic captured today can be decrypted later. Signatures have a different profile, and that difference should shape how fast you move.
How urgent is post-quantum migration for signatures?
Less urgent than for encryption, and not zero. Encrypted traffic captured today can be decrypted later, which sets a hard deadline. A forged signature is only useful when presented, so the deadline is set by how long a record must remain verifiable — which for some records is decades.
- Signatures face no harvest-now-attack-later risk; forging requires a capable machine at the time the forgery is useful.
- The exposure is for records whose verification matters past the point such a machine might exist — which is a long retention question.
- A hybrid receipt carrying both a classical and a post-quantum signature is the transition path, at a real cost in size.
Part of Receipt cryptography and standards
Why signatures are not encryption
| Property | Encryption | Signatures |
|---|---|---|
| Harvest now, attack later | Yes — captured ciphertext can be decrypted decades on | No — a forged signature is only useful when presented |
| Value of a past compromise | Full — the plaintext is revealed | Limited — forging an old signature persuades nobody if records exist elsewhere |
| Urgency driver | Confidentiality lifetime of the data | Verification lifetime of the record |
| Migration difficulty | Protocol negotiation | Format change plus verifier updates |
The first row is the whole difference in urgency. Encryption has a deadline set by when data was captured; signatures have one set by when verification still matters.
Who actually has exposure
Not everyone, and the honest answer for many systems is that this is not pressing.
- Session tokens and short-lived assertions: essentially no exposure. They expire in minutes.
- Ordinary audit records with a seven-year retention: low, and worth planning for rather than rushing.
- Records that must verify for decades — property, pensions, long-dated contracts: genuine exposure.
- Root trust anchors and code signing roots: highest, because they have very long lives and high value.
An organisation should locate itself on that list before deciding how fast to move. Treating a session token system as urgently exposed wastes effort that the third and fourth categories need.
The hybrid approach
Carry both signatures. Verification succeeds only if both verify, so the record is at least as strong as the stronger of the two.
{
"statement": { ... },
"signatures": [
{ "alg": "Ed25519", "kid": "2026-03-b", "sig": "..." },
{ "alg": "ML-DSA-65", "kid": "2026-03-b-pq", "sig": "..." }
]
}
# Verifier policy:
# transition period → require classical, accept PQ if present
# hybrid period → require both
# post-transition → require PQ, classical optionalThe three policies correspond to three phases, and the middle one is where you want to be for a long time.
The size cost, plainly
| Scheme | Approximate signature size | Approximate public key size |
|---|---|---|
| Ed25519 | 64 bytes | 32 bytes |
| ML-DSA-44 | ~2.4 KB | ~1.3 KB |
| ML-DSA-65 | ~3.3 KB | ~2.0 KB |
| Hybrid (Ed25519 + ML-DSA-65) | ~3.4 KB | ~2.0 KB |
That is roughly fifty times larger. For a receipt stored once per consequential action it is irrelevant — a million receipts is a few gigabytes. For a token sent on every request it is not.
This is another reason the exposure analysis matters: the things with the most exposure are the things where size matters least.
What to do now
- Make the format agile. A signatures array rather than a single signature field. This costs nothing today and is the change that is painful to retrofit.
- Record the algorithm explicitly per signature, and have verifiers select by policy rather than by what the record asserts.
- Classify your records by how long verification must remain possible. This is the analysis that determines urgency.
- Pilot on the longest-lived category rather than everywhere. It is where the value is and where size does not bite.
- Track standards maturity and library availability rather than committing early to a specific parameter set.
Point one is the recommendation that survives any outcome. A format that can carry two signatures can carry whichever two turn out to be right.
A note on timelines
Estimates for when a cryptographically relevant quantum computer might exist vary by decades and come from parties with different incentives. Any plan that depends on a specific date is built on a number nobody can defend.
Plan for agility rather than for a date. An organisation that can add a signature algorithm without a format change is prepared regardless of when, or whether, the timeline estimates converge.
Who actually has exposure
| Record | Exposure |
|---|---|
| Session tokens | Essentially none — they expire in minutes |
| Seven-year audit records | Low; worth planning |
| Property, pensions, long-dated contracts | Genuine |
| Root trust anchors and code signing roots | Highest |
An organisation should locate itself on that table before deciding how fast to move. Treating a session-token system as urgently exposed wastes effort the bottom two rows need.
Objections and honest limits
“The size cost makes this impractical.” Roughly fifty times larger signatures. Irrelevant for a receipt stored once per consequential action — a million receipts is a few gigabytes. Significant for a token on every request, which is also the case with no exposure.
“We should wait for the timelines to firm up.” Estimates vary by decades and come from parties with different incentives. Plan for agility rather than a date: a format carrying an array of signatures is prepared regardless.
What to do now
- Make the format carry an array of signatures. Costs nothing today; painful to retrofit.
- Record the algorithm per signature. And have verifiers select by policy, not by what the record asserts.
- Classify records by verification lifetime. That analysis determines urgency, not the headlines.
- Pilot on the longest-lived category. Where the value is and where size does not bite.
Terms used here
- Harvest now, decrypt later
- Capturing encrypted traffic today to break it when capability exists — the driver for encryption urgency, and absent for signatures.
- Hybrid signature
- Carrying both a classical and a post-quantum signature, where verification requires both.
- Verification lifetime
- How long a record must remain checkable — the variable that sets signature urgency.
Frequently asked questions
Is the urgency the same as for encryption? No. Encrypted traffic captured today can be decrypted later. A forged signature is only useful when presented, so the deadline is set by verification lifetime.
Who has real exposure? Records that must verify for decades — property, pensions, long-dated contracts — and root trust anchors. Session tokens have essentially none.
What is the size cost? Roughly fifty times larger signatures. Irrelevant for receipts stored per consequential action; significant for tokens sent on every request.
What should be done today? Make the format carry an array of signatures rather than one. That costs nothing now and is the change that is painful to retrofit.
Is signature migration as urgent as encryption? No. A forged signature is only useful when presented, so there is no harvest-now risk. Urgency follows verification lifetime.
Where this fits in Manav
Manav's receipt is deliberately small: RFC 8785 canonicalisation, one algorithm, keys at a well-known URL, and a verifier short enough to audit or reimplement.