Quantum risk without the panic — JP Aumasson's post-quantum roadmap.

JP Aumasson co-designed SLH-DSA, BLAKE2/3, and SipHash, and is Chief Security Officer at Taurus, where he has managed quantum risk for bank-grade crypto-asset custody since 2018. His Black Hat Asia briefing is a calm, practitioner-level map of post-quantum migration. (1) A cryptographically relevant quantum computer would break all RSA and elliptic-curve cryptography, which reaches well past TLS into PKI, code signing, DNSSEC, FIDO2, MPC wallets, ZK systems, and PAKEs. (2) Nobody knows when such a machine will exist. His own estimate is no "Q-Day" before 2036. (3) NIST's standards (ML-KEM, ML-DSA, SLH-DSA, with FN-DSA and HQC to follow) are ready, and ML-KEM and ML-DSA run about as fast as the elliptic-curve schemes they replace, but their keys and signatures are an order of magnitude larger. (4) A lot of PQC is already deployable: cloud KMS, iOS 26, Android 17, Cloudflare, Kubernetes via Go 1.24, RHEL 10.1. (5) For an organization this is not a one-off migration. It is a continuous risk-management loop: observe, assess, decide, act.

Post 01 of my Black Hat Asia 2026 series. For the full algorithm-level treatment, see this site's 18-part Post-Quantum Cryptography course. This post stays at the strategic level the talk set.

1. What a quantum computer is (and isn't)

The talk opens by clearing away the two most common misconceptions, since both lead to bad risk decisions:

• Quantum computers are not faster computers. Their advantage has nothing to do with clock speed. A quantum computer doing ordinary arithmetic would be slower and far more expensive than a laptop.
• They do not "try all answers simultaneously." This pop-science description is wrong. A measurement returns one outcome. The advantage comes from algorithms that use interference so that wrong answers cancel and the right structure shows up. That only works for problems with the right mathematical structure.

Very few problems have that structure. The two that matter here are the ones classical public-key cryptography is built on:

• Factoring: given \(n = p \times q\), recover \(p\) and \(q\). This is the hard problem behind RSA.
• Discrete logarithm: given \(x\), \(p\), and \(y = x^d \bmod p\), recover \(d\). This, in its elliptic-curve form, is the hard problem behind ECDH, ECDSA, and Ed25519.

Shor's algorithm solves both in polynomial time on a large enough fault-tolerant quantum computer. That is the whole threat. Symmetric cryptography such as AES and SHA-2/3 is only mildly affected: Grover's algorithm gives at most a quadratic speed-up, which larger key sizes absorb.

2. The blast radius: everything built on RSA or ECC

The talk groups the damage into three buckets. This is the most useful part for anyone scoping a program, because most teams underestimate how far public-key cryptography reaches.

2.1 Signatures and authentication

• PKI: certificates, OCSP responses, Certificate Transparency logs.
• Infrastructure: DNSSEC, BGP route-origin validation (RPKI), EMV payment cards.
• Code signing: OS applications, firmware, APT/RPM packages, dependency signatures.
• Authentication protocols: SSH host keys, FIDO2/passkeys, TLS client certificates.
• Blockchains: transaction signatures.

2.2 Encryption and key agreement

• Key establishment: TLS, SSH, IPsec, WireGuard, messaging protocols.
• Key wrapping: PGP, S/MIME, key-encryption keys, ECIES.
• Confidential data on some privacy-oriented blockchains.

The asymmetry between these two buckets drives prioritization. Encryption is exposed to "store now, decrypt later": an adversary can record encrypted traffic today and decrypt it once a quantum computer exists. Signatures are not exposed that way. A signature forged in 2040 cannot retroactively fool a verifier that ran in 2026. Signature migration only has to finish before a quantum computer exists. Confidentiality migration has to finish before the data you encrypt today stops being sensitive, minus however long an attacker is prepared to wait.

2.3 The less obvious cryptography

The third bucket is where inventories usually miss things:

• Threshold/MPC versions of ECDSA and Ed25519, which crypto custody depends on and which is Aumasson's day job.
• Many zero-knowledge proof systems: ZK rollups, zkVMs, privacy coins built on pairing- or discrete-log-based commitments.
• Most deployed PAKEs (password-authenticated key exchange), including OPAQUE.
• Private set intersection, as used in iCloud.
• Anonymous credentials such as Privacy Pass.

None of these has a drop-in NIST replacement the way TLS key exchange does. They need protocol-level redesign, so they belong early in a roadmap even if their deadline is late.

3. Where quantum hardware actually is

Today's machines have on the order of ~100 good qubits. Aumasson calls them "research prototypes of no practical interest yet." Google Quantum AI and IBM are the most visible players, among many others. Three engineering problems separate these prototypes from a machine that can run Shor at cryptographic scale:

1. Scale: many qubits that are connected and entangled, not just physically present.
2. Coherence and gate count: qubits must hold their state long enough to run the very deep circuits Shor needs.
3. Error rates and error correction: many noisy physical qubits have to be combined into each reliable logical qubit.

3.1 The resource estimates keep falling

The talk covers two recent developments that moved the estimates:

• Google reported a reduced qubit and gate count for breaking cryptography, one that "could execute in minutes using fewer than half a million physical qubits." Unusually, the algorithm itself was not published. The evidence was released as a zero-knowledge proof, so the claim can be checked without the method being disclosed. It builds on an IACR ePrint result (2026/280).
• Oratomic described a neutral-atom architecture that might need even fewer qubits. It is only a theoretical design with no hardware. Aumasson also flags a 2025 neutral-atom experiment with about 6,100 atoms that is sometimes cited as progress: it had no entanglement, 13-second coherence, and no error correction, which he says makes it "not a quantum computer."

3.2 When?

Aumasson's answer is refreshingly direct: nobody knows. It could be 2030, 2060, 2300, or never. His personal view is no Q-Day before 2036. A standard way to turn that uncertainty into a deadline is Mosca's inequality. Let \(X\) be how long your data must stay confidential, \(Y\) how long your migration will take, and \(Z\) the time until a cryptographically relevant quantum computer exists. You have a problem if

\[ X + Y \;>\; Z. \]

For signatures \(X \approx 0\), since a forgery can't be back-dated, so the condition reduces to finishing the migration before Q-Day. For long-lived confidential data such as health records, state secrets, or a bank's key material, \(X\) can be decades, and the condition may already hold even under optimistic estimates of \(Z\). This framing, not a guess at a single date, is what makes the "no need to panic" and "start now" messages consistent with each other.

3.3 The cryptocurrency paradox

An aside from someone who works in crypto custody: Aumasson argues that no quantum computer will ever be used to steal bitcoins. If Bitcoin were known to be vulnerable and a quantum computer were known or suspected to exist, its price would collapse, destroying what the attacker was after. And a quantum computer kept secret is worth far more used against intelligence targets than spent on a visible, self-defeating theft. The point generalizes: the first real-world uses of a quantum computer will probably be quiet ones, which is one more reason to prioritize confidentiality over signatures.

4. Post-quantum cryptography, briefly

PQC, also called "quantum-safe" or "quantum-secure," is public-key cryptography that runs on today's classical computers but does not rest on factoring or discrete logarithms. Its hardness assumptions come from three families:

• Problems related to NP-hard problems: lattices and error-correcting codes.
• The security of symmetric primitives, e.g. hash-function preimage resistance, as in hash-based signatures.
• And, in Aumasson's words, "problems that we don't know how to solve classically."

4.1 The NIST standards and deadline

NIST ran a public competition from 2016, like the ones that produced AES and SHA-3, and standardized three algorithms, with two more on the way:

Standard	Type	Basis	Status
ML-KEM	Key encapsulation	Module lattices	Standardized (FIPS 203)
ML-DSA	Signature	Module lattices	Standardized (FIPS 204)
SLH-DSA	Signature	Hash functions only	Standardized (FIPS 205), co-authored by Aumasson
FN-DSA	Signature	NTRU lattices (Falcon)	Forthcoming
HQC	Key encapsulation	Codes	Selected as a non-lattice backup KEM

NIST IR 8547 ("Transition to Post-Quantum Cryptography Standards") sets 2035 as the deadline for deploying PQC. For US federal agencies this is mandated by OMB M-23-02 and NSM-10 and enforced by CISA. In practice, large vendors and regulated industries worldwide treat these dates as the default schedule.

4.2 Hybrid schemes

A hybrid scheme combines a post-quantum algorithm with a classical one, for example X25519 and ML-KEM together, producing two ciphertexts whose shared secrets are combined. It is secure as long as either component is secure: X25519 protects you if ML-KEM turns out to have a classical flaw (the PQ schemes are young), and ML-KEM protects you against a quantum adversary. The cost is extra bytes and computation. Aumasson's advice is that the right choice depends on the threat model and how critical the data is. For key exchange, hybrid is the norm in deployment today. For signatures it is less valuable, because a signature break does not cause a retroactive confidentiality breach.

4.3 What PQC costs: size, not speed

The talk's performance slides show the trade-off clearly. Reproduced here (sizes in bytes):

KEM	Public key	Private key	Ciphertext	Speed
ECDH P-256 (classical)	64	32	65	baseline
ML-KEM-512	800	1,632	768	comparable to ECDH
HQC-128	2,249	2,289	4,481	orders of magnitude slower

Signature	Public key	Private key	Signature	Speed
ECDSA P-256 (classical)	64	32	64	baseline
ML-DSA-44	1,312	2,528	2,420	comparable to ECDSA
SLH-DSA-128s	32	64	7,856	orders of magnitude slower

Takeaways from these tables:

• The lattice schemes are fast. ML-KEM and ML-DSA cost roughly what ECDH and ECDSA cost in CPU. Speed is not the problem.
• Size is the problem. An ML-DSA signature is about 38× an ECDSA signature. A TLS handshake carries several signatures and public keys in its certificate chain, which is why PQ authentication in TLS is harder than PQ key exchange. Cloudflare co-introduced Merkle Tree Certificates (see §5) largely to address this.
• Private keys compress. An ML-KEM private key can be stored as a 64-byte seed and an ML-DSA private key as 32 bytes, then expanded when needed. That matters for HSMs and smart cards with little storage.
• Hybrid is cheap for KEMs, because the PQ ciphertext dominates the size anyway, so adding 65 bytes of ECDH is noise.
• SLH-DSA is the conservative choice. Its security rests only on hash functions, which makes it the most trusted assumption. The price is large, slow signatures. It suits root keys, firmware, and other rare, high-value signatures, not per-request authentication.

4.4 Regional initiatives in Asia

Appropriately for a Singapore audience, the talk surveys what Asian governments are doing beyond NIST:

Country	Initiative
China	NGCC competition program to select national PQC standards (submission deadline June 2026)
Japan	No local standards. CRYPTREC (Japan's NIST equivalent) has reviewed PQC algorithms but issued no formal guidelines yet
Singapore	CSA Quantum-Safe Handbook and Quantum Readiness Index
South Korea	KpqC competition (2022–2025) selected KEMs NTRU+ and SMAUG-T and signatures AIMer and HAETAE

For multinationals this means crypto-agility is a compliance requirement, not only an engineering nicety. A product sold in China, Korea, and the US may eventually need different algorithm suites per market.

4.5 How much traffic is already post-quantum

The talk shows Cloudflare Radar's per-country estimates of post-quantum HTTPS traffic for Singapore, Japan, and North Korea. The Singapore and Japan figures reflect the fact that major browsers already negotiate hybrid key exchange by default. North Korea is a cheeky contrast. The broader point: PQ key exchange for web traffic is largely happening without end-user organizations doing anything, as long as their TLS stacks and CDNs are current. The hard remaining work is everywhere else.

5. What you can deploy today

Platform	PQC status per the talk
AWS KMS	ML-DSA signing
Google Cloud KMS	ML-DSA, ML-KEM, and X-Wing (a hybrid KEM) for decryption/wrapping
Azure Key Vault	No PQC support documented
Cloud HSM back-ends	Don't appear to support PQC yet (AWS possibly in preview)
iOS 26	TLS defaults to a PQ KEM via URLSession. CryptoKit exposes ML-DSA and ML-KEM, with Secure Enclave support
Android 17	ML-DSA in Keystore via KeyPairGenerator. The bootloader integrity chain is moving to PQ. PQ TLS not on by default (needs a custom Conscrypt)
Apple ecosystem	iMessage (PQ3) uses hybrid key agreement. VPN/IPsec API support. Apple Watch ↔ iPhone traffic is PQ
Cloudflare	Tunnel is PQ by default. PQ TLS 1.3 with hybrid key agreement. Targets a fully PQ product suite by 2029. Co-introduced Merkle Tree Certificates
HSMs	Most support some PQC with ACVP certificates, but no FIPS-validated module yet
IPsec	PQ key agreement defined for IKEv2. Implemented in strongSwan, not Libreswan
Kubernetes	TLS defaults to PQ via Go 1.24's TLS stack
RHEL 10.1+	The DEFAULT crypto policy uses PQC for SSH and TLS
Signal	End-to-end protocol is PQ via PQXDH (the Noise transport is not)
WhatsApp	Not PQ yet

6. Migration is the wrong word: a quantum-risk management loop

The talk's last section reframes the whole problem. For a product, you can "migrate to PQC." For an organization, legacy cryptography will be around for years (in suppliers, embedded devices, archives, and partner integrations), so the program never really ends. Aumasson structures it as a continuous four-phase loop, deliberately close to the OODA loop:

6.1 Observe: inventory cryptography, yours and your suppliers'

The inventory slide works as a checklist. Group findings by what the cryptography protects:

• Confidentiality: public-key encryption and key agreement (KEMs, symmetric-key wrapping); public-key-protected encrypted files on shared filesystems and git repos; encrypted email and messaging (PGP, S/MIME, apps); encrypted archives and backups (database dumps, cloud backups); secure transport (TLS, SSH, IPsec, WireGuard). Pre-shared keys offer partial mitigation.
• Key infrastructure: KMS and HSMs. What are the keys used for, and how are they protected?
• Shared/ledger systems: blockchains and distributed ledgers. Is data shared with other parties affected, including ZK proofs?
• Signature and authentication: access to critical systems is a priority even though store-now-decrypt-later doesn't apply; code signing (apps, bootloaders), especially embedded systems whose integrity checks can't be updated; PKI and certificate chains, which may contain keys used for encryption; authorization and authentication frameworks.

How to collect it: review documentation and policies (don't change them yet); review configuration files and templates; and verify claimed PQ support on live systems, because documentation and deployed reality often differ. For third parties, read their documentation and settings and ask vendors directly for their PQC roadmap. Tooling helps: cbomkit for generating a cryptographic bill of materials from code, ssh-audit for SSH endpoints (the talk demos ssh-audit <host> checking an SSH server's key-exchange algorithms), plus commercial scanners.

6.2 Assess: prioritize by risk and cost

Risk criteria	Cost criteria
How long the data stays sensitive (the \(X\) in Mosca's inequality)	Technical difficulty: a settings change vs. custom development
Exposure outside the organization	Impact on bandwidth and performance (see the size tables in §4.3)
Asset volume and criticality: PII, key material, classification level	Interoperability and certification challenges
Regulatory and contractual obligations

Plot systems on these two axes and the quick wins become obvious: high-risk, low-cost items such as enabling a PQ crypto policy on RHEL or upgrading Go services. The multi-year items are equally obvious: high-risk, high-cost ones such as bespoke protocols, HSM-bound signing, and embedded fleets.

6.3 Decide: policy and roadmap

• Cryptography policy: newly deployed cryptography must be PQ. This single line stops the inventory from growing.
• Key management procedures: adapt them to PQC's larger keys, seed-based private key storage, and hybrid key pairs.
• Supplier and third-party requirements: put PQC into procurement and third-party risk management.
• Roadmap: milestones from quick wins to multi-year efforts, clear roles and responsibilities, and explicit deprecation deadlines for classical algorithms.

6.4 Communicate, act, monitor

The talk gives unusual attention to communication, which is realistic: most migration failures are organizational.

Audience	What they need
Board / management	"We have a plan"
Engineers	Concrete requirements for TLS, SSH, etc., with pointers to libraries and code examples
Procurement / TPRM / legal	Requirements for new vendors
Retail clients / users	A public roadmap overview
Enterprise clients	Detailed internal documents (crypto policy etc.)
Partners / suppliers	PQ requirements and joint upgrade plans

Then: plan, develop, test, deploy, and, in the slide's own words, "pray it actually works." To make it continuous, add discovery controls (scans and audits that catch new classical crypto), put quantum risk into the enterprise risk model, evaluate new features and providers for PQC readiness, and plan contingencies for the case where critical data is decrypted later. That last item is often skipped. For data already captured under classical key exchange, migration cannot help, and only an incident-response plan can.

7. The three-line conclusion

1. No need to panic. Hardware is far from cryptographic relevance, and credible estimates don't put Q-Day in the next decade.
2. Integrate PQC support into your products now. The standards are final, the lattice schemes are fast, and the libraries exist.
3. Large organizations must manage the risk as a continuous program, not a one-off project.

If Q-Day is probably after 2036, why act now?

Because of store-now-decrypt-later and migration time. Mosca's inequality \(X + Y > Z\) says data that must stay secret for 15 years, protected by a system that takes 5 years to migrate, is already exposed if a quantum computer arrives within 20 years. Signatures can wait longer. Confidentiality usually can't.

Should I use hybrid or pure PQ?

For key exchange, hybrid (e.g. X25519 + ML-KEM) is the deployment norm: it's cheap because the PQ ciphertext dominates the size, and it protects against a classical break of the young PQ scheme. For signatures, hybrid adds less value, because a signature break doesn't cause retroactive disclosure.

What's the first concrete thing to do?

An inventory. Run ssh-audit and a TLS scan against your estate, generate a CBOM from your main codebases, list every embedded device that verifies firmware signatures, and set a policy that all newly deployed crypto must be PQ.

Is my Kubernetes cluster already post-quantum?

Its TLS key exchange likely is if its components are built with Go 1.24+, whose TLS stack defaults to a hybrid PQ key exchange. Certificates and signatures are still classical. Verify on the live cluster rather than assuming.

Takeaways

• Quantum computers threaten only a few problems, but those problems (factoring and discrete log) underlie all deployed public-key crypto, including MPC wallets, ZK systems, and PAKEs.
• Timing is unknown. Aumasson's estimate is no Q-Day before 2036. Use Mosca's inequality, not a guessed date, to decide urgency.
• Confidentiality before signatures, because only encryption is exposed to store-now-decrypt-later.
• ML-KEM and ML-DSA are as fast as ECC but 10–40× larger. Size, not speed, is the engineering constraint.
• Much PQC is already on by default (Go 1.24 TLS, RHEL 10.1, iOS 26, Cloudflare). Upgrading is often the migration.
• Run it as a risk-management loop: observe, assess, decide, act, repeat. Find unupgradeable embedded signature checks first.

References & further reading

• Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
• Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
• awesome-post-quantum (Aumasson) — NIST/IETF standards, regional guidance, vendor docs, and open-source libraries.
• NIST IR 8547 — Transition to Post-Quantum Cryptography Standards — the 2035 deprecation timeline.
• Apple Platform Security — quantum-secure cryptography — iOS 26 TLS, CryptoKit, and Secure Enclave support.
• Google Security Blog — PQC in Android — Android 17 Keystore ML-DSA.
• CSA Singapore — Quantum-Safe Handbook & Readiness Index — Singapore's national guidance.
• Cloudflare Radar — post-quantum adoption — per-country PQ HTTPS traffic.
• Aumasson — Quantum computers will not steal bitcoins — the "quantum gravity principle" essay.
• cvam.sight — Post-Quantum Cryptography course (18 parts) — the full lattice math, ML-KEM/ML-DSA/SLH-DSA internals, hybrid TLS, and migration engineering.