Please Mind the Gap, Part 1: Notes from a PQC Migration Talk

In September 2026 I attended a talk by Fraunhofer Singapore titled Please Mind the Gap: From Migration Models to Operational Reality, given by Prof. Daniel Loebenberger and Prof. Marc Stöttinger under the QUASAR-CREATE programme. The thesis: there is a real gap between how post-quantum cryptography (PQC) migration is modelled and how organizations actually operate, and that gap deserves attention.

What follows are my notes on the talk, with the key figures redrawn from the slides and what the underlying papers add, and a conversation afterwards about Bitcoin. Part 2 looks at what all of it means for CKB.

The talk in one line: PQC migration is no longer hard because of algorithms. It is hard because of system architecture and organizational operations.

1. Background

The talk came out of QUASAR-CREATE, a Singapore–Germany research programme on quantum-safe migration and crypto-agility, and opened with a live session in the browser-based circuit simulator Quirk to give the audience the basics of qubit states, the Bloch sphere and measurement.

2. How far away is a cryptographically relevant quantum computer?

The speakers used Samuel Jaques’s Landscape of Quantum Computing in 2026: physical qubits on the x-axis (10^0 to 10^9), error rate on the y-axis (10^-1 to 10^-6).

• Today’s machines (Quantinuum, IonQ, Google, IBM, QuEra, Atom + Microsoft, KunLun and others) cluster around 10^2 qubits with error rates of 10^-2 to 10^-3, the corner marked “We are here”. Per Jaques’s page, the most advanced device is still about 9,500 times short of breaking RSA-2048: surface codes need about one million physical qubits, some 13.2 doublings away even at sustained exponential growth.
• Newer high-rate qLDPC codes such as bicycle codes, the “with special codes” annotations, lower that bar considerably. Jaques discounts them: they need long-range connectivity between qubits that experiments have not shown at scale, and his chart counts only what has been demonstrated.
• My reading: the gap is still two to four orders of magnitude, but the bar keeps falling and migration takes years, so it cannot wait for the hardware.

Two claims about timing

The speakers made two pointed claims:

1. There is a high probability that someone will secretly have a useful quantum computer around 2030. The emphasis is on secretly: public progress charts only count published, demonstrated devices. Real capability may be ahead of them.
2. Store now, decrypt later is already happening. They asserted that intelligence agencies are already archiving intercepted traffic to decrypt it later.

How I weigh them:

• Claim 1 roughly matches official planning assumptions. Chapter 5 of the MAgiCS 2026 proceedings cites Germany’s BSI working assumption for high-security domains: a cryptographically relevant quantum computer is likely in the early 2030s. Mosca puts the probability of one appearing by 2031 at about one in two.
• Claim 1 is in tension with Jaques’s chart, which counts only demonstrated capability and arrives at a 9,500× gap. The speakers stress exactly the part that is not public. Neither can falsify the other, which is why planning should treat the timeline as uncertain.
• Claim 2 is an assertion. There is no public evidence of what any agency has archived or intends to do with it. But harvest-now-decrypt-later is the mainstream threat model; the NIST IR 8547 draft and the workshop poster both take it as a premise.
• Mosca’s inequality ties the two together: if the secrecy lifetime X of some data plus the migration time Y exceeds the time Z until a capable quantum computer, data transmitted today is already exposed. On the speakers’ view Z is about four years. Anything that must stay confidential past 2030 and takes years to migrate is at risk now.
• Store-now-decrypt-later threatens confidentiality first. What gets intercepted is key exchange and encrypted traffic, so key exchange should move to ML-KEM or a hybrid KEM first. Signatures generally cannot be forged after the fact and can follow later, with the exception of long-lived roots of trust and firmware verification keys.

3. Scaling migration and verification

Migration has to move from individual algorithms to increasingly complex systems and infrastructure, but the higher the level, the less complete our knowledge of how cryptography is used and what depends on it.

• Migration: from a single algorithm to complex systems and infrastructure.
• Information: the further up, the less complete the picture of usage and dependencies.
• Verification: automated discovery and checking to recover evidence and assess whether each migration step preserves both security and function.

4. Algorithm efficiency (supercop)

The speakers plotted supercop benchmarks on a log-log chart of size against CPU cycles. Conclusion: for most PQC schemes, speed is not the problem. Size is.

• ML-KEM (kyber1024) at about 10^4.8 cycles is in the same order as a classical RSA-2048 KEM (about 10^4.2), with a public key roughly an order of magnitude larger.
• ML-DSA (dilithium5) and Falcon-512 at about 10^5.5 to 10^5.9 cycles are faster than RSA-2048 signing (about 10^6.4).
• SLH-DSA (sphincsf256shake256simple) is the slowest at about 10^8.6 cycles. Classic McEliece (mceliece8192128f) has a public key around 10^6 bytes.
• BIKE-L3 and HQC-256 sit in between; HQC at about 10^6.1 cycles.

One thing stands out when checking the positions against published parameter sizes. The KEM points sit at their public-key sizes, but the signature-scheme points sit at their signature sizes: Falcon-512 at about 666 B, ML-DSA-87 at about 4.6 KB, SLH-DSA-256f at about 49 KB rather than its 64 B public key. The slide’s axis says public key, so for signatures the chart is really plotting the artifact that travels.

From the papers (chapter 7): tools like supercop average away the variance in ML-DSA signing time as noise, but that variance is an inherent heavy tail of the algorithm. On a Cortex-M33 the worst case is about 20 times the mean. Comparing schemes at different security levels on one chart is also the first benchmarking pitfall that paper lists.

5. System impact: PQ signatures and message length

Plan migration around growth in memory and bandwidth, not only key size and speed.

• Two kinds of cost: artifact size (keys, signatures) is constant; message processing grows with message length |M|. Usually only the first gets planned for.
• RSA and ECC use hash-then-sign, so only a 32-byte digest enters the cryptographic module. PQ signatures (ML-DSA, SLH-DSA, XMSS, LMS) sign the whole message, so the bytes transferred grow with |M|.
• High-risk settings: signing on a remote cryptographic module such as an HSM; verifying on a memory-constrained device.
• Streaming: the verifier needs the public key first (XMSS and LMS also need the signature first) before it can process the message. SLH-DSA signing reads the message twice, and verification needs the public key and the R value from the signature up front.
• Worked example, a 1 MB message moving from RSA-3072 to SLH-DSA-128f: artifact size ×22; data sent into the cryptographic module ×31,250 (1 MB ÷ 32 B).

From the papers (chapter 6): all of this has mitigations, each with a price. Pre-hash variants fall back to hash-then-sign security assumptions. ML-DSA’s external-μ keeps the security argument but does not solve streaming verification. X.509 does not allow pre-hashed ML-DSA, only composite signatures. The PKCS#11 v3.2 draft supports neither external-μ nor segmented XMSS/LMS signing.

6. Measuring crypto-agility at the application layer

Applications should express cryptographic intent; the choice of algorithm and provider belongs behind a controlled interface. Agility is not a single maturity level but two tiers with seven orthogonal components, each scored 0 to 4.

Component	Low to high	Best of 6 evaluated systems	PQC-ready
C1 Operation	algorithm-specific calls → fully agile	4	≥3 (consistent parameter ranges)
C2 Key generation	explicit parameters → intent or purpose	1	≥2 (intent-based generation)
C3 Provider	explicit import → provider-agnostic	3
C4 Mechanism (governs C1–C3)	hard-coded → configuration → policy engine	1	≥3 (policy engine)
C5 Authority	developer → role-based → federated	2
E1 Algorithm migration	no versioning → TransformKey → automatic	2	≥3
E2 Provider migration	bound to provider → automatic routing	1

The paper confirms that none of the six systems (PKCS#11, OpenSSL 3.0, JCA, Tink, AWS KMS, Vault Transit) reaches C2.2, C4.3 or E1.3. The “best of 6” column stitches together per-component maxima; it does not describe any one system. Both tiers are required: decoupling without enablers is latent capability, enablers without decoupling is ecosystem lock-in.

What the enablers mean

Decoupling asks “can the code switch”. Enablers ask “when you actually switch, can the existing keys come along”. The paper defines E1 as replacing the algorithm without changing application code, and E2 as moving keys and operations to another provider without changing application code.

Level	E1 Algorithm migration	E2 Provider migration
0	No versioning: a new algorithm means a new key and a manual update of every reference. PKCS#11, OpenSSL 3.0, JCA	The key is bound forever to the provider that created it; an HSM key cannot move to a cloud KMS. OpenSSL 3.0, JCA, Tink
1	Same-algorithm rotation: new key material under the same key ID, but the algorithm cannot change. AWS KMS, Vault Transit	Manual export and import by an administrator (wrap/unwrap). PKCS#11, AWS KMS, Vault Transit
2	Multiple algorithm versions under one key identity, for example an ECDSA version and an ML-DSA-65 version; new operations use the latest, old versions still verify or decrypt. Google Tink	A dedicated MigrateKey operation that moves, rewraps and updates metadata in one step
3	An access-controlled TransformKey operation that converts a key’s algorithm to a new one. This is the PQC-ready bar	Organizational policy triggers automatic migration, for example moving all software keys into an HSM when compliance requirements change
4	Policy monitoring triggers algorithm conversion automatically	Dynamic provider selection by latency, availability or cost

The paper stresses the difference between E1.1 and E1.3: same-algorithm rotation can never turn an RSA-2048 key into an ML-DSA-65 key. Cross-algorithm migration needs E1.3. E2 is also not “higher is better”: HSM keys are non-exportable by design, and the right level depends on the security model. The provider mechanisms in OpenSSL 3 and JCA count as C3 (provider decoupling), not E2; both score 0 on E2.

Two failure modes make the tiers concrete. An application that only calls sign(purpose = document) with the algorithm chosen by policy is fully decoupled, yet tens of thousands of RSA keys in the HSM have no version field and cannot be transformed. That is latent capability. Conversely, a vendor platform may support automatic migration while the application hard-codes that vendor’s RSA calls, so switching only works inside that vendor’s ecosystem. That is lock-in.

7. Five dimensions of operational readiness

The speakers grouped the recurring “operational gaps” into five dimensions drawn from the literature, and mapped each anti-pattern from the next section onto them.

• I, Information sufficiency: do we know what to change and why?
• C, Technical controllability: can the affected components actually be changed?
• V, Verification capability: can the target cryptographic state be verified?
• E, Ecosystem coordination: can external dependencies be coordinated?
• R, Resource readiness: are there enough people and skills?

8. Seven anti-patterns and their no-regret moves

The speakers called the planning principles classic “no-regret moves”: whenever the quantum computer arrives, doing these now will not be regretted.

Anti-pattern	Planning principle
Bob Knows	Make knowledge explicit, reviewable and transferable, attached to roles rather than people
The Spreadsheet of Doom	Keep an evidence-backed inventory, reconciled against runtime observation
The Ghost in the Basement	Chase down unexplained traffic, unmanaged certificates and systems nobody owns
The Last Windows XP Machine	Decide early whether to replace, isolate, retire or accept the risk
The Vendor Will Surely Fix It	Distinguish shipped releases, binding commitments and roadmaps
The Friday Night Migration	Plan runnable intermediate states, rollback, staffing and realistic change windows
The Algorithm Nobody Used	Define cryptographic acceptance criteria and evidence before deployment

Source: Loebenberger and Stöttinger, Please Mind the Gap, manuscript, 2026 (not yet published).

9. After the talk: why is Bitcoin hard to migrate?

I asked one of the speakers afterwards. Two points:

1. Protocol layer. Bitcoin is tightly bound to specific cryptography, ECDSA and Schnorr over secp256k1, and there is no consensus yet on how to upgrade the protocol. ECC is among the easiest targets for a quantum computer, so time is short.
2. Even once the protocol question is settled, the hardest part will be policy.

Why policy is the hard part, in my words:

• Protocol answers “can we switch”. Policy answers “who decides, when, and what happens to coins that never move”. Bitcoin has no authority that can make those decisions. The talk’s point about architecture was that where you cut depends on who can coordinate: a 5G operator has its certificate authorities, the EVM design the talk presented has on-chain validator votes, Bitcoin has neither.
• There is no good answer for unmigrated coins. Coins whose public keys are already on chain (early P2PK outputs, reused addresses) are exposed first, and many owners are gone or have lost their keys. Freezing them violates “your keys, your coins” and immutability. Not freezing them means whoever gets a quantum computer first can drain and dump them, hurting every holder. Both paths are irreversible and both hurt someone.
• Who sets the deadline? Too early and many users cannot make it; too late and the chain may already be broken. No centre can announce a date and own the consequences. Past soft forks such as Taproot took years from idea to activation.
• Block space and fees are economic policy. PQ signatures are tens to hundreds of times larger than a 64 B Schnorr signature (ML-DSA-44 about 2.4 KB, SLH-DSA-128s about 7.8 KB). Whether to give them a witness discount or raise capacity reopens the block size war, and a network-wide migration itself consumes a lot of block space.
• User behaviour cannot be forced. Every holder has to move their own coins, and hardware wallets, multisig, Lightning, exchanges and custodians all need support one by one.

Against the five readiness dimensions:

Dimension	Bitcoin
I Information	Good on chain: P2PK outputs, addresses that have been spent from or reused, and Taproot outputs, whose output key sits in the UTXO itself, can all be counted. Unknown: which of those owners are still around
C Controllability	The bottleneck. Post-quantum signature verification needs a soft fork with no agreed design yet. BIP-360, the draft furthest along, adds an output type without Taproot’s key path and leaves post-quantum signatures to a later proposal. Until those land, holders can keep public keys off chain until they spend, which limits long exposure but not an attack during the spend itself or a key leaked some other way
V Verification	Consensus changes need long audits and new signature implementations even longer ones. The end state, coins moved off exposed outputs, is verifiable on chain but unreachable before the protocol changes
E Ecosystem	Two rounds of coordination with no authority to run either: activating the fork needs miners, nodes and the economic majority; then wallets, exchanges, custodians and Lightning must ship support; then every holder must move. The speaker’s policy layer lives here
R Resources	Mixed. There is no shortage of developers or funding around Bitcoin, but the pool of people who can review consensus-critical cryptography is small, and every wallet, exchange and custodian needs its own engineering capacity to ship and test support

The weight across the five is uneven. For Bitcoin, controllability at the protocol layer dominates: inventory, research and wallet work can start now, but no coin can move behind a post-quantum signature until a fork activates one. That is the opposite of CKB’s profile in Part 2, where the protocol layer is already quantum-safe and the weight sits on the ecosystem.

The proposals under discussion split along the same line, and neither is yet a complete answer. BIP-360, in its current draft P2MR (pay to Merkle root), is a Taproot-like output type with the key path removed: it resists long-exposure attacks on public keys sitting on chain, and leaves short-exposure attacks and post-quantum signatures to a separate proposal. Lopp’s legacy signature sunset draft BIP-361 is the policy layer, and it requires a post-quantum signature BIP that does not exist yet.

Chapter 10 of the MAgiCS 2026 proceedings describes the version of BIP-361 it discusses: Phase A, three years after BIP-360 activation, forbids sending to P2PK and P2PKH, so new UTXOs must use a quantum-resistant format; Phase B, after a fixed deadline, invalidates spends from legacy addresses, freezing unmigrated funds. The current draft differs. Phase A starts about 160,000 blocks, roughly three years, after BIP-361’s own activation. Phase B, two years later, tightens verification of ECDSA and Schnorr spends in a way meant to rule out quantum attackers while still admitting authentic holders, a quantum-safe rescue rather than a bare freeze; how that rescue works and which coins it could cover are still open. The paper says the proposal is contested in the community and notes its heavy reliance on the BIP-32 wallet standard; paper wallets and other non-conforming wallets would break.

The same paper takes the opposite stance: a user who returns after a while should not find their funds unusable because they missed a window. Those two positions are the two ends of the policy dilemma. A survey it cites found that 58.8% of more than 14,000 blockchain users rated post-quantum security “not important” when choosing a chain, which suggests voluntary migration will be slow. It also points out that PoW and PoS differ fundamentally, so its validator key rotation mechanism does not transfer to Bitcoin.

Recent reporting puts the BTC held in outputs with exposed public keys at around 7 million coins. I have not verified that number against a primary source.

Note: Bitcoin developers usually use “policy” for node relay rules (standardness). Here it means governance and decision-making.

10. Key takeaways

• Algorithms are ready; the bottleneck has moved to bytes. ML-KEM and ML-DSA are as fast as RSA, but larger keys and signatures make memory, bandwidth, certificate size and block size the new constraints.
• Plan for costs that grow with the message. Artifacts grow 22×; data into the cryptographic module grows 31,250×. HSMs and embedded devices feel it first.
• Crypto-agility can be measured. Seven orthogonal components with explicit PQC-ready thresholds turn “agile” from a slogan into a score. Current systems fall short mostly on key generation, policy mechanism and algorithm migration.
• Governance decides where to cut. The talk showed two options: with a central operator, externalize policy; without an authority, carry the algorithm identifier with the data.
• The biggest gap is organizational. Knowledge only in someone’s head, inventories that do not match reality, reliance on vendor roadmaps, rushed weekend changes: none of this is about quantum, yet it decides whether migration succeeds.
• Verification runs through the whole thing. Every step needs evidence that security and function are both preserved, with acceptance criteria defined before deployment.

Sources

• QUASAR-CREATE: the research programme behind the talk
• Quirk by Craig Gidney: the circuit simulator used in the opening demo
• Sam Jaques, Landscape of Quantum Computing: the quantum computing landscape chart (CC BY)
• NIST FIPS 204 FAQ, computing μ: ML-DSA external μ
• NIST IR 8547, initial public draft: RSA and ECC deprecation timeline; still a draft as of September 2026
• BIP-360, Pay-to-Merkle-Root (P2MR), Beast, Heilman, Foxen Duke, draft: the output type without Taproot’s key path
• BIP-361, Post Quantum Migration and Legacy Signature Sunset, Lopp et al., draft: the phased sunset of legacy signatures
• Loebenberger and Stöttinger, Please Mind the Gap, manuscript, 2026: cited on the slides, not yet public
• Loebenberger, D., Stöttinger, M. (eds.): Migration and Agility in Cryptographic Systems. MAgiCS 2026, Springer CCIS, open access, doi:10.1007/978-3-032-28946-9. Workshop site with slides: magics-workshop.cs.hs-rm.de. The talk’s P6, P9 and P10 are chapters 6, 9 and 10; the “from the papers” notes and chapter references above refer to this volume.

---

Compiled from my own notes and slide photos, organized with help from Claude.