{
 "slug": "post-quantum-cryptography-pqc-roadmap-migrating-ed25519",
 "topic_id": "TOPIC-094",
 "cluster": "Cryptography & Standards",
 "tier": "Tier B",
 "title": "Planning the post-quantum migration for long-lived signatures",
 "summary": "Signatures differ from encryption in their quantum exposure: there is no harvest-now-decrypt-later risk, but records that must verify decades out need a plan.",
 "lede": "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.",
 "date": "2024-10-27",
 "category": "Compliance",
 "author_id": "august-moravec-diallo",
 "tags": [
  "post-quantum",
  "ML-DSA",
  "Ed25519",
  "migration",
  "cryptographic agility",
  "standards"
 ],
 "image_title": "Post Quantum Migration Signatures",
 "schema": "Article",
 "key_takeaways": [
  "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."
 ],
 "body": [
  {
   "type": "h2",
   "text": "Why signatures are not encryption"
  },
  {
   "type": "diagram",
   "kind": "compare",
   "alt": "Two different urgency drivers",
   "caption": [],
   "nodes": "Harvest-now-decrypt-later does not apply to signatures, and that changes the plan.",
   "left": {
    "title": "Encryption",
    "items": [
     "Captured now, broken later",
     "Deadline set by capture date",
     "Applies to all confidential traffic",
     "Urgent"
    ]
   },
   "right": {
    "title": "Signatures",
    "items": [
     "Forgery useful only when presented",
     "Deadline set by verification lifetime",
     "Applies to long-lived records",
     "Plan, do not rush"
    ]
   }
  },
  {
   "type": "table",
   "head": [
    "Property",
    "Encryption",
    "Signatures"
   ],
   "rows": [
    [
     "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"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Who actually has exposure"
  },
  {
   "type": "p",
   "html": "Not everyone, and the honest answer for many systems is that this is not pressing."
  },
  {
   "type": "ul",
   "items": [
    "<strong style=\"font-weight:600\">Session tokens and short-lived assertions:</strong> essentially no exposure. They expire in minutes.",
    "<strong style=\"font-weight:600\">Ordinary audit records with a seven-year retention:</strong> low, and worth planning for rather than rushing.",
    "<strong style=\"font-weight:600\">Records that must verify for decades — property, pensions, long-dated contracts:</strong> genuine exposure.",
    "<strong style=\"font-weight:600\">Root trust anchors and code signing roots:</strong> highest, because they have very long lives and high value."
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "The hybrid approach"
  },
  {
   "type": "p",
   "html": "Carry both signatures. Verification succeeds only if both verify, so the record is at least as strong as the stronger of the two."
  },
  {
   "type": "code",
   "text": "{\n  \"statement\": { ... },\n  \"signatures\": [\n    { \"alg\": \"Ed25519\", \"kid\": \"2026-03-b\", \"sig\": \"...\" },\n    { \"alg\": \"ML-DSA-65\", \"kid\": \"2026-03-b-pq\", \"sig\": \"...\" }\n  ]\n}\n\n# Verifier policy:\n#   transition period  → require classical, accept PQ if present\n#   hybrid period      → require both\n#   post-transition    → require PQ, classical optional"
  },
  {
   "type": "p",
   "html": "The three policies correspond to three phases, and the middle one is where you want to be for a long time."
  },
  {
   "type": "h2",
   "text": "The size cost, plainly"
  },
  {
   "type": "table",
   "head": [
    "Scheme",
    "Approximate signature size",
    "Approximate public key size"
   ],
   "rows": [
    [
     "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"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "This is another reason the exposure analysis matters: the things with the most exposure are the things where size matters least."
  },
  {
   "type": "h2",
   "text": "What to do now"
  },
  {
   "type": "ol",
   "items": [
    "<strong style=\"font-weight:600\">Make the format agile.</strong> A signatures array rather than a single signature field. This costs nothing today and is the change that is painful to retrofit.",
    "<strong style=\"font-weight:600\">Record the algorithm explicitly</strong> per signature, and have verifiers select by policy rather than by what the record asserts.",
    "<strong style=\"font-weight:600\">Classify your records</strong> by how long verification must remain possible. This is the analysis that determines urgency.",
    "<strong style=\"font-weight:600\">Pilot on the longest-lived category</strong> rather than everywhere. It is where the value is and where size does not bite.",
    "<strong style=\"font-weight:600\">Track standards maturity</strong> and library availability rather than committing early to a specific parameter set."
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "A note on timelines"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Who actually has exposure"
  },
  {
   "type": "table",
   "caption": "By record type",
   "head": [
    "Record",
    "Exposure"
   ],
   "rows": [
    [
     "Session tokens",
     "Essentially none — they expire in minutes"
    ],
    [
     "Seven-year audit records",
     "Low; worth planning"
    ],
    [
     "<strong style=\"font-weight:600\">Property, pensions, long-dated contracts</strong>",
     "<strong style=\"font-weight:600\">Genuine</strong>"
    ],
    [
     "<strong style=\"font-weight:600\">Root trust anchors and code signing roots</strong>",
     "<strong style=\"font-weight:600\">Highest</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“The size cost makes this impractical.”</strong> 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."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“We should wait for the timelines to firm up.”</strong> 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."
  }
 ],
 "faq": [
  {
   "q": "Is the urgency the same as for encryption?",
   "a": "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."
  },
  {
   "q": "Who has real exposure?",
   "a": "Records that must verify for decades — property, pensions, long-dated contracts — and root trust anchors. Session tokens have essentially none."
  },
  {
   "q": "What is the size cost?",
   "a": "Roughly fifty times larger signatures. Irrelevant for receipts stored per consequential action; significant for tokens sent on every request."
  },
  {
   "q": "What should be done today?",
   "a": "Make the format carry an array of signatures rather than one. That costs nothing now and is the change that is painful to retrofit."
  },
  {
   "q": "Is signature migration as urgent as encryption?",
   "a": "No. A forged signature is only useful when presented, so there is no harvest-now risk. Urgency follows verification lifetime."
  }
 ],
 "sources": [
  {
   "t": "NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard",
   "u": "https://csrc.nist.gov/pubs/fips/204/final"
  },
  {
   "t": "RFC 8032 — Edwards-curve Digital Signature Algorithm (EdDSA)",
   "u": "https://www.rfc-editor.org/rfc/rfc8032"
  },
  {
   "t": "CISA — known exploited vulnerabilities and incident reporting",
   "u": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
  },
  {
   "t": "NIST — post-quantum cryptography project",
   "u": "https://csrc.nist.gov/projects/post-quantum-cryptography"
  }
 ],
 "related": [
  {
   "slug": "cryptographic-receipt-primitive-rfc8785-ed25519-vs-jwt",
   "title": "A session token is not an audit record",
   "category": "Compliance"
  },
  {
   "slug": "fail-closed-cryptographic-key-management-implementing-dual-key",
   "title": "Rotating signing keys without breaking verification",
   "category": "Compliance"
  },
  {
   "slug": "building-manav-verify-write-open-source-offline-verifier",
   "title": "Writing an offline verifier with no dependencies",
   "category": "Compliance"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Post%20Quantum%20Migration%20Signatures/1200_630/blog.jpg",
 "wordcount": 888,
 "url": "/blog/post-quantum-cryptography-pqc-roadmap-migrating-ed25519.html",
 "reading_time": "4 min read",
 "hub": {
  "slug": "topics/receipt-cryptography",
  "title": "Receipt cryptography and standards"
 },
 "answer": "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.",
 "answer_q": "How urgent is post-quantum migration for signatures?",
 "glossary": [
  {
   "term": "Harvest now, decrypt later",
   "def": "Capturing encrypted traffic today to break it when capability exists — the driver for encryption urgency, and absent for signatures."
  },
  {
   "term": "Hybrid signature",
   "def": "Carrying both a classical and a post-quantum signature, where verification requires both."
  },
  {
   "term": "Verification lifetime",
   "def": "How long a record must remain checkable — the variable that sets signature urgency."
  }
 ],
 "checklist": {
  "title": "What to do now",
  "id": "pqc",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Make the format carry an array of signatures.",
    "text": "Costs nothing today; painful to retrofit."
   },
   {
    "name": "Record the algorithm per signature.",
    "text": "And have verifiers select by policy, not by what the record asserts."
   },
   {
    "name": "Classify records by verification lifetime.",
    "text": "That analysis determines urgency, not the headlines."
   },
   {
    "name": "Pilot on the longest-lived category.",
    "text": "Where the value is and where size does not bite."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "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.",
  "href": "../architecture.html",
  "label": "Read the architecture"
 }
}