Parag Mali - tag: crypto-migration

You Cannot Rotate What You Cannot See: Crypto-Agility and the Cryptographic Bill of Materials

noreply@paragmali.com (Parag Mali) — Tue, 14 Jul 2026 03:13:06 GMT

Post-quantum migration is two problems wearing one name: being able to ROTATE your cryptography, and being able to SEE where it all lives. The new algorithms are the easy part -- ML-KEM is a `pip install` away and already ships inside Windows. The hard part is finding the old RSA, ECDH, and ECDSA, which is "typically buried deep within components." Crypto-agility (RFC 7696, 2015) is the design-time discipline for rotating. The Cryptography Bill of Materials (CBOM), upstreamed into CycloneDX v1.6 in April 2024, is the machine-readable substrate for seeing: it models cryptography as a first-class asset with `implements` and `uses` dependencies you can prioritize as a graph. Executive Order 14412 makes the stack binding -- key establishment by 2030, signatures by 2031 -- and directs CISA to define CBOM's minimum elements. But both halves have a provable ceiling: complete automated discovery is undecidable, and long-lived signatures, trust anchors, and firmware cannot be rotated after the fact. This is the field guide to both verbs, and to why you cannot rotate what you cannot see.

1. You Cannot Rotate What You Cannot See

In November 2022, the White House told every federal civilian agency to do something that sounds almost trivial: make a list. OMB Memorandum M-23-02 directed each agency to produce a prioritized inventory of the cryptographic systems most vulnerable to a future quantum computer, to submit the first version by May 4, 2023, and to keep it current every year through 2035 [@omb-m2302]. Not to migrate anything yet. Just to write down where the vulnerable cryptography was, and to name a migration lead within thirty days to own the effort [@omb-m2302].

Agencies discovered they could not do it. They could not reliably answer the question "where does our RSA-2048 actually live?" -- because, as IBM's own documentation for the Cryptography Bill of Materials puts it, cryptography "is typically buried deep within components that are used to compose and build systems and applications" [@ibm-cbom]. The mandate assumed a list any competent organization could produce. The list turned out to be the hard part.

Now the deadlines are real. Executive Order 14412, signed June 22, 2026, orders agencies to move their high-value and high-impact systems to post-quantum key establishment by December 31, 2030 and to post-quantum digital signatures by December 31, 2031 [@eo14412]. And here is the asymmetry that reframes the entire migration: the new algorithm is the easy part. NIST finalized the replacements in FIPS 203, 204, and 205 on August 13, 2024 [@fips203].

ML-KEM, the standardized replacement for the key exchange that Shor's algorithm dooms, is a pip install away in Python and already ships inside Windows' SChannel and SymCrypt [@pyca-changelog] [@ms-pqc-windows], as the sibling posts in this series show.The two "migrate to what" endpoints are covered in companion posts: ML-KEM arriving in the default pyca/cryptography wheels, and ML-KEM plus ML-DSA landing in Windows SChannel and SymCrypt. This article is deliberately the other half -- finding the old cryptography, not adopting the new.

You can adopt the replacement this afternoon. What you cannot do this afternoon -- or this quarter, or perhaps by the deadline -- is enumerate every place your organization still relies on the cryptography it replaces.

Note: FIPS 203, 204, and 205 were finalized in August 2024 [@fips203], and quantum-safe primitives now ship in mainstream libraries and operating systems [@pyca-changelog] [@ms-pqc-windows]. Yet the 2030 and 2031 deadlines are hard [@eo14412]. The binding constraint is not availability. It is visibility -- knowing where the quantum-vulnerable cryptography is.

Post-quantum migration is really two problems wearing one name. One is being able to change your cryptography -- the discipline of crypto-agility, which the field has refined since the 1990s and formalized in 2015. The other is knowing where your cryptography is -- the inventory problem, which almost nobody was forced to take seriously until a mandate arrived with a deadline attached.

The two-verb diagnostic runs through everything that follows. ROTATE: can a system change its algorithms at all, without being re-architected? SEE: does the organization actually know where its RSA, ECDH, and ECDSA are deployed? The thesis of this field guide is one line: you cannot rotate what you cannot see.

Why does the split matter so precisely, and why do the two deadlines differ by a year? Because the threat driving the confidentiality deadline is not a quantum computer that exists today. It is an adversary recording your encrypted traffic today to decrypt it later, once a capable quantum machine is built.

The threat model in which an adversary records encrypted data today and stores it, intending to decrypt it once a sufficiently capable quantum computer exists. Because captured ciphertext can be broken retroactively, HNDL makes confidentiality and key establishment urgent *now* -- even before any quantum computer is built. It does not threaten digital signatures, which cannot be forged retroactively, which is why Executive Order 14412 dates key establishment (2030) ahead of signatures (2031) [@eo14412]. A quantum computer large and reliable enough to run Shor's algorithm against deployed RSA and elliptic-curve key sizes. No CRQC is known to exist yet; its uncertain future arrival date is the quantity a migration plan races against, and the term that anchors the prioritization math introduced later in this guide.

The ability to swap an algorithm is the half the field spent thirty years perfecting. Knowing where every algorithm lives is the half it avoided until a deadline made avoidance impossible. To see how the discipline got so lopsided, start where the pain began: with cryptography that could not be changed at all.

2. Algorithm Rigidity as Original Sin

Long before anyone worried about quantum computers, migrating a single cryptographic algorithm was already agony -- and the reason was structural, not mathematical. The 2030 deadline is a decade-long emergency, not a weekend of pip install commands, because changing one algorithm has always been so hard that it takes decades.

Start with why a migration is coming at all. In 1994, Peter Shor showed that a quantum computer could factor large integers and compute discrete logarithms in polynomial time [@shor1994]. That single result put RSA, Diffie-Hellman, elliptic-curve Diffie-Hellman, and ECDSA on notice: the mathematical problems they rely on become tractable to a sufficiently large quantum machine.

The internals of Shor's algorithm and the lattice math that replaces these primitives belong to the companion posts in this series. For this guide, one fact is enough: the public-key cryptography holding up most of the internet has a known expiration condition, and the field has known it for three decades.

Knowing an algorithm will eventually fall is not the same as being able to replace it. The deeper problem is that early protocols baked a single primitive directly into their design. There was no algorithm identifier on the wire, so a peer could not announce which cipher it intended to use, and there was no clean seam at which to substitute a different one.

RFC 7696, the IETF's 2015 best-current-practice document on the subject, describes the consequence precisely: without an algorithm identifier, transitioning "from one algorithm to another" requires "the protocol version number or some other major change" [@rfc7696]. Swapping a cipher meant revising the protocol itself.

The design-time property that, in RFC 7696's words, "Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time" [@rfc7696]. In plain terms: the ability to change cryptographic algorithms without re-architecting the systems that depend on them. It is a property you build in before you need it -- and it says nothing about discovering cryptography you have already deployed.

The canonical worked example is slow, symmetric, and instructive. RFC 7696 notes that "the transition from DES to Triple-DES to AES took place over decades, causing a shift in symmetric block cipher strength from 56 bits to 112 bits to 128 bits" [@rfc7696].That 56-to-112-to-128-bit progression over roughly a quarter century is the template the public-key world is now rerunning against RSA and elliptic curves, except compressed into a single mandated decade. The symmetric transition had no hard federal deadline; this one does. Decades, for a change every cryptographer agreed was necessary. And the reason was not that AES was hard to implement. It was that thousands of systems had hardcoded the old cipher with no seam at which to change it.

This is the original sin, and it compounds. RFC 7696 opens with the blunt observation that "cryptographic algorithms age; they become weaker with time," so protocol designers "need to assume that advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete" [@rfc7696]. If aging is certain and the algorithm is welded in place, then every cryptographic break becomes an estate-wide re-architecture. The field lived this repeatedly: DES and Triple-DES, MD5, RC4, and SHA-1 each had to be ripped out of deployed systems at enormous cost.

RC4 was so entrenched that removing it required the IETF to publish an entire standard, RFC 7465, whose sole job was to command that "TLS clients and servers never negotiate the use of RC4 cipher suites when they establish connections" [@rfc7465].Adding an algorithm is easy; removing one is so hard that it can take a dedicated standards-body prohibition. RFC 7465 exists only to say "stop using RC4" -- a one-line policy that needed the weight of a published RFC because the cipher was wired into too many implementations to retire quietly [@rfc7465].

timeline title From Shor to a federal deadline 1994 : Shor's algorithm dooms RSA, DH, and ECC in theory 1990s-2001 : DES to Triple-DES to AES over decades 2015 : RFC 7696 turns agility into a discipline 2022 : NSM-10 and OMB M-23-02 mandate a prioritized inventory 2023 : NIST NCCoE SP 1800-38 preliminary draft on discovery 2024 : CBOM upstreamed into CycloneDX v1.6 2025 : NIST CSWP 39 restates agility as risk management 2026 : Executive Order 14412 sets the 2030 and 2031 deadlines

Notice the character of this failure. It is not that the cryptography computed the wrong answer. DES still encrypts; MD5 still hashes. The failure is one of operability: the algorithm runs fine, but the system cannot move off it. That distinction matters, because it means the fix is not a better algorithm. The fix is a better design -- one that stops welding the primitive in place.

The obvious such fix is to put a name on the wire and let the peers choose. That fix has a name of its own, cipher-suite negotiation, and for a while it looked like the whole answer. It was not.

3. Negotiation and the Spreadsheet

Each half of the problem got a first-generation answer. Both were reasonable. Both under-delivered, and in almost the same instructive way. If you can negotiate algorithms at connection time and audit the results into a spreadsheet, what could possibly be left to solve?

The rotate half's first answer was negotiation. Instead of welding one cipher into the protocol, carry an identifier for the algorithm -- or for a whole suite of them -- on the wire, back it with an IANA registry of code points, and let the two endpoints agree on the best option they both support. TLS cipher suites, IKE and IPsec transforms, the X.509 AlgorithmIdentifier, and the JOSE and COSE object formats all work this way.

RFC 7696 blesses the approach while carefully bounding its importance: "The inclusion of an algorithm identifier is a minimal step toward cryptographic algorithm agility" [@rfc7696]. Minimal is the operative word.

Negotiation is necessary, and it is nowhere near sufficient, for three documented reasons. First, negotiation you do not integrity-protect can be turned against you. RFC 7696 warns that an unprotected negotiation "will be subject to a downgrade attack" [@rfc7696], and the field has the scars to prove it. The 2015 Logjam attack "allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography" [@weakdh], steering two peers who both support strong Diffie-Hellman down to a key size a well-resourced attacker can break [@weakdh-pdf]. FREAK and POODLE are cousins in the same family [@freak] [@poodle].

Second, negotiation encourages ossification: because dropping an option can break some peer somewhere, "flawed algorithms are supported for far too long" [@rfc7696] -- which is exactly why retiring RC4 needed its own prohibiting standard [@rfc7465].

Third, every additional negotiable option is additional attack surface and additional code to get right [@rfc7696].

Note: Being able to negotiate a strong cipher does two things it is easy to conflate with a solved migration, and neither is one. Unprotected negotiation invites downgrade attacks -- Logjam, FREAK, and POODLE all forced peers onto weak-but-supported options [@weakdh] [@freak] [@poodle]. And selecting AES at connection time tells you nothing about where the weak algorithm still lives. Negotiating AES on one server says nothing about which of your ten thousand other servers still negotiate RC4.

That last point is the decisive one for this guide. Negotiation lets a system select among options both peers pre-agreed to support. It gives you no ability to remove an algorithm across your estate, and -- this is the part everyone misses -- no ability to know where a given algorithm is deployed in the first place.

A protocol that can negotiate its way onto AES has told you nothing about the inventory of RC4, RSA-1024, or SHA-1 scattered across your servers, firmware, and stored certificates. Agility at the connection is not visibility across the estate.

The two negotiation styles are both legitimate and opposite. IPsec and IKEv2 carry a separate identifier for each algorithm; TLS carries one identifier per whole suite. RFC 7696 explicitly blesses both -- "some approaches carry one identifier for each algorithm ... other approaches carry one identifier for a full suite of algorithms" [@rfc7696] -- trading a combinatorial explosion of options against coarser, less flexible suites. There is no single right answer, only a design choice.

The see half's first answer was the spreadsheet. Manual audits, one-off certificate scans, a cryptography inventory maintained by hand. It is the natural first move, and it fails for reasons that have nothing to do with effort. A spreadsheet does not scale to an estate of thousands of applications and millions of certificates. It is stale the moment it is written, because code ships and certificates rotate daily.

It is not machine-actionable: you cannot run a query against it, diff it against last quarter, or check it automatically against a 2030 deadline. And it cannot be propagated -- when a vendor updates a library, nothing in your spreadsheet knows. It is a document, not a queryable system.

The one semi-automated technique in wide use, certificate discovery, is genuinely useful but sees only the public-key infrastructure surface: the certificates, not the code that calls them or the protocols that carry them.

To name the shape of the answer that eventually arrives, borrow the idea the software supply chain had already converged on.

A machine-readable inventory of the components inside a piece of software and the dependencies among them, published in a standard format such as CycloneDX or SPDX so that tools -- not people -- can query, diff, and act on it [@owasp-cdx16]. An SBOM is to software components what a later chapter's Cryptography Bill of Materials is to cryptographic assets: the crypto version is a specialized extension of exactly this idea.

Both first answers failed for the same underlying reason: they treated agility and inventory as afterthoughts to bolt on, rather than disciplines to design for. The difference in what happened next is the whole story of the next section. The rotate half got its discipline first, compressed into a single 2015 document that turned "agility" from a slogan into an engineering checklist. The see half got nothing comparable -- until someone with a deadline made organizations solve it.

4. From Slogan to Discipline, and the Inventory Forced Into the Open

This is where the two lineages split, mature on separate tracks, and then -- years later -- get forced back together by a mandate. It also poses the sharpest question in the whole story: if algorithm agility became a real engineering discipline in 2015, why were federal agencies still helpless in front of a simple inventory in 2022?

The rotate half got its discipline in a single document. In November 2015, Russ Housley published RFC 7696, "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms," as IETF Best Current Practice 201 [@rfc7696]. It turned a slogan into a checklist. Register your algorithm identifiers. Keep the set of algorithms every implementation must support small, and -- the load-bearing idea -- put that set in a companion document so it can change "without updating the base protocol specification" [@rfc7696]. Integrity-protect your negotiation so it cannot be downgraded [@rfc7696].

And heed two cautions that sound paradoxical until you have lived them: section 3.2 is titled "Too Many Choices Can Be Harmful," and section 3.3 is titled "Picking One True Cipher Suite Can Be Harmful" [@rfc7696]. Too many negotiable options is attack surface; exactly one is a single point of failure with no in-band recovery. The discipline lives in the tension between them.

The small set of algorithms every conformant implementation of a protocol is required to support, so that any two implementations are guaranteed to share at least one. RFC 7696 recommends keeping the MTI set in a separate companion document precisely so the required algorithms can change "without updating the base protocol specification" when one weakens [@rfc7696] -- agility applied to the requirements themselves.

Here is the limit that makes 2015 insufficient for 2022. RFC 7696 is design-time and forward-looking. It helps every system you build after you adopt it, and it says nothing about discovering the cryptography you already deployed across a legacy estate. An organization can adopt RFC 7696 wholesale for all new development and still be completely unable to answer "where does RSA-2048 live in what we already run?" The discipline hardens the rotate half. It never touched the see half.

The see half was forced open by a mandate. In May 2022, National Security Memorandum 10 set the strategy: inventory the government's quantum-vulnerable cryptography [@nsm10]. That November, OMB M-23-02 operationalized it, directing every agency to submit a prioritized cryptographic inventory, to designate a cryptographic inventory and migration lead within thirty days, and to repeat the inventory annually [@omb-m2302]. The order was not "migrate." It was merely "tell us what you have, worst things first."

And it exposed the binding constraint immediately: agencies could not enumerate their own quantum-vulnerable cryptography, because -- as IBM's CBOM documentation states -- it "is typically buried deep within components that are used to compose and build systems and applications" [@ibm-cbom]. The manual method the mandate inherited did not scale to the estate it was pointed at. This, not any algorithm milestone, is the real turning point of the field: thirty years of perfecting the rotate half had left the see half genuinely unsolved.

"Cryptography is typically buried deep within components that are used to compose and build systems and applications." -- IBM CBOM documentation, on why an inventory is the hard part [@ibm-cbom]

Automation answered the scale problem, and revealed a deeper one. CISA responded with a strategy for Automated Cryptography Discovery and Inventory tools, describing their purpose as "the use of ACDI tools to support a FCEB agency in its creation of an inventory of its information systems and assets that contain CRQC-vulnerable cryptography," where "the inventory tools automate the collection of the cryptographic characteristics required for the inventory" [@cisa-acdi]. NIST's National Cybersecurity Center of Excellence supplied a reference architecture in the SP 1800-38 practice guide, which remains a preliminary draft rather than a finalized standard [@sp1800-38-guide].

Automation gave the see half the scale a spreadsheet never had. But it exposed a subtler gap: a scanner emits a pile of tool-specific findings, not a queryable inventory. "Component X contains AES" carries no distinction between the algorithm family and the specific variant, and no dependency structure connecting the library that implements an algorithm to the application that uses it. Automation delivered scale without a data model.

CISA's term for tools that automatically enumerate an organization's cryptographically relevant, quantum-vulnerable assets across its systems, collecting "the cryptographic characteristics required for the inventory" rather than relying on manual audits [@cisa-acdi]. ACDI supplies the scale a manual inventory lacks -- but on its own it produces findings, not a structured, prioritizable model.

Key idea: Post-quantum migration is two verbs, not one: ROTATE, the design-time discipline of being able to change your cryptography, and SEE, the run-time practice of knowing where it all lives. The field perfected the rotate half over thirty years -- rigidity to negotiation to RFC 7696 -- and only closed the see half under a federal deadline. You cannot rotate what you cannot see.

The two lineages, and their eventual meeting point, look like this when you draw them on one page.

flowchart TD subgraph ROT["ROTATE lane -- design-time agility"] R1[Hardcoded rigidity] --> R2[Cipher-suite negotiation] R2 --> R3[RFC 7696 discipline] R3 --> R4[NIST CSWP 39 risk guidance] end subgraph SEE["SEE lane -- run-time inventory"] G1[Manual spreadsheet] --> G2[Federal mandate NSM-10 and M-23-02] G2 --> G3[Automated discovery ACDI] end R4 --> CBOM["CycloneDX CBOM, crypto as a first-class asset"] G3 --> CBOM CBOM --> EO["Executive Order 14412 makes the stack binding"]

The condensed history of both lanes fits in one table.

Generation	Era	Key idea	Why it was superseded, or its limit	Status
1. Hardcoded rigidity	pre-2000s	One primitive baked in, no wire identifier	Every break forced an estate-wide re-architecture	Obsolete
2. Cipher-suite negotiation	1990s-2010s	Algorithm or suite identifiers, IANA registry, negotiate	Downgrade attacks and ossification; selects but cannot see or remove	Necessary, insufficient
3. Agility as discipline (RFC 7696)	2015	Registered IDs, MTI in a companion doc, protected negotiation	Design-time and forward-looking only; blind to deployed crypto	Current (rotate half)
4. Manual inventory under mandate	2022 (NSM-10 / M-23-02)	Order a prioritized cryptographic inventory	Spreadsheet does not scale, stale, not machine-actionable	Superseded by automation
5. Automated discovery (ACDI)	2022-2025	Tools auto-collect cryptographic characteristics	A pile of tool-specific findings, no shared data model	Current (scale)
6. CBOM substrate	2024 (CycloneDX 1.6)	Model crypto as a first-class asset with dependencies	Only as complete as the scanners that populate it	Current (see half)

The deadlines in this article are precise about scope, and it matters. Executive Order 14412 requires *federal agencies* to transition their high-value assets and high-impact systems -- explicitly excluding National Security Systems -- to post-quantum key establishment by December 31, 2030 and to post-quantum digital signatures by December 31, 2031 [@eo14412]. A companion Federal Acquisition Regulation rule pushes covered federal contractors toward compliance by December 31, 2030 [@eo14412]. Critical infrastructure operators are *encouraged*, not mandated. That National Security Systems exclusion is a hand-off, not a gap: NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, September 2022) already owns that estate, mandating the same NIST winners -- ML-KEM and ML-DSA -- on its own use-case-staggered schedule, to be complete by 2035 in line with NSM-10, the memorandum that set the whole government-wide posture [@cnsa2] [@nsm10]. The civilian and national-security tracks are two branches of one 2022 origin. And one more distinction worth burning in: EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks") is not EO 14413, a separate order about quantum innovation published in the same Federal Register issue [@eo14412]. Do not cite one for the other.

Design-time agility was, by 2024, a solved discipline. Run-time inventory finally had scale, but no shape. The missing piece was never another scanner. It was a way to model cryptography itself as an asset you could query, prioritize, and pass down a supply chain. That piece arrived on April 9, 2024.

5. The Breakthrough: Cryptography as a First-Class Asset

The breakthrough was not a better scanner. It was a decision to model cryptography the way the software supply chain already models its components -- as inventoried assets with dependencies you can query. To see why that is a genuine shift and not a rebranding, ask what a raw scan finding is missing. What does "component X contains AES" need to carry before it becomes something you can actually act on?

On April 9, 2024, that question got an answer with a standard behind it. IBM Research's Cryptography Bill of Materials was upstreamed into OWASP CycloneDX v1.6 [@owasp-cdx16]. CBOM was carried into the current CycloneDX v1.7 (October 2025), published as the Ecma International standard ECMA-424, which extended the cryptography model further [@cdx-spec-17]. The design choice that matters most is the quietest one: a CBOM is an extension of the same CycloneDX BOM document, not a separate schema [@ibm-cbom]. Your cryptographic inventory can live in the same file as your software inventory, produced by the same tools, consumed by the same pipelines. CBOM did not invent a parallel supply chain. It taught the existing one to describe cryptography.

Its design answers four specific ways a raw finding falls short [@ibm-cbom]. First, it models the asset types that matter -- algorithms, protocols, certificates, and "related crypto material like keys, tokens, secrets or passwords." Second, it captures the property that makes a finding actionable: the difference between a family and a variant. As the CBOM documentation puts it, "it makes a difference if one knows the algorithm family (e.g. AES) or the specific variant ... (e.g. AES-128-GCM) ... SHA1 vs. HMAC-SHA1 also makes a difference" [@ibm-cbom]. A report of "AES" is not actionable. "AES-128-GCM at file X, line 51" is.

An extension of the CycloneDX BOM document that models an organization's cryptographic assets -- algorithms, protocols, certificates, and related key material -- together with their properties and the dependencies among them [@ibm-cbom]. At the field level, a crypto-asset is a component of type `cryptographic-asset` carrying `cryptoProperties` (whose `assetType` is one of algorithm, certificate, protocol, or related-crypto-material) and `evidence.occurrences` recording where it was found [@cdx-cbom-cap] [@cdx-cbom-guide]. It is the first open standard purpose-built to describe cryptography as an inventoried, dependency-aware asset.

The third design goal is the one that turns a list into a graph. CBOM "differentiates between 'implements' and 'uses' dependencies ... (e.g. TLS 1.3 uses ECDH/secp256r1)" [@ibm-cbom]. A library implements an algorithm; an application uses it. That single distinction is the edge type that lets you answer the question the whole migration turns on: which applications transitively depend on a quantum-vulnerable primitive? Fourth and finally, the model applies uniformly across applications, libraries, firmware, and files, so the same representation describes source code, a shipped container, and an embedded device.

CBOM's two crypto-asset relationship types. A component *implements* a cryptographic asset when it provides the algorithm (a library implements ECDH/secp256r1); a component *uses* an asset when it consumes it (TLS 1.3 uses ECDH/secp256r1, and an application uses TLS 1.3) [@ibm-cbom]. Distinguishing the two turns a flat inventory into a directed graph -- and makes "which applications are exposed to this weak primitive?" a graph traversal rather than a guess.

Model each crypto-asset with cryptoProperties and connect them with implements and uses edges, and the inventory stops being a list and becomes a directed graph. The CycloneDX capability documentation describes exactly this: the format "enables detailed representation of cryptographic assets within a system," including "algorithms, keys, certificates, and their relationships to software components" [@cdx-cbom-cap]. On a graph, prioritization is a traversal -- and a traversal over $V$ assets and $E$ dependencies costs $O(V + E)$, cheap enough to run over an entire estate.

The graph reads directly. The application payments-api uses TLS 1.3, which uses ECDH over secp256r1 -- a key-exchange primitive Shor's algorithm defeats. Follow the uses edges and the exposure is explicit: this application is on the 2030 list. The implements edges tell you where to fix it: openssl provides that primitive, so the remediation targets that library. The same two edge types that describe the estate also route the work.

CBOM concept	What it captures	Example
`assetType: algorithm`	A cryptographic algorithm or primitive	ML-KEM, RSA-2048, ECDH/secp256r1, AES-128-GCM
`assetType: certificate`	An X.509 certificate as an inventoried asset	A TLS server certificate expiring in 2029
`assetType: protocol`	A protocol that consumes cryptography	TLS 1.3, SSH, IKEv2
`assetType: related-crypto-material`	Keys, tokens, secrets, passwords	A stored private key or API token
Family vs variant	The property that makes a finding actionable	AES vs AES-128-GCM; SHA-1 vs HMAC-SHA1
`implements` edge	A library provides an algorithm	`openssl` implements ECDH/secp256r1
`uses` edge	An application or protocol consumes an algorithm	TLS 1.3 uses ECDH/secp256r1
`evidence.occurrences`	Where the asset was actually found	File path and line number

Here is the traversal made concrete. The snippet below parses a miniature CBOM and walks its uses edges to flag every application transitively exposed to a quantum-vulnerable primitive.

{` // Pedagogical, not production -- use a vetted tool such as CBOMkit. // A tiny CycloneDX-style CBOM: crypto-assets plus implements/uses edges. const cbom = { components: [ { ref: "app:payments-api", type: "application" }, { ref: "proto:tls-1.3", type: "cryptographic-asset", assetType: "protocol" }, { ref: "alg:ecdh-secp256r1", type: "cryptographic-asset", assetType: "algorithm", quantumVulnerable: true }, { ref: "alg:aes-128-gcm", type: "cryptographic-asset", assetType: "algorithm", quantumVulnerable: false }, { ref: "lib:openssl", type: "library" } ], dependencies: [ { ref: "app:payments-api", dependsOn: ["proto:tls-1.3"], kind: "uses" }, { ref: "proto:tls-1.3", dependsOn: ["alg:ecdh-secp256r1"], kind: "uses" }, { ref: "lib:openssl", dependsOn: ["alg:ecdh-secp256r1", "alg:aes-128-gcm"], kind: "implements" } ] };

// Adjacency map built from the "uses" edges only. const usesEdges = {}; for (const d of cbom.dependencies) { if (d.kind === "uses") usesEdges[d.ref] = d.dependsOn; } const vulnerable = new Set( cbom.components.filter(c => c.quantumVulnerable).map(c => c.ref) );

// Depth-first: does this component transitively use a vulnerable primitive? function reachesVulnerable(ref, seen) { seen = seen || new Set(); if (seen.has(ref)) return false; seen.add(ref); for (const next of (usesEdges[ref] || [])) { if (vulnerable.has(next) || reachesVulnerable(next, seen)) return true; } return false; }

const apps = cbom.components.filter(c => c.type === "application"); for (const app of apps) { const verdict = reachesVulnerable(app.ref) ? "EXPOSED" : "clear"; console.log(app.ref + " -> " + verdict); } `}

Key idea: CBOM's breakthrough is not discovery power -- it is a data model. Model each crypto-asset with the property that makes it actionable (family versus variant) and its implements and uses dependencies, and a pile of tool-specific scan findings becomes a prioritizable graph you can query with a single traversal.

"CBOM is the first open standard to describe an organizations' cryptographic assets inventory, and their dependencies." -- Michael Osborne, CTO, IBM Quantum Safe [@owasp-cdx16]

One caution keeps this honest, and a later section pays it off in full. A CBOM is a data model, not a discovery method. It is only ever as complete as the scanners that populate it [@ibm-cbomkit-blog]. Modeling cryptography as a graph is necessary, and it does not make the cryptography any easier to find.CycloneDX v1.6 shipped Attestations (CDXA) alongside CBOM -- machine-readable "attestations to the veracity and completeness of those claims" [@owasp-cdx16]. That plumbing is what the open problem of completeness attestation, discussed later, is built on: a way to state not just what you found, but how thoroughly you looked.

With cryptography finally modeled as a queryable, prioritizable graph, the remaining pieces could be assembled into a real pipeline: discipline at design time, discovery across every surface, roll-up into a CBOM, and prioritization against a deadline. By 2026, that pipeline has a definite shape.

6. The Discovery-to-Migration Stack (2026)

The state of the art in 2026 is not a product. It is a layered pipeline, and its governing rule is that no single layer is complete. Read from the top, it takes a legacy estate and produces a prioritized, deadline-aware migration plan.

The design-time layer is crypto-agility as discipline. RFC 7696 did not stay an IETF document. In December 2025, NIST published Cybersecurity White Paper 39, "Considerations for Achieving Cryptographic Agility: Strategies and Practices" (updated as CSWP 39-upd1 in June 2026), restating algorithm agility as national risk-management guidance [@cswp39]. The author list closes a thirty-year loop: Russ Housley, who wrote RFC 7696, appears alongside the leaders of NIST's post-quantum standardization such as Dustin Moody and Lily Chen, and William Newhouse, who leads the NCCoE inventory work [@cswp39].

The people who standardized the new algorithms, the person who formalized agility, and the person building the inventory practice signed the same page. Agility sits at the top of the stack because it is what makes the eventual swap cheap.

The discovery layer is five surfaces, and each is blind exactly where another sees clearly. This is the heart of the see half, and the reason the outputs must be merged rather than chosen among.

Static source analysis reads owned source code and reports cryptographic calls with file-and-line precision. CBOMkit-Hyperion and its Sonar Cryptography plugin do this today, generating a CBOM directly from source and covering Java's JCA and Python's pyca/cryptography libraries [@sonar-crypto] [@ibm-cbomkit-blog]. It is precise and cheap in continuous integration -- and blind to third-party binaries it cannot see the source of, and to algorithms selected through dynamically constructed names.
Binary and container analysis reaches what static analysis cannot: shipped binaries, container images, and firmware. CBOMkit-Theia scans these artifacts [@cbomkit]. It reaches code you did not build -- and is defeated by packing and obfuscation, which can make cryptographic code indistinguishable from anything else.
Passive network monitoring observes the algorithms actually negotiated on live links, giving ground-truth on what is really in use. It is blind to data at rest and to systems that are simply idle during the capture window.
Active probing connects to listening services and enumerates the algorithms they will agree to negotiate, producing a capability census. It reaches only services that are listening, and says nothing about internal batch jobs or stored data.
Certificate and key-store analysis is the most mature surface and feeds the 2031 signature deadline most directly, but it sees only the public-key infrastructure: certificates, keys, and signature algorithms, not the code or protocols around them.

Note: No single surface is complete, so the operational rule is to run several and merge them, then budget a permanent manual-validation pass over the residual. This is not a workaround; it is what CISA's ACDI strategy and NIST's SP 1800-38 practice guide prescribe -- a method mix feeding a human-checked inventory, never one tool trusted to see everything [@cisa-acdi] [@sp1800-38-guide].

The five surfaces do not rank; they tile. Draw them feeding one merge-and-validate step, and the architecture is clear.

flowchart TD SRC[Static source scan] --> MERGE BIN[Binary and container scan] --> MERGE NET[Passive network sensor] --> MERGE PROBE[Active probing census] --> MERGE CERT[Certificate and key-store scan] --> MERGE MERGE[Merge and manual validation] --> CBOM[CycloneDX CBOM]

Discovery surface	What it sees	Scaling	Primary blind spot	Best suited for
Static source	Crypto calls in owned source, with file and line	High, runs in CI	Third-party binaries, dynamic names	Owned codebases
Binary / container	Crypto in shipped binaries, containers, firmware	Medium	Packing and obfuscation	Third-party and embedded artifacts
Passive network	Algorithms actually negotiated on the wire	High	Data at rest, idle systems	Live ground-truth
Active probing	Capabilities of listening services	Medium	Non-listening and internal-only services	External posture census
Certificate / key-store	Certificates, keys, signature algorithms	High	Anything outside the PKI	The 2031 signature deadline

The table names each surface's blind spot. Understanding why those blind spots exist -- and why they are not gaps a future release will quietly close -- means looking at how a scanner actually finds cryptography, because on the two hardest surfaces the detection mechanism and the blind spot turn out to be one fact seen from two sides.

Static source analysis lifts a library call to a normalized identity and its OID. A source scanner does not understand cryptography; it recognizes calls into catalogued cryptographic-library APIs and resolves each to a canonical algorithm.

CBOMkit-Hyperion and its Sonar Cryptography plugin walk the parsed syntax tree, spot a call into a known provider API -- Java's MessageDigest.getInstance("SHA-256"), or a pyca/cryptography constructor -- and map it to the algorithm, its variant, and its object identifier, the dotted-decimal name the registries use [@sonar-crypto] [@ibm-cbomkit-blog]. SHA-256 normalizes to the OID 2.16.840.1.101.3.4.2.1, in the NIST Computer Security Objects Register arc [@oidref-sha256].The SHA-256 OID 2.16.840.1.101.3.4.2.1 is the machine-mergeable identity a static scanner lifts an API call to: two tools that print "SHA-256" and "SHA256" collapse to one crypto-asset the moment both resolve to it [@oidref-sha256].

A globally unique, dotted-decimal name for an algorithm or other object, assigned under a registration hierarchy. SHA-256 is `2.16.840.1.101.3.4.2.1` in the NIST Computer Security Objects Register arc [@oidref-sha256]. A static scanner resolves a recognized API call to its OID, and because two tools that spell an algorithm differently agree the instant both resolve to the same OID, the OID is the machine-mergeable identity the CBOM roll-up is built on.

The OID is what lets two tools' findings merge into one graph, and it also fixes the surface's exact reach. Recognition runs against a fixed catalog of call patterns -- a decidable restriction -- so an algorithm name assembled at runtime, a call made through reflection, a language the ruleset does not cover, or a hand-rolled primitive presents no catalogued API to match and is simply never seen. The precision of static analysis and its blindness to dynamic names are the same design decision.

Binary and container analysis recovers a primitive with no symbols at all, from constants and from behavior. A stripped artifact still exposes two things a detector can key on. The first is its constants: block ciphers and hashes embed fixed, algorithm-specific tables -- an AES S-box, SHA round-constant tables, DES permutation tables -- and matching those known tables names the primitive with no function symbol present, the structural technique of Gröbert, Willems, and Holz in their 2011 RAID paper [@grobert-raid2011].

The second is its behavior: where the constants are absent or rewritten, the detector runs the code and tests the output for cryptographic signatures -- high Shannon entropy, and the avalanche effect, in which flipping one input bit flips roughly half the output bits, a property real ciphers have and ordinary arithmetic does not. Later work such as Hill and Bellekens' CryptoKnight names the same problem of recognizing primitives in compiled code [@hill-bellekens].

This mechanism is exactly why packing is a blind spot rather than a bug to be patched. Packing or white-box obfuscation removes or rewrites the very constant tables the structural matcher depends on, and can make an implementation indistinguishable by construction from non-cryptographic code -- the worst-case form of a limit the section after next proves is fundamental.

The behavioral fallback then meets a coverage wall: it can only judge the paths it actually executes, so cryptography on an unexecuted branch stays dark. The blind spot is not a defect in the tool; it is the shadow the detection mechanism casts.

flowchart LR subgraph STATIC["Static source lane"] A1["Recognize catalogued library API call"] --> A2["Resolve to algorithm and variant"] A2 --> A3["Look up object identifier, the OID"] end subgraph BINARY["Binary lane, no symbols"] B1["Match S-box and round-constant tables"] --> B3["Name the primitive"] B2["Run it, measure entropy and avalanche"] --> B3 end A3 --> OID["Crypto-asset keyed by OID"] B3 --> OID OID --> NODE["Mergeable CBOM node"]

Both lanes converge on the same object: a crypto-asset named by its OID, ready to merge with every other tool's findings. That shared identity is what makes the next layer possible.

The substrate layer rolls every surface up into a CycloneDX CBOM -- the graph from the previous section, now populated from five directions. (SPDX 3.0 is the parallel choice, and the next section weighs it.)

The prioritization layer turns the graph into a ranked queue using Mosca's inequality. You cannot migrate everything at once, so you order the work by exposure.

A triage rule attributed to Michele Mosca (IACR ePrint 2015/1075): begin migrating a system *now* if $x + y > z$, where $x$ is how long the data must stay confidential, $y$ is how long the migration will take, and $z$ is the time until a cryptographically relevant quantum computer exists [@mosca-eprint]. When the exposure window $x + y$ exceeds the time to a CRQC, harvest-now-decrypt-later already threatens that data, so waiting is a loss [@gri-mosca].

Applied over the CBOM graph, Mosca's inequality converts an inventory into a sorted migration queue, and it maps cleanly onto the executive order's split: confidentiality and key establishment, where $x$ can be decades, come due in 2030, while signatures, which cannot be forged retroactively, come due in 2031 [@eo14412]. The decision, per asset, looks like this.

flowchart TD X[Data shelf-life x] --> SUM["Exposure window x + y"] Y[Migration time y] --> SUM Z[Time to a CRQC z] --> D SUM --> D{"x + y exceeds z?"} D -->|yes| NOW[Migrate now, harvest-now-decrypt-later already applies] D -->|no| DEFER[Defer, but keep monitoring z]

The same rule expressed as code sorts a real inventory by how little slack it has left.

{` // Pedagogical, not production. Mosca's inequality: migrate now when x + y > z. const yearsToCRQC = 12; // z: uncertain estimate of time to a capable quantum computer. const assets = [ { name: "root-CA-signing", shelfLifeYears: 20, migrationYears: 3 }, { name: "payments-TLS", shelfLifeYears: 10, migrationYears: 2 }, { name: "internal-metrics", shelfLifeYears: 1, migrationYears: 1 }, { name: "archival-backups", shelfLifeYears: 25, migrationYears: 4 } ];

function triage(a) { const exposure = a.shelfLifeYears + a.migrationYears; // x + y return { name: a.name, exposure: exposure, slack: yearsToCRQC - exposure, // negative slack means already exposed migrateNow: exposure > yearsToCRQC }; }

const ranked = assets.map(triage).sort((p, q) => p.slack - q.slack); for (const r of ranked) { const flag = r.migrateNow ? "MIGRATE NOW" : "monitor"; console.log(r.name + " exposure=" + r.exposure + "y slack=" + r.slack + "y -> " + flag); } `}

The binding-policy layer is what makes the stack mandatory rather than aspirational. CISA's ACDI strategy defines the automated-discovery goal [@cisa-acdi]; NIST's SP 1800-38 practice guide, the deliverable of the NCCoE's Migration to Post-Quantum Cryptography project, supplies the reference architecture, as a preliminary draft [@sp1800-38-guide] [@sp1800-38-project]; and Executive Order 14412 attaches the dates and, within 270 days of signing, directs CISA to publish the "minimum elements for a cryptographic bill of materials" that "enable the automated assessment of the cryptographic assets" [@eo14412]. The policy layer literally names the substrate the rest of the stack produces.

NIST NCCoE's "Migration to Post-Quantum Cryptography" practice guide -- whose Volume B is the cryptographic-discovery volume -- is an initial public *preliminary draft*, and its own title page says so [@sp1800-38-guide] [@sp1800-38b-pdf]. Cite it for its discovery reference architecture, which is genuinely useful, but never as a finalized, normative NIST standard. Treating a draft as a final spec is one of the recurring errors in this space.

This stack works, up to a point. "Run every surface and roll it up" quietly assumes the surfaces can, together, see everything. They cannot, and no substrate choice changes that. Before confronting that ceiling, though, there is an honest comparison to make: CBOM is not the only way to inventory cryptography.

7. CBOM Is Not the Only Way to Inventory Cryptography

A claim that CBOM is the substrate has to survive its rivals. There are three real axes of competition, and on each, the honest answer is "it depends." Steelmanning the alternatives is not a detour from the thesis; it is how the thesis earns the word "substrate."

The schema choice: CycloneDX CBOM versus SPDX 3.0. SPDX is the other major machine-readable bill-of-materials standard, with an ISO/IEC 5962 lineage, and its 3.0 revision added a Security profile [@spdx-spec]. That profile is oriented toward vulnerability and VEX communication -- expressing whether a component is affected by a known vulnerability -- rather than toward modeling cryptographic assets in their own right [@spdx-security].VEX, the Vulnerability Exploitability eXchange, is a machine-readable statement about whether a given vulnerability actually affects a product. It answers "are we exploitable?", which is a different question from "what cryptography do we run?" -- which is why an inventory built around VEX is a different tool from one built around crypto-assets. CBOM, by contrast, ships purpose-built cryptographic-asset types and the implements versus uses edges that make the inventory a graph [@ibm-cbom].

The practical read: if you are inventorying cryptography to prioritize a migration, CBOM is the crypto-native choice, and it is the artifact Executive Order 14412 names by title [@eo14412]. If your organization is already standardized on SPDX and VEX workflows, SPDX 3.0 can carry crypto information at a coarser grain and keep you on one toolchain. Both, importantly, live in the same document as your SBOM, so this is a modeling choice, not a parallel-infrastructure choice.

Dimension	CycloneDX CBOM	SPDX 3.0
Steward	OWASP CycloneDX	Linux Foundation / SPDX (ISO/IEC 5962 lineage)
Crypto-asset modeling	Purpose-built `cryptographic-asset` types	Security profile, less crypto-specialized
Dependency semantics	`implements` versus `uses` edges	General relationships, VEX-oriented
Primary orientation	Cryptographic inventory	Vulnerability and VEX communication
Executive Order 14412 alignment	Named target artifact	Not named

The tooling choice: open versus commercial. The open reference implementation is CBOMkit, an IBM and Post-Quantum Cryptography Alliance suite whose modules cover source scanning (Hyperion), binary and container scanning (Theia), viewing (Coeus), compliance (Themis), and repository storage (Mnemosyne) [@cbomkit] [@ibm-cbomkit-blog]. Open tooling wins on transparency, on integrating into continuous integration, and on being the reference producer of the exact CBOM format the policy layer names.

It struggles outside its rule set -- languages or libraries it does not yet recognize -- and on completeness when it lacks build context. CBOMkit's own documentation is candid about the second limit: scanning without a full build "potentially reduces completeness and accuracy of the findings since some Java symbols may not be resolved" [@cbomkit].

The commercial alternative is the category of cryptographic-posture-management platforms: closed, multi-surface products that add correlation to business services and data flows. They win on breadth and on tying a raw finding to "which revenue-bearing service is this?" They cost money, keep their data models proprietary, and -- this is the part no budget fixes -- run into the exact same theoretical ceiling as the open tools.

Dimension	Open (CBOMkit)	Commercial cryptographic-posture management
Discovery surfaces	Source, plus binary and container; extensible	Multi-surface breadth out of the box
Output format	CycloneDX CBOM (the reference producer)	Often proprietary, typically exports CBOM
Correlation to business services	Limited	A primary selling point
Cost	Free and open	Licensed
Completeness ceiling	Bounded by rule set and build context	The same theoretical ceiling

The discovery-method choice is the five surfaces from the previous section, and the honest summary bears repeating: each is genuinely strong somewhere and genuinely blind somewhere else, and none is complete alone. Static analysis owns your source; binary analysis owns your firmware; passive monitoring owns live traffic; probing owns external posture; certificate scanning owns the PKI. The right answer is never "pick one." It is "run several and merge."

Note: There is no independent, peer-reviewed benchmark that ranks these schemas or tools by recall and precision on a shared corpus of real systems. The comparisons above are by design and coverage profile, not by measured performance numbers -- and any vendor deck that quotes a precise detection percentage is quoting itself. Treat coverage claims as architecture, not as evidence.

Every one of these choices trades coverage for cost, or specialization for breadth, and not one of them escapes a deeper problem they all share. Whatever schema you standardize on and whatever tools you buy or build, there is a hard limit on how complete your inventory can ever be -- and, with unsettling symmetry, a second hard limit on how much of your cryptography you can rotate at all.

8. Two Ceilings the Hard Problem Cannot Lift

Here is the uncomfortable core of the whole subject -- the most important idea in this guide after the thesis itself. Complete visibility into your cryptography is not merely expensive. It is impossible. And so, separately, is complete agility. Each verb has its own independent, provable ceiling, and the two ceilings have different shapes. Ask the budget question directly: with unlimited money and every tool on the market, could you reach 100 percent? No -- and the reasons you cannot are not the same for the two halves.

The SEE ceiling is undecidability. The question at the center of discovery is not the tidy one it first appears. What a scanner must answer, for arbitrary deployed code, is does this program use cryptographic primitive C somewhere inside it? -- think of a network daemon that happens to call AES while going about its ordinary work. That is the operative question, and it is provably unanswerable in general.

So is its stricter cousin, does this program compute C? -- is the program's entire input-output behavior the AES map itself? The two are undecidable for different reasons, and keeping them apart is the difference between a slogan and a proof.

Two distinct computability results cap automated discovery. Whether a program *computes* a given primitive -- whether its input-output function is, say, the AES map -- is a non-trivial semantic property of the function the program computes, so it is undecidable directly by Rice's theorem, which holds that every non-trivial property of the function a program computes is undecidable [@rice1953]. But the question discovery actually asks -- whether a program *uses* a primitive C internally while computing something else -- is not a property of the program's external function at all, because two programs with identical outputs can differ in whether they call C. Rice's theorem therefore does not apply directly; that case's undecidability follows instead from a reduction to the halting problem. Either way, no algorithm decides it for all programs.

The applied cryptography-detection literature reaches the same wall from the practical side, and it supplies the third leg of the attribution. Gröbert, Willems, and Holz, in their 2011 RAID paper on identifying cryptographic primitives in binary programs, show that binary crypto detection is fundamentally best-effort, and that no detector defeats arbitrary obfuscation: sufficiently transformed code can be made indistinguishable from non-cryptographic code [@grobert-raid2011].

Put the three arguments together -- Rice's theorem for computes C, the halting-problem reduction for uses C internally, and Gröbert for survives obfuscation -- and the conclusion is firm: 100 percent automated cryptographic discovery is not achievable in the general case.The attribution is deliberately three-part. Does P compute C? is undecidable by Rice's theorem [@rice1953]. The operative does P use C internally? is a halting-problem reduction, not Rice, because it is not a property of P's external function. And no detector defeats arbitrary obfuscation is Gröbert, Willems, and Holz at RAID 2011 [@grobert-raid2011]. Three different arguments, one conclusion. It is not a tooling gap that a better scanner will someday close. It is a computability limit.

This is the rigorous reason automated discovery must always be paired with human validation, and it instantiates in every messy corner of a real estate -- obfuscated and packed binaries, hand-rolled cryptography, dynamically loaded modules, firmware and operational-technology devices with decade-long lifetimes, and third-party or SaaS systems you simply cannot reach to scan.

The regulator agrees, in writing. As reported by Nextgov, CISA's guidance states that the agency "has not been able to confirm the full scope of cryptographic algorithm detection capabilities that will be available via automated cryptographic discovery tools," and that "the inventory process requires both manual data collection and the use of automated support" [@nextgov-cisa]. The body pushing hardest for automated discovery is explicit that automation alone will not get you to a complete inventory. Bounded coverage is not a vendor's excuse; it is the official operating assumption.

The ROTATE ceiling is irreversibility. Suppose, impossibly, you had perfect visibility. Some cryptography still cannot be rotated, because it was committed to the world in a form that cannot be recalled. RFC 7696 states the canonical case precisely: the digital signature on an intermediate certification authority certificate "is often expected to last decades, which hinders the transition away from a weak signature algorithm," and once a long-lived certificate is issued under a given algorithm, relying parties "cannot stop supporting it without invalidating all of the subordinate certificates" [@rfc7696].

The same irreversibility applies to every long-lived signature already emitted, to trust anchors and root stores embedded in devices, to firmware and hardware with parameters fixed at manufacture, and to protocols that shipped with no negotiation mechanism at all. These are not discovery failures. You can see them perfectly. The rotate half is simply, structurally impossible for them after the fact.

flowchart TD PQM[Post-quantum migration] --> SEE["SEE, run-time inventory"] PQM --> ROT["ROTATE, design-time agility"] SEE --> U["Ceiling, undecidability (halting reduction, Rice's theorem, RAID 2011)"] ROT --> I["Ceiling, irreversibility (RFC 7696 section 2.6)"] U --> UEX["Obfuscated binaries, hand-rolled crypto, SaaS opacity"] I --> IEX["Long-lived signatures, trust anchors, firmware"]

The undecidability ceiling is easy to feel with a five-line example. A naive static detector greps for a known cipher name. It catches the direct call and misses the identical algorithm the moment the name is assembled at runtime.

{` // Pedagogical illustration, not a proof and not production. // A naive static detector: it scans source for a known cipher literal. function naiveDetect(source) { const known = ["aes-128-gcm", "aes-256-gcm", "chacha20-poly1305"]; return known.filter(name => source.includes('"' + name + '"')); }

// Case 1: the algorithm is named directly. The detector sees it. const direct = 'const c = crypto.createCipheriv("aes-128-gcm", key, iv);';

// Case 2: the SAME algorithm, selected through a name built at runtime. const hidden = [ 'const parts = ["aes", "128", "gcm"];', 'const alg = parts.join("-");', 'const c = crypto.createCipheriv(alg, key, iv);' ].join(" ");

console.log("direct ->", naiveDetect(direct)); // ["aes-128-gcm"] found console.log("hidden ->", naiveDetect(hidden)); // [] missed `}

A real scanner is far cleverer than this, and a determined obfuscator is far cleverer still. The demo is not a proof of undecidability -- it is a picture of why the problem is undecidable: any fixed detector can be evaded by a program that constructs its cryptography in a way the detector does not model.

Note: A certificate scan is not a cryptographic inventory. Neither is a network scan. Each sees exactly one surface -- the PKI, or the wire -- and even the union of all five surfaces is provably bounded below complete coverage. Anyone who hands you a single-surface scan and calls it "our crypto inventory" has confused a slice for the whole.

So the attainable optimum is not a complete inventory and never was. It is a high-coverage, multi-surface, human-validated approximation whose residual incompleteness is acknowledged rather than hidden.You can push coverage upward asymptotically by adding surfaces and manual review, but never to a proven 100 percent. The mature deliverable is therefore bounded assurance -- a statement of how thoroughly you looked -- not a bare list that silently claims a completeness it cannot possibly guarantee. Coverage rises toward the ceiling; it never touches it.

If completeness is provably out of reach, then the goal cannot be a bare list that claims a coverage it cannot back. It has to be bounded assurance: a statement of which surfaces were scanned, with which tools, under which caveats. Building that -- along with everything else this young discipline has not finished -- is where the live research sits.

9. Where the Research and Standardization Are Still Live

The substrate exists and the deadline is fixed, but the discipline is young, and several load-bearing pieces are still under construction. The question that organizes the frontier is simple: what has to be solved before a CBOM can be trusted the way a mature SBOM is trusted today?

Trustworthy attestation of completeness is the flagship open problem. A CBOM asserts what a set of tools found. Nothing in it attests to what they missed -- and the previous section proved that what they miss can never be driven to zero. So a consumer of your CBOM needs something more honest than a list: bounded assurance, a signed statement of how far the inventory was actually pushed.

Concretely, a standard completeness-attestation profile would pin down four minimum elements: surface coverage (which of the five discovery surfaces were actually run against this target, and which were not); tools and versions (which discovery tools, at which versions and rule packs, since a surface's recall is bounded by the specific catalog it matches against); coverage and exclusion caveats (unscanned repositories, un-executed binary paths, unsupported languages, unreachable air-gapped or SaaS systems, the scanned-without-build-context case); and residual manual-validation scope (what a human reviewed, and what still awaits review).

The striking part is that the plumbing to carry all four already ships. CycloneDX Attestations (CDXA) landed in the same v1.6 line as CBOM, providing machine-readable "attestations to the veracity and completeness of those claims" [@owasp-cdx16] [@cdx-attestations].

Its object model maps onto the profile almost one-to-one: a top-level declarations object whose targets name the CBOM the claim is about; claims that each carry a predicate (for example, "all five surfaces scanned for target T"), its reasoning, linked evidence, and -- decisively -- counterEvidence, the schema's native field for what undercuts the claim, which is exactly where the blind spots the last section says can never be zero would be recorded; evidence items with created and expires timestamps, which also give an inventory's assurance an explicit shelf-life; and assessors carrying a thirdParty boolean that separates self-assessment from an independent audit, the whole declaration closed with an affirmation and an enveloped signature [@cdx-16-json].CDXA already carries completeness claims: claims.counterEvidence records what undercuts a claim, and evidence.expires gives the assurance a shelf-life [@cdx-16-json]. So the gap is a missing standard profile -- an agreed catalog of which claims a CBOM must assert -- not missing plumbing.

So the gap is not missing machinery; it is a missing standard profile -- an agreed, named set of claims a CBOM must assert to count as completeness-attested -- plus the absence of any shared, peer-reviewed benchmark against which a tool's recall and precision could be measured.The absence of a public discovery benchmark is why no honest vendor can quote you a real recall number. There is no shared corpus of representative systems with a known ground-truth inventory to measure against, so "we detect 98 percent of cryptography" is, at present, an unfalsifiable claim rather than a measured result.

Note: The most consequential unsolved problem in cryptographic inventory is not building a more powerful scanner. It is being able to state, verifiably, how thorough a given inventory is. Bounded assurance -- an honest account of coverage and its gaps -- is worth more to a downstream consumer than a longer list that silently overclaims what it saw. Attestation is the direct answer to the undecidability ceiling.

Four more problems are visibly in motion. Schema convergence: ACDI tools still emit tool-specific shapes, and CBOM and SPDX 3.0 coexist with no agreed crosswalk between their cryptographic representations [@ibm-cbom] [@spdx-spec]. A real crosswalk is not a field-rename -- it has to preserve crypto-asset identity, the family-versus-variant distinction, and the dependency semantics, so that CycloneDX's provides and dependsOn edges are not flattened into a mapping that collapses "this library contains X" into "this application uses X" [@cdx-16-json].

Continuous versus point-in-time inventory: a CBOM is stale the instant code ships, a certificate rotates, or traffic shifts; continuous inventory is practical for source and network surfaces and much harder for binary, firmware, and SaaS, so most inventories today are snapshots that begin aging immediately.

Correlation to business context: "AES-128-GCM at file X, line 51" does not tell you which service depends on it, which data it protects, or how long that data must stay secret -- yet that is precisely the input $x$ and the business priority that Mosca's inequality needs, so the gap between a technical finding and a risk decision is still bridged by humans.

Supply-chain propagation: most of an application's cryptography lives in its transitive dependencies, and while the data model supports composition -- via BOM-Link references between documents, enveloped signatures for provenance, and merge and de-duplication keyed on a stable identity such as OID plus package URL plus bom-ref -- the practice of publishing, signing, and merging upstream CBOMs the way SBOMs are beginning to flow is still nascent [@cdx-16-json].

And one problem loops straight back to the theory. Signature- and rule-based detectors recognize only cryptography they already have a rule for. Early post-quantum hybrids, experimental constructions, and hand-rolled primitives evade the catalog -- which is the undecidability ceiling of the previous section wearing everyday clothes [@grobert-raid2011]. Taken together, these open problems share a theme: the model for cryptography is settled, and the practices that make the model trustworthy, current, and composable are still being written.

None of this is a reason to wait, because the deadline will not. The research frontier and the compliance clock run in parallel, which means the practitioner's job is not to wait for the discipline to mature. It is to build the best inventory achievable now, bound it honestly, and improve it continuously. Here is how to start this quarter.

10. Doing It This Quarter

Strip away the theory and the policy, and a concrete, deadline-aware workflow remains -- one any team on the 2030 hook can start now. Five steps, each tied to one of the two verbs.

Step 1 -- Build agility in (ROTATE, forward). For everything you build from here on, apply the RFC 7696 patterns: put an indirection layer between your application and its cryptography, use registered algorithm identifiers, hardcode no primitives, and keep your mandatory-to-implement set in a companion configuration so it can change without a rebuild [@rfc7696]. Done well, the eventual post-quantum swap becomes a configuration change rather than a re-architecture. This step does not touch your legacy estate -- it stops that estate from growing.

Step 2 -- Run multi-surface discovery (SEE). Not one tool. A mix, matched to the surfaces from earlier: a static scan of owned source in continuous integration with CBOMkit-Hyperion and its Sonar Cryptography plugin [@sonar-crypto] [@ibm-cbomkit-blog]; a binary and container scan with CBOMkit-Theia for third-party artifacts and firmware [@cbomkit]; passive network monitoring for live ground-truth; active probing for an external capability census; and certificate and key-store scanning first if you are triaging the 2031 signature deadline. Then budget a permanent manual-validation line item for the residual the tools cannot reach -- because, as established, that residual never reaches zero [@nextgov-cisa].

Step 3 -- Emit a CBOM (SEE, substrate). Roll the merged findings into a CycloneDX CBOM of the current line -- CBOM was introduced in v1.6 and carried into v1.7 -- validate it, and store it as an artifact right next to your SBOM [@owasp-cdx16] [@cdx-spec-17]. Version it over time so you can diff this quarter against last, and keep the history in a repository such as CBOMkit-Mnemosyne [@cbomkit].

Step 4 -- Prioritize (SEE to decision). Run Mosca's inequality over the graph. Rank by harvest-now-decrypt-later exposure and timing, $x + y > z$, and map the result onto the mandated dates: confidentiality and key establishment toward December 31, 2030, signatures toward December 31, 2031 [@gri-mosca] [@eo14412]. The output is a queue, not a wish list.

Step 5 -- Migrate to algorithms that already ship (ROTATE, execute). The endpoints of the queue are the subject of the companion posts in this series: ML-KEM arriving in a pip install, ML-KEM and ML-DSA in Windows SChannel and SymCrypt, and the twenty-year SChannel algorithm-agility story that shows the rotate half working at scale in one real TLS stack. The replacement primitives are finished and shipping -- FIPS 203, 204, and 205 since August 2024 [@fips203] [@pyca-changelog] [@ms-pqc-windows]. The entire stack above exists to produce the prioritized list those endpoints execute against.

flowchart TD A[Build agility into new code] --> B[Run multi-surface discovery] B --> C[Emit and validate a CycloneDX CBOM] C --> D{"x + y exceeds z?"} D -->|yes| E[Migrate now to shipping PQC algorithms] D -->|no| F[Queue and keep monitoring z] E --> G[Re-scan and version the CBOM] F --> G

Step	Method	Effort	Best suited for
Build agility in	RFC 7696 patterns in new code	Design-time, low ongoing	Greenfield and active codebases
Discover owned source	Static scan in CI (Hyperion / Sonar)	Low, continuous	Code you wrote
Discover third-party and firmware	Binary and container scan (Theia)	Medium	Artifacts you did not build
Discover live traffic	Passive network plus active probing	Medium	Ground-truth and external posture
Discover the PKI	Certificate and key-store scan	Low	The 2031 signature deadline
Prioritize	Mosca's inequality over the CBOM	Low	Ordering the migration queue
Migrate	Adopt shipping PQC (companion posts)	High	The assets the queue surfaces first

Note: If you remember a single operational rule, make it this: run a mix of surfaces, roll the results up into one CBOM, and validate the residual by hand. Every common failure in this space is a shortcut around that rule -- trusting one tool, one surface, or one snapshot.

The pitfalls are predictable, and each is a shortcut past something earlier in this guide. Scanning Java source without building it leaves symbols unresolved and findings incomplete, exactly as CBOMkit's documentation warns [@cbomkit]. Treating a certificate scan, or a network scan, as a finished inventory mistakes one surface for the estate. Collapsing family into variant -- recording "AES" instead of "AES-128-GCM" -- throws away the property that makes a finding actionable [@ibm-cbom]. Losing the implements versus uses distinction flattens the graph back into a list. And citing a stale CycloneDX version number invites a reviewer to distrust the rest.

A concrete starting move, before any of the harder surfaces: build one representative service, run a static CBOM scan of it in your CI pipeline with CBOMkit-Hyperion and the Sonar Cryptography plugin, and commit the resulting CycloneDX CBOM next to that service's SBOM [@sonar-crypto]. You will have a real, validated, versioned crypto inventory for one service by Friday -- and a template for the next hundred. Start where you have source and build context, because that is the surface where the tools are strongest.

Do all five steps and you have converted an impossible-sounding mandate into a bounded, prioritized, machine-actionable program -- and, in the process, confronted the one truth the whole field converged on. That truth is worth stating plainly, alongside the misconceptions that keep tripping teams up.

11. Misconceptions, Questions, and the One Truth

Almost every misconception in this space is a shortcut past one of the two verbs. "Post-quantum cryptography is the hard part" skips the SEE half -- the new algorithms are finished and shipping [@fips203] [@pyca-changelog] [@ms-pqc-windows]; discovery is the bottleneck. "CBOM is a separate schema from CycloneDX or the SBOM" misreads the substrate -- it is the v1.6 extension of the same document, and can live in the same file [@owasp-cdx16].

"SP 1800-38 is a finalized NIST standard" over-reads a preliminary draft [@sp1800-38-guide]. "Executive Order 14412 binds everyone" over-reads its scope -- federal agencies and covered contractors are mandated, critical infrastructure is encouraged, and EO 14412 is not EO 14413 [@eo14412]. "We can just scan the network" trusts one surface for the whole estate. And "a spreadsheet of our certificates is a cryptographic inventory" mistakes a stale, single-surface document for a machine-actionable, dependency-aware graph. Each error is a verb half-done.

No. FIPS 203, 204, and 205 were standardized in August 2024 [@fips203], and ML-KEM is now a `pip install` away and built into Windows [@pyca-changelog] [@ms-pqc-windows]. The binding constraint is discovering where the quantum-vulnerable algorithms already live across your estate. You cannot rotate what you cannot see. No. The Cryptography Bill of Materials is an extension of the same CycloneDX BOM document, introduced in v1.6 in April 2024 [@owasp-cdx16]. A CBOM can live in the same file as your SBOM, produced and consumed by the same tools [@ibm-cbom]. No. It is a preliminary, initial public draft NCCoE practice guide [@sp1800-38-guide]. Use it for its discovery reference architecture, which is genuinely useful, but state its draft status rather than citing it as a finalized standard. Only if you are a federal agency or a covered federal contractor; critical infrastructure operators are encouraged, not mandated [@eo14412]. Note also that EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks") is not EO 14413, a separate order on quantum innovation [@eo14412]. No. Passive and active network discovery see only cryptography that transits an observed link. They miss data at rest, embedded and operational-technology devices, internal-only applications, and SaaS you cannot reach. A network scan is one surface, not an inventory. Not a maintainable one. It is stale the moment it is written, it is not machine-actionable, it cannot be prioritized as a graph, and a certificate list sees only the public-key infrastructure surface. A CycloneDX CBOM is the machine-actionable substitute [@ibm-cbom]. No, and not because the tools are immature. Complete automated cryptographic discovery is undecidable in general: the operative question -- whether a program *uses* a primitive internally -- reduces to the halting problem, and Gröbert, Willems, and Holz (RAID 2011) show no detector defeats arbitrary obfuscation. So manual validation is a permanent complement, and the honest deliverable is bounded assurance [@grobert-raid2011] [@nextgov-cisa].

So here is the whole argument in one breath. Post-quantum migration is two verbs, not one. You must be able to ROTATE your cryptography, and you must be able to SEE where it all lives. The replacement algorithms are finished and shipping -- FIPS 203, 204, and 205 since August 2024 [@fips203], a pip install away and built into Windows [@pyca-changelog] [@ms-pqc-windows] -- yet the 2030 and 2031 deadlines are hard [@eo14412]. The field completed the ROTATE lineage decades before it closed the SEE lineage: rigidity gave way to negotiation, negotiation hardened into RFC 7696, and RFC 7696 was restated as national risk-management guidance in NIST CSWP 39 [@rfc7696] [@cswp39] -- while the inventory half sat unsolved through the spreadsheet era until a 2022 mandate forced it open, automated discovery gave it scale, and CBOM finally gave it a data model [@omb-m2302] [@ibm-cbom]. CBOM is where the two verbs meet: cryptography modeled as a first-class, machine-readable, dependency-aware asset, now named in federal law [@eo14412].

And the two ceilings keep the claim honest. Undecidability caps what you can see; irreversibility caps what you can rotate [@grobert-raid2011] [@rfc7696]. So the mature goal is never a bare 100 percent. It is bounded assurance for the seeing, and structural honesty about the un-rotatable. The algorithms, it turns out, were the easy part.

The algorithms were the easy part. You cannot rotate what you cannot see.

The Thirty-Year Migration Ships in a pip install: How Post-Quantum Cryptography Crossed from Standard to Shipping Code

noreply@paragmali.com (Parag Mali) — Tue, 30 Jun 2026 00:00:00 GMT

Post-quantum cryptography spent thirty years crossing from theory (Shor, 1994) to lattice math (Learning With Errors, 2005) to NIST standards (FIPS 203 and 204, 2024) -- and in 2026 it finally reached shipping code. On May 4, 2026, `pyca/cryptography` v48.0.0 put ML-KEM and ML-DSA into the default `pip` wheels, roughly seven weeks *before* Executive Order 14412 set the federal deadlines. But shipping the primitive is necessary, not sufficient: ML-KEM and ML-DSA are one to two orders of magnitude larger than the X25519 and Ed25519 they replace, and a key-encapsulation mechanism is not a drop-in for Diffie-Hellman. The remaining work -- integrating these into TLS, SSH, X.509, and package signing -- is the real last mile, because a primitive is not a protocol.

1. The Last Mile Is a `pip install`

On May 4, 2026, the migration Peter Shor set in motion thirty-two years earlier quietly crossed its last mile -- not in a standards body, not at a White House signing, but in a routine pip install. That day, pyca/cryptography v48.0.0 added ML-KEM and ML-DSA to the default wheels that sit beneath Ansible, Certbot, and a package downloaded more than a billion times a month [@pyca-changelog] [@tob-2026]. Seven weeks later, an executive order would set the federal deadlines for exactly this migration [@eo14412] -- but the code had already arrived.

That ordering is the whole story, and it is the opposite of the one most people tell. The usual narrative treats the 2024 NIST standards or the 2026 executive order as the moment post-quantum cryptography "became real." The dated record says otherwise: the primitive shipped first, in a version-bump nobody outside a handful of maintainers noticed.

Key idea: The pip install beat the policy. pyca/cryptography v48.0.0 shipped ML-KEM and ML-DSA on May 4, 2026; Executive Order 14412 set the federal deadlines on June 22, 2026 -- forty-nine days later. The shipping code was already in a billion-download-a-month wheel before the mandate existed [@pyca-changelog] [@eo14412].

Trail of Bits, which wrote much of the code that made this possible, put the milestone plainly.

Post-quantum cryptography is now one `pip-install` away. -- Trail of Bits, on the arrival of ML-KEM and ML-DSA in `pyca/cryptography` [@tob-2026]

This is a strange kind of anticlimax. A threat that dooms RSA, Diffie-Hellman, and elliptic-curve cryptography was described in 1994. It took a decade to find math that plausibly resists it, another decade for that math to become efficient enough to deploy, a six-year public competition to pick winners, and a formal standardization in 2024. And then the thing that actually put quantum-resistant cryptography in front of most working programmers was a distribution change: the same primitives, previously reachable only in specialist builds, landing in the wheel everyone already installs.

timeline title From a quantum threat to shipping code 1994 : Shor's algorithm breaks RSA, DH, and ECC in theory 1996 : Ajtai proves worst-case lattice hardness 2005 : Regev defines Learning With Errors 2012 : Module-LWE yields kilobyte-scale keys 2016 : NIST opens its post-quantum competition 2022 : NIST selects Kyber, Dilithium, Falcon, and SPHINCS+ 2024 : FIPS 203, 204, and 205 finalized on August 13 May 2026 : pyca cryptography v48 ships ML-KEM and ML-DSA Jun 2026 : Executive Order 14412 sets the federal deadlines

There is a catch, and it is the reason this article exists. Shipping the primitive is the easy part. ML-KEM and ML-DSA are not smaller, faster, tidier versions of the algorithms they replace; they are dramatically larger, they have a different shape, and they violate assumptions that thousands of protocols and buffers quietly encoded around 32-byte keys and 64-byte signatures. A standardized, pip-installable primitive is a genuine milestone. It is also not a working TLS handshake, a signed X.509 certificate, or a package-signing scheme. In a phrase this article will earn: a primitive is not a protocol.

So here is the question. If the primitive is a pip install away, why is the migration still a thirty-year project -- and how did the code beat the executive order?

2. The Threat That Started a Thirty-Year Clock

In 1994, Peter Shor showed that a sufficiently large quantum computer could factor integers and compute discrete logarithms in polynomial time [@shor1994]. That one result quietly condemned almost every public-key system in deployment. RSA rests on the hardness of factoring; Diffie-Hellman and elliptic-curve cryptography rest on discrete logarithms. Shor's algorithm breaks all three at once. It is not a faster attack that a bigger key can outrun -- it is a correctness failure of the assumption those systems are built on.Shor's 1994 paper is cited under two titles: the FOCS conference version, "Algorithms for Quantum Computation: Discrete Logarithms and Factoring," and the expanded arXiv and SIAM version, "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer" [@shor1994].

Classical cryptographic algorithms -- ones that run on ordinary computers -- designed to remain secure even against an adversary with a large-scale quantum computer. PQC is not quantum cryptography: it uses no quantum hardware. It replaces the *hard problems* (factoring, discrete log) that quantum computers solve with problems (such as finding short vectors in a lattice) that they are not known to solve efficiently. A 1994 quantum algorithm that factors integers and solves the discrete-logarithm problem in polynomial time. Its existence means that RSA, Diffie-Hellman, and elliptic-curve cryptography are all breakable by a large enough quantum computer, which is the entire reason the post-quantum migration exists [@shor1994].

Why symmetric cryptography survives

The quantum threat is asymmetric in an important way: it targets public-key cryptography, not the symmetric ciphers and hashes underneath it. The relevant quantum tool for symmetric keys is Grover's algorithm, which gives only a quadratic speedup on a brute-force search [@grover1996]. The folk summary is that Grover halves the security level, turning a 128-bit key into 64 bits.That halving is a naive query-count bound, not a real cost. A depth-limited quantum search is far more expensive: NIST's own evaluation criteria peg the effective quantum cost of breaking AES-128 near $2^{170}/\text{MAXDEPTH}$ rather than $2^{64}$ [@nist-cfp-eval], and Grassl and colleagues give the concrete Grover-on-AES resource estimates behind that figure [@grassl-2016]. Because Grover parallelizes only as the square root of the number of machines, serial depth dominates [@zalka-1999]. Even AES-128 keeps a wide margin; moving to AES-256 is a precaution, not a rescue. The practical upshot is clean: symmetric keys need at most a modest bump, so the migration is overwhelmingly a public-key story [@nist-cfp-eval] [@grassl-2016].

Why the migration cannot wait for the hardware

Here is the part that surprises people. You do not need a working quantum computer today for the threat to be operational today. An adversary can record encrypted traffic now and simply store it, then decrypt it years later once a cryptographically relevant quantum computer exists. Anything that must stay confidential past the arrival of that machine is already exposed.

An attack strategy in which an adversary captures and stores encrypted data today, betting on decrypting it in the future once quantum computers can break the key exchange that protected it. HNDL makes the quantum threat a *present-day* problem for any data with a long confidentiality lifetime, even though the quantum computer does not yet exist.

Thirty-two years after Shor, Executive Order 14412 opens by restating exactly this rationale as national-security fact [@eo14412].

Ongoing cyber activity against our Nation also presents the risk of adversaries collecting United States information now, and decrypting it later once large-scale quantum computers are operational. -- Executive Order 14412 [@eo14412] Because HNDL is the operative threat, the near-term reason to adopt post-quantum key establishment is not that a quantum computer is imminent -- it is that *today's* confidential traffic has a shelf life that outlasts the hardware timeline. Trail of Bits made the point sharply in a 2024 essay arguing that quantum resistance is not even the main benefit of post-quantum cryptography: the discipline of a clean migration and modern, agile primitives pays off regardless of when the machine arrives [@tob-2024] [@eo14412].

The field even got its name in this period. The PQCrypto workshop series began gathering researchers around the problem in 2006, and the 2009 Springer volume Post-Quantum Cryptography framed the multi-decade replacement thesis that the community has been executing ever since [@pqcrypto-workshop] [@pqc-book-2009].The coinage of the phrase "post-quantum cryptography" is usually attributed to Daniel J. Bernstein around 2003 to 2006, but that attribution is folk knowledge; the firm anchors are the 2006 workshop and the 2009 book [@pqcrypto-workshop] [@pqc-book-2009].

If factoring and discrete log are dead in the quantum model, the obvious next question is what we build on instead. Several candidate hard problems were on the table. Only one of them turned into the workhorse behind the algorithms that just shipped in your pip cache -- and understanding why the others lost is the fastest way to understand what makes the winner trustworthy.

3. The Math That Survives Quantum

After Shor, cryptographers had a menu of hard problems that quantum computers were not known to crack: hash functions, error-correcting codes, systems of multivariate quadratic equations, isogenies between elliptic curves, and lattices. Four of the five had a disqualifying flaw for a general-purpose default. One did not.

Hash-based signatures are the most conservative option on the menu, because their only assumption is that a hash function behaves like a hash function. Merkle proposed the idea in 1979 [@rfc8391], and it survives today as SLH-DSA. But hash-based schemes sign; they cannot establish a key, so they can never be the whole answer. The early stateful forms carry a vicious footgun -- reuse a one-time key by losing track of internal state and you leak the private key [@sp800-208] -- and the stateless successor, SPHINCS+, buys safety with large, slow signatures [@sphincs-plus] [@tob-2026].

Code-based encryption has an even longer unbroken record. McEliece's 1978 cryptosystem hides a structured error-correcting code as a random-looking matrix; half a century and many attack papers later, including quantum ones, its security has held [@classic-mceliece]. Its ciphertexts are tiny. The problem is the public key: Classic McEliece keys run from roughly 261 KB to more than 1 MB [@classic-mceliece]. That is fine for a niche, fatal for a default that has to fit inside a TLS handshake.

Multivariate and isogeny schemes both looked promising and both broke during the standardization era -- a story worth its own section (Section 4).

That leaves lattices, and the reason they won is a two-step story of beauty followed by engineering.

Step one: beauty (worst-case hardness)

In 1996, Miklos Ajtai proved something remarkable: you can build cryptographic instances whose average-case hardness is guaranteed by the worst-case hardness of a lattice problem [@ajtai1996]. In most of cryptography you hope your random instance is hard; Ajtai showed a family where a random instance is provably as hard as the hardest instance in the class. In 2005, Oded Regev turned this into a usable assumption -- Learning With Errors -- complete with a quantum worst-case-to-average-case reduction and a working public-key encryption scheme [@regev-lwe].

The problem of recovering a secret vector $s$ given many noisy linear equations $b = As + e$, where $A$ is public and random and $e$ is small random noise. Without the noise this is trivial linear algebra; with it, recovering $s$ is believed hard even for quantum computers. LWE is the assumption underneath ML-KEM and ML-DSA [@regev-lwe].

LWE is beautiful, and in its raw form it is unshippable. A plain-LWE public key is essentially a big random matrix, so its size grows like $O(n^2)$ in the security parameter -- megabytes, not kilobytes. Beauty was not enough.

Step two: engineering (algebraic structure)

The fix was to give LWE algebraic structure. Ring-LWE (2010) works over a ring of polynomials instead of a flat vector space, collapsing the quadratic overhead and letting the Number-Theoretic Transform multiply polynomials quickly; its own authors describe removing LWE's "inherent quadratic overhead" [@ring-lwe]. Module-LWE (2012) generalized this to short vectors of ring elements, giving designers a tunable dial between raw LWE and full Ring-LWE [@module-lwe]. The size effect is the whole game: from $O(n^2)$ down to $O(n)$, from megabytes to kilobytes. That single step is what turned lattice cryptography from a theorist's toy into the deployable engine behind ML-KEM and ML-DSA.

A middle-ground version of LWE defined over modules -- short vectors whose entries are elements of a polynomial ring. It sits between unstructured LWE (large, most conservative) and Ring-LWE (compact, most structured), letting a scheme trade size against how much algebraic structure it assumes. Module-LWE is the specific hard problem under CRYSTALS-Kyber and CRYSTALS-Dilithium, standardized as ML-KEM and ML-DSA [@module-lwe]. flowchart TD A["Classical public key (RSA, DH, ECC)"] -->|Shor 1994 breaks all three| B["Need a quantum-hard problem"] B --> C["Hash-based (SLH-DSA): conservative backstop, large and slow"] B --> D["Code-based (McEliece): unbroken, but keys near 1 MB"] B --> E["Multivariate (Rainbow): broken in a weekend, 2022"] B --> F["Isogeny (SIKE): broken in about ten minutes, 2022"] B --> G["Lattice (LWE): worst-case hardness, but O(n^2) keys"] G --> H["Ring-LWE and Module-LWE: O(n) kilobyte keys"] H --> I["ML-KEM and ML-DSA: the deployed workhorse"]

There is an honest catch in step two, and it matters for the rest of this article. Adding structure is what buys the kilobyte keys, but structure is also extra assumption.Is the algebraic structure "free"? The worst-case reduction for Ring-LWE and Module-LWE runs to ideal or module lattices -- a smaller, more special class than general lattices [@peikert-2015]. No known attack cashes that extra structure in at the standardized parameters; the best attack remains generic lattice sieving at $2^{0.292\beta}$, the same cost as for unstructured LWE [@bdgl16]. Module-LWE deliberately dilutes the structure, as its own built-in hedge [@module-lwe]. But "the structure is free" is a conjecture, not a theorem -- which is exactly why the standardized portfolio keeps a hash-only backstop, SLH-DSA, that would survive even if that conjecture failed [@fips205]. The community's answer to that residual doubt is not to pretend it away; it is to keep a scheme from a completely different family in reserve. Hold that thought -- it is the reason the eventual standard is a portfolio, not a single winner.

Kilobyte-scale lattice schemes existed by 2018 [@kyber] [@dilithium]. So why did it take a six-year global tournament to decide which ones to trust?

4. From a Problem to a Portfolio

NIST did not crown one algorithm. Starting in 2016, it ran an open, public, break-or-defend competition -- publish your candidate, publish your attacks, let years of adversarial scrutiny do the filtering [@nist-pqc-project]. Google had already run a taste of the future in 2016, wiring an experimental post-quantum key exchange called CECPQ1 into Chrome and its front ends to see what breaks at internet scale, then retiring it precisely because it was not yet standardized [@google-cecpq]. The lesson was clear: experiments are cheap, but a default needs a standard behind it.

On July 5, 2022, NIST announced its first selections: CRYSTALS-Kyber for key establishment, and CRYSTALS-Dilithium, Falcon, and SPHINCS+ for signatures [@nist-2022]. Three of the four are lattice schemes; the fourth, SPHINCS+, is hash-based. NIST named Dilithium the primary signature, Falcon the option for applications that need smaller signatures, and SPHINCS+ the backup built on "a different math approach" [@nist-2022]. That portfolio is a deliberate hedge: a compact, versatile lattice family as the workhorse, plus a signature scheme whose security rests on nothing but hash functions.

The tournament produced casualties

The hedge was not paranoia. It was a lesson the competition taught in real time.

The isogeny KEM SIKE was one of the most elegant candidates, with the smallest keys of anything in the field, and it advanced to the fourth round. Then, in 2022, Wouter Castryck and Thomas Decru broke it -- not with a quantum computer, but on a laptop.Castryck and Decru recovered the SIKE private key by exploiting the torsion-point images the protocol reveals, via Kani's reducibility criterion. Their Magma implementation "breaks SIKEp434, which aims at security level 1, in about ten minutes on a single core" [@sike-break]. A years-vetted, fourth-round candidate fell to one new mathematical idea. Around the same time, Ward Beullens broke the multivariate signature scheme Rainbow, a third-round finalist, recovering its secret key in an average of 53 hours -- one weekend -- on a standard laptop [@rainbow-break].

SIKE and Rainbow are the empirical argument for diversity. Both were serious, years-scrutinized candidates; both collapsed to a single new attack during standardization [@sike-break] [@rainbow-break]. If a finalist can fall that fast, betting the entire internet on one hard problem is reckless. That is why NIST standardized a small, deliberately diverse set and kept a hash-only backstop from a different family -- the same reasoning that keeps SLH-DSA in the portfolio even though ML-DSA is faster and smaller.

Even NTRU, one of the oldest and most compact lattice schemes (Hoffstein, Pipher, and Silverman, 1996), did not make the cut. It was a finalist, but its security rested on a more heuristic argument than the CRYSTALS schemes' cleaner reductions, and it carried a history of patent encumbrance that only lapsed in 2017 [@ntru]. NIST's rationale was multi-factor, but the outcome was telling: given two workable lattice families, the committee preferred the one with the tidier hardness story and no intellectual-property baggage.

flowchart LR subgraph LAT["Lattice family (selected)"] L1["Ring-LWE and Module-LWE"] --> L2["Kyber and Dilithium selected 2022"] end subgraph HEDGE["Conservative hedge"] H1["Hash-based SPHINCS+ selected as backstop"] end subgraph DEAD["Broken during standardization"] D1["Isogeny SIKE broken 2022"] D2["Multivariate Rainbow broken 2022"] end N["NTRU finalist, not selected"] -.-> L2

The following table condenses the generational story: which ideas advanced, which were demoted to a niche or a backstop, and which broke outright.

Approach	Since	Core idea	Status
RSA / DH / ECC	1976	Factoring and discrete log	Quantum-doomed (Shor) [@shor1994]
Hash-based (Merkle to SLH-DSA)	1979	One-time keys over a hash tree	Active backstop, signatures only [@sp800-208] [@sphincs-plus]
Code-based (Classic McEliece)	1978	Hide a Goppa code as a random matrix	Niche: unbroken but ~1 MB keys [@classic-mceliece]
Lattice theory (Ajtai; Regev/LWE)	1996 / 2005	Worst-case-hard lattices; LWE	Foundation, but O(n^2) raw sizes [@ajtai1996] [@regev-lwe]
NTRU	1996	Ring-based lattice encryption	Superseded finalist, not selected [@ntru]
Ring/Module-LWE to ML-KEM/ML-DSA	2012 / 2024	Structured lattices, NTT	Standardized workhorse [@module-lwe] [@fips204]
Isogeny SIDH/SIKE	2011	Supersingular isogeny walks	Broken in about ten minutes, 2022 [@sike-break]
Multivariate Rainbow	2005	Multivariate quadratic systems	Broken in a weekend, 2022 [@rainbow-break]
Falcon / FN-DSA	2022	NTRU lattice with Gaussian sampling	Standard pending as FIPS 206 [@nist-2022]

A short list of winning algorithms is still just math on paper. What turns "we chose Kyber" into something a whole software supply chain can build on?

5. Why the Rename Mattered

On August 13, 2024, NIST finalized three standards. Kyber became ML-KEM (FIPS 203), Dilithium became ML-DSA (FIPS 204), and SPHINCS+ became SLH-DSA (FIPS 205) [@fips203] [@fips204] [@fips205]. It is tempting to read this as bureaucratic relabeling. It is the opposite: the rename is the moment the algorithms stopped being research artifacts and became a contract.

A Federal Information Processing Standard: a document published by NIST that fixes exact parameter sets, byte-level encodings, and algorithm behavior so that independent implementations interoperate and can be validated against a common reference. A FIPS standard is a specification -- a shared, machine-checkable contract -- not a piece of software [@fips203].

The value of a FIPS document is that it pins down the boring, load-bearing details. A research paper can leave an encoding ambiguous or offer three parameter options; a standard says these parameter sets, these byte counts, this wire encoding, and nothing else. That is what lets a hardware team, a TLS library, and a Python wheel independently implement ML-KEM and have their outputs match to the byte.

Note: A common misconception is that the FIPS PDF ships the known-answer test vectors. It does not. The standard fixes the parameter sets and byte counts, but the validation vectors -- the inputs and expected outputs implementers check against -- are published and maintained through NIST's ACVP and CAVP validation program, in the usnistgov/ACVP-Server repository (folders such as ML-KEM-keyGen-FIPS203 and ML-DSA-sigGen-FIPS204), not inside the standard's text [@acvp-server]. The standard fixes the bytes; the validation program publishes the vectors.

The three standards divide the work cleanly.

The Module-Lattice-Based Key-Encapsulation Mechanism: the standardized key-establishment primitive, derived from CRYSTALS-Kyber, with security tied to Module-LWE. It comes in three parameter sets -- ML-KEM-512, ML-KEM-768, and ML-KEM-1024 -- in increasing order of security strength [@fips203]. The Module-Lattice-Based Digital Signature Algorithm: the standardized general-purpose signature, derived from CRYSTALS-Dilithium. It is a Fiat-Shamir-with-aborts lattice signature that samples from the uniform distribution -- a design the Dilithium team chose specifically because "Gaussian sampling is hard to implement securely and efficiently" [@fips204] [@dilithium].

SLH-DSA (FIPS 205) rounds out the set as the hash-only backstop -- slower and larger, but resting on assumptions no lattice attack can touch [@fips205]. Key establishment, everyday signatures, and a conservative signature hedge: three jobs, three standards, one portfolio.

Key idea: Standardization, not the algorithm, is what lets a whole software community move at once. The algorithm was ready in 2018; what a whole community of libraries, protocols, and hardware needs is a fixed set of byte counts and validated test vectors they can all target independently. FIPS 203 and 204 supplied exactly that -- and that is the "standard" pole of the crossing this article traces [@fips203] [@fips204] [@acvp-server].

But a standard is still only a specification. It does not compile, it does not ship in a wheel, and it does not integrate itself into a single protocol. FIPS 204 tells you that an ML-DSA-65 signature is exactly 3,309 bytes; it does not tell you what happens to the fifty protocols and hardware buffers that were quietly built around 64-byte signatures.

The standard fixes the byte counts. What happens when those byte counts are fifty times bigger than the ones every protocol was quietly built around?

6. Why the Numbers Break the Protocols

An Ed25519 signature is 64 bytes. Its post-quantum replacement, ML-DSA-65, is 3,309 bytes [@tob-2026] [@fips204]. Now multiply that by every place a protocol, a certificate format, a hardware buffer, or a database column quietly assumed 64.

This is the pivot of the whole article. The primitive is real, standardized, and about to be a pip install away -- and it does not fit where the old one did.

The size table

Role	Classical	Post-quantum	Public key	Wire output	Blow-up
Signature	Ed25519	ML-DSA-65	32 B to 1,952 B	64 B sig to 3,309 B sig	~61x key, ~52x sig
Key exchange	X25519	ML-KEM-768	32 B to 1,184 B	32 B shared to 1,088 B ciphertext	~37x key, ~34x wire

Those multipliers -- roughly 34x to 61x -- come straight from the Trail of Bits size tables and FIPS 204's Appendix B [@tob-2026] [@fips204].Private keys are not the problem. Both ML-DSA-65 and ML-KEM-768 can store their private keys compactly as 32-byte and 64-byte seeds, respectively [@tob-2026]. The pressure is entirely on the values that travel on the wire: public keys, signatures, and ciphertexts. Those are exactly the objects protocols frame with fixed-width length fields. The size story alone would be a migration headache. But size is only half of what breaks. The other half is shape.

A KEM is not a Diffie-Hellman

The instinct is to treat ML-KEM as "X25519, but bigger." It is not. X25519 is a Diffie-Hellman exchange: both parties publish a share, and both combine their own secret with the other's share to arrive at the same value. ML-KEM is a key-encapsulation mechanism, which has a different message shape entirely.

A key-establishment primitive with three operations. The receiver generates a keypair and publishes the public (encapsulation) key. A sender runs encapsulate on that public key, producing a fresh shared secret together with a ciphertext; the sender keeps the secret and transmits the ciphertext. The receiver runs decapsulate on the ciphertext to recover the same shared secret. Unlike Diffie-Hellman, only one side draws the secret, and there is no "combine my share with yours" step [@fips203].

Trail of Bits states the distinction directly: in a KEM "one party encapsulates a fresh shared secret to the receiver's public key, and the receiver decapsulates it," which is "fundamentally different from Diffie-Hellman" [@tob-2026]. The consequence for real systems is severe. A protocol that assumed the symmetric, two-share choreography of Diffie-Hellman cannot simply swap in ML-KEM; the message flow itself has to be redesigned, not merely re-parameterized.

sequenceDiagram participant A as Alice participant B as Bob Note over A,B: Diffie-Hellman, both sides contribute a share A->>B: public share A B->>A: public share B Note over A,B: each side combines to reach the same secret Note over A,B: ML-KEM, only one side encapsulates B->>A: publishes public key A->>B: ciphertext from encapsulate Note over A,B: Bob runs decapsulate to recover the same secret

The 4,096-byte wall

The abstract worry becomes concrete at a specific number. Move up one ML-DSA security level, from ML-DSA-65 to ML-DSA-87, and the signature grows from 3,309 bytes to 4,627 bytes [@fips204]. That crosses a boundary that a lot of hardware was built around.

Note: A Trusted Platform Module speaks a command protocol with a maximum command size that is commonly 4,096 bytes, and the protocol has no chunking -- a command either fits or it cannot be sent. ML-DSA-87's 4,627-byte signature does not fit; ML-DSA-65's 3,309-byte signature does. The catch is that 4,096 is a common value, not a universal constant: TPM 2.0 buffer sizes are implementation-defined and queried at runtime, and the TCG reference implementation is tighter still -- MAX_COMMAND_SIZE is defined as 4096-0x80, or 3,968 bytes, with a 1,024-byte input buffer [@tpm2-spec] [@mstpm-ref]. Either way, one extra security level silently crosses a fixed hardware boundary that nobody sized for kilobyte signatures [@fips204].

You can check the arithmetic yourself. The snippet below computes the blow-up ratios and tests ML-DSA-87's signature against both a 4,096-byte budget and the tighter 3,968-byte reference budget.

{` // verified byte counts: FIPS 204 Appendix B and the Trail of Bits size tables const ed25519 = { key: 32, sig: 64 }; const mldsa65 = { key: 1952, sig: 3309 }; const x25519 = 32; const mlkem768 = { key: 1184, ct: 1088 };

console.log("ML-DSA-65 signature is " + (mldsa65.sig / ed25519.sig).toFixed(0) + "x an Ed25519 signature"); console.log("ML-DSA-65 public key is " + (mldsa65.key / ed25519.key).toFixed(0) + "x an Ed25519 key"); console.log("ML-KEM-768 public key is " + (mlkem768.key / x25519).toFixed(0) + "x an X25519 key");

// the 4,096-byte wall: does one signature fit one TPM command? const COMMON_TPM = 4096; // a common maximum command size const TCG_REF = 4096 - 0x80; // TCG reference MAX_COMMAND_SIZE = 3968 const mldsa87sig = 4627; // ML-DSA-87 signature

const fits = (sig, budget) => (sig > budget ? "OVERFLOWS" : "fits"); console.log("ML-DSA-87 (4627 B) vs 4096 B budget: " + fits(mldsa87sig, COMMON_TPM)); console.log("ML-DSA-87 (4627 B) vs 3968 B budget: " + fits(mldsa87sig, TCG_REF)); console.log("ML-DSA-65 (3309 B) vs 3968 B budget: " + fits(3309, TCG_REF)); `}

Trail of Bits generalizes the warning beyond TPMs: if you maintain a protocol or wire format that hardcodes Ed25519-sized signatures or X25519-sized public keys, "the surrounding fields, length prefixes, and chunking assumptions need to grow with it" [@tob-2026]. Length prefixes sized for a single byte of count, record framing that assumed a signature fit in one packet, database columns declared CHAR(64) -- each is a small, quiet assumption that the standardized sizes break.

Key idea: A primitive is not a protocol. Standardizing ML-KEM and ML-DSA -- even shipping them in a default wheel -- does not migrate a single handshake. The primitive is larger, differently shaped, and hostile to the fixed-width assumptions baked into TLS records, X.509 certificates, SSH packets, and hardware command buffers. Installing it is the easy part; making the protocols around it accept it is the migration [@tob-2026] [@fips204].

So the primitive is real, standardized, and about to be a pip install away -- yet it silently breaks the protocols we would drop it into. Who actually shipped it, and how did they get it into more than a billion downloads a month?

7. The Crossing: How the Primitive Reached a Billion Downloads

The milestone on May 4, 2026 was not a new algorithm. ML-KEM and ML-DSA had existed in specialist builds of pyca/cryptography for over a year -- reachable only if you compiled the library against AWS-LC or BoringSSL. What changed in v48.0.0 was distribution: the primitives landed in the default wheel that everyone already installs.

The changelog says it plainly. Version 48.0.0 added support for mlkem and mldsa "when using OpenSSL 3.5.0 or later, in addition to the existing AWS-LC and BoringSSL support," and concludes: "This means post-quantum algorithms are now available to users of our wheels" [@pyca-changelog]. That last clause is the crossing. Not "available if you rebuild against a special backend," but available to users of the ordinary wheels, from an ordinary pip install.

The evolution here is distribution, not mathematics

flowchart TD S["FIPS 203 and 204 standard (2024)"] --> B1["OpenSSL 3.5.0 (2025)"] S --> B2["AWS-LC and BoringSSL (earlier)"] B2 -.->|specialist builds only, 2024 to early 2026| G["Backend-gated access"] B1 -->|default build| W["pyca cryptography v48 wheel (May 2026)"] G -.-> W W --> D["Ansible, Certbot, Airflow, paramiko"] D --> P["The whole Python software supply chain"]

The gate that opened was a backend one. pyca/cryptography delegates its heavy cryptography to a C library, and until recently only the non-default backends AWS-LC and BoringSSL exposed the post-quantum primitives. OpenSSL 3.5.0, released April 8, 2025, added support for ML-KEM, ML-DSA, and SLH-DSA to the mainstream backend [@openssl-35]. Once the default wheels could be built against an OpenSSL that carried the primitives, the last distribution barrier fell. The sequence is: standard, then backend-gated builds, then default wheels [@pyca-changelog] [@openssl-35].

There is a security point hiding in that sequence. pyca/cryptography does not reimplement ML-KEM or ML-DSA in Python; it delegates to the vetted C backend and exposes a thin, cross-tested binding [@tob-2026]. That is why the milestone is a packaging event, not a cryptographic one. It is also why the OpenSSL 3.5.0 floor is not an inconvenience but the whole mechanism: the primitive a developer calls is the same backend implementation that already ships in browsers and servers, reached through new Rust bindings rather than rewritten in a memory-unsafe hurry. Distribution, not reimplementation, is what crossed the last mile.

Why does one Python library matter this much? Reach. pyca/cryptography is the foundational cryptography library for the Python community, sitting underneath widely used tools including Ansible, Certbot, Apache Airflow, and paramiko [@tob-2026] [@deps-dev]. Because so much of the Python world depends on it, one release put quantum-resistant primitives within a single pip install of an enormous body of software.Trail of Bits reports pyca/cryptography as the eleventh most-downloaded package on PyPI, with about 1.2 billion downloads in the last month [@tob-2026] [@pypistats]. A change to a dependency that widely used is a change to the reachable capability of the entire community above it.

Who built it

The post-quantum work in pyca/cryptography was a funded, credited effort, not a weekend patch. Trail of Bits, with support from the Sovereign Tech Agency, wrote the Rust bindings, the cross-binding API and tests, and the AWS-LC backend support; the library's maintainers, Paul Kehrer and Alex Gaynor, contributed other-backend work and review [@tob-2026] [@sovereign-tech].

This article deliberately owns the shipping-code and Python axis of the migration. The complementary platform-and-operating-system axis -- how Windows exposes post-quantum primitives through SymCrypt, CNG, Schannel, and the TPM -- is the subject of this blog's separate post, [*Post-Quantum Cryptography on Windows*](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati/). Where that post asks which operating-system primitive ships in which release, this one asks what it means when the whole Python supply chain can `pip install` post-quantum crypto, and what still does not work.

What the API looks like

The signature API mirrors the existing asymmetric surface: generate a key, get its public key, sign, verify. The KEM API is where the shape difference from Section 6 becomes code -- encapsulate returns a (shared_secret, ciphertext) pair, not a single shared value both sides derive.

Signatures (FIPS 204): mirrors the familiar sign / verify shape

from cryptography.hazmat.primitives.asymmetric import mldsa private_key = mldsa.MLDSA65PrivateKey.generate() public_key = private_key.public_key() signature = private_key.sign(b"message") public_key.verify(signature, b"message") # raises InvalidSignature on failure

Key establishment (FIPS 203): a KEM, not Diffie-Hellman

from cryptography.hazmat.primitives.asymmetric import mlkem private_key = mlkem.MLKEM768PrivateKey.generate() public_key = private_key.public_key() shared_secret_sender, ciphertext = public_key.encapsulate() shared_secret_receiver = private_key.decapsulate(ciphertext) assert shared_secret_sender == shared_secret_receiver `}

Two caveats keep this honest. First, v48 ships ML-KEM and ML-DSA but not SLH-DSA; Trail of Bits notes only that they have "started working on it" [@tob-2026]. Second, the OpenSSL 3.5.0 requirement is real -- the primitives are exposed only when the wheel is backed by a version that carries them [@pyca-changelog]. The availability matrix makes the pattern visible: the primitive columns are nearly all "Yes," while real protocol integration remains sparse.

Layer	Artifact	ML-KEM	ML-DSA	SLH-DSA	Hybrid KEX default
Crypto backend	OpenSSL 3.5.0 (2025-04-08)	Yes	Yes	Yes	X25519MLKEM768 (TLS)
Crypto backend	AWS-LC / BoringSSL	Yes	Yes	no	n/a
Python library	pyca/cryptography v48.0.0 (2026-05-04)	Yes	Yes	no (WIP)	delegates
Python library	pyca/cryptography v49.0.0 (2026-06-12)	Yes	Yes (plus X.509)	no	delegates
SSH protocol	OpenSSH 9.9 (2024-09-19)	hybrid KEX	no	no	mlkem768x25519-sha256

Sources: OpenSSL 3.5.0 release notes [@openssl-35]; the pyca changelog [@pyca-changelog]; OpenSSH 9.9 notes [@openssh-99]; the Trail of Bits write-up [@tob-2026].

The code shipped the primitive in May. The federal government set its deadlines in June. Which one was driving the other?

8. The Clock, and Why the Code Got There First

Seven weeks after the wheels shipped, the White House put a clock on the wall. Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," was signed on June 22, 2026 [@eo14412]. It sets hard federal deadlines: migrate key establishment to post-quantum cryptography by December 31, 2030; migrate digital signatures by December 31, 2031; stand up a NIST migration pilot by December 31, 2027; and have CISA issue cryptographic-bill-of-materials minimum-elements guidance within 270 days [@eo14412].

timeline title Two tracks, and the code point lands first section Code track OpenSSL 3.5.0 2025-04-08 : PQC in the mainstream backend pyca v48.0.0 2026-05-04 : ML-KEM and ML-DSA in default wheels pyca v49.0.0 2026-06-12 : X.509 support, current at EO signing section Policy track NSM-10 and CNSA 2.0 2022 : intent set, but no shipping code OMB M-23-02 2022 : agency inventory guidance EO 14412 2026-06-22 : deadlines 2027, 2030, 2031

The policy intent is older than the code. The National Security Memorandum 10 (May 2022) [@nsm10], the NSA's CNSA 2.0 suite (September 2022) [@cnsa2], and OMB memorandum M-23-02 (November 2022) [@omb-m2302] had already told federal systems that a post-quantum migration was coming. What none of them could do was make the primitive installable. That is the asymmetry worth sitting with: the intent was set in 2022, but the shipping code arrived in 2026 -- and it arrived ahead of the deadline that finally gave the intent teeth.

The executive order's own definitions are asymmetric

One precise detail here is easy to get wrong, and getting it right sharpens the argument.

The executive order does not define its two migration targets symmetrically.Section 2 defines "key establishment" with the same meaning it has in FIPS 203 -- which is ML-KEM, a post-quantum standard -- so the key-establishment mandate points straight at the standardized primitive. But it defines "digital signature" with the same meaning it has in FIPS 186-5, the classical Digital Signature Standard covering RSA, ECDSA, and EdDSA; the post-quantum signature standard, FIPS 204 (ML-DSA), is not named in the definitions [@eo14412-fedreg] [@fips186-5] [@fips204]. The signature mandate is therefore operative, not definitional: Section 4(b) still requires migrating signatures to post-quantum cryptography by 2031, but it reaches that goal through the deadline text rather than by defining a signature as a post-quantum object. Key establishment is defined into a post-quantum standard; signatures are mandated toward post-quantum cryptography by a deadline while still being defined against the classical standard [@eo14412-fedreg] [@fips186-5]. That is not a contradiction -- it reflects that key establishment carries the urgent, harvest-now-decrypt-later confidentiality risk, while signatures do not, a distinction Section 9 develops.

The pip install beat the policy

Stated plainly: the shipping code led, and the policy followed. The full four-date timeline -- and why "the same week" is a misconception -- is in the callout below [@pyca-changelog] [@eo14412].

Note: A tempting version of this story claims the library and the executive order shipped the same week. They did not. Four dated facts settle it: pyca/cryptography v48.0.0 shipped the primitives on 2026-05-04; v49.0.0 followed on 2026-06-12; Executive Order 14412 was signed on 2026-06-22; and Trail of Bits published its write-up on 2026-06-30. No pyca release landed in the executive order's week -- the code arrived about seven weeks earlier [@pyca-changelog] [@eo14412] [@tob-2026].

This is the article's second turn, paid off. It was not the 2024 standard, and not the 2026 executive order, that put quantum-resistant cryptography in front of ordinary developers. It was two distribution events: standardization fixing the byte counts, and a default-wheel release shipping the code. The second beat the mandate. Federal policy still matters enormously for who must migrate and by when, and the platform axis of that migration on Windows is its own long story in this blog's sibling post. But on the shipping-code axis, decree did not lead. Distribution did.

If the code beat the mandate and the standard is finalized, the migration should be basically done. It is not. Why not?

9. What Shipping the Primitive Does Not Solve

Here is the uncomfortable truth beneath the celebration: nobody can prove that lattice problems are hard, and the assumption is younger than the one it replaces.

The security of ML-KEM and ML-DSA rests on two pillars. The first is the worst-case-to-average-case reduction from Ajtai and Regev, which ties breaking a random instance to solving the hardest instance of a lattice problem [@ajtai1996] [@regev-lwe]. The second is the best-known attack: lattice sieving, whose cost is $2^{0.292\beta}$ classically in the relevant blocksize, with no known exponential quantum speedup [@bdgl16]. The entire security argument lives in the gap between "no proof of hardness" and that attack cost. A proven super-polynomial lower bound would settle $P \ne NP$, since these lattice problems sit in NP -- so we are not getting a proof soon. This is the same epistemic position RSA has always occupied, except on a younger assumption.

Note: Integer factoring has been studied since antiquity; structured-lattice hardness in its deployed form dates to roughly 2012. That youth, plus the open "is the structure free?" question from Section 3, plus the fact that SIKE and Rainbow both fell during standardization, is exactly why the portfolio keeps SLH-DSA -- a signature whose security rests on hash functions alone and would survive even if lattice cryptanalysis advanced dramatically [@fips205] [@peikert-2015] [@sike-break] [@rainbow-break].

Two threat horizons, not one

A subtle but important point: the quantum threat does not arrive on the same schedule for confidentiality and for authentication.

Harvest-now-decrypt-later is a confidentiality horizon. An adversary can record an encrypted session today and decrypt it whenever a quantum computer arrives, so key establishment must be quantum-resistant now for any secret with a long shelf life. Signature forgery is an authentication threat with no retroactive version: you cannot forge yesterday's signature tomorrow, because a signature only needs to resist forgery until the moment it is verified and trusted [@eo14412]. That is why the order's key-establishment deadline (2030) falls a year before its signature deadline (2031): the confidentiality clock is the more urgent one [@eo14412].

Why the answer is a portfolio

No single scheme is simultaneously tiny, tightly reduced to a decades-old assumption, and trivially side-channel-safe. That ideal primitive does not exist, which is precisely why the standard is a portfolio rather than a single winner.

Dimension	ML-KEM (203)	ML-DSA (204)	SLH-DSA (205)	FN-DSA/Falcon (206)	Classic McEliece
Job	Key establishment	Signature	Signature	Signature	Key establishment
Hard problem	Module-LWE	Module-LWE	Hash preimage	NTRU lattice	Goppa decoding
Public key	1,184 B	1,952 B	32 to 64 B	compact	261 KB to 1.3 MB
Output	1,088 B ct	3,309 B sig	many KB sig	small sig	128 to 240 B ct
Assumption age	~2012	~2012	decades	~1996	45+ years
In pyca v48	Yes	Yes	no	no (pending)	no

Sources: FIPS 203, 204, and 205 [@fips203] [@fips204] [@fips205]; the CRYSTALS pages for the lattice schemes [@kyber] [@dilithium]; Classic McEliece for the code-based sizes [@classic-mceliece]; and the pyca changelog for what v48 includes [@pyca-changelog].

Two more standing hedges belong here, because they shape the practical advice in Section 11.

A key-establishment construction that runs a classical exchange (such as X25519) and a post-quantum KEM (such as ML-KEM-768) together and combines both shared secrets, so the session stays secure as long as *either* component is unbroken. Hybrids protect against both a surprise lattice break and an implementation bug in the new code, at the cost of sending both sets of bytes [@openssl-35]. The property of a system that can swap cryptographic algorithms without re-architecting the protocols and formats around them. Crypto-agility is the standing hedge against the next migration: build the seams now so that replacing a broken primitive later is a configuration change, not another thirty-year project.

If the math is settled enough to standardize and ship, and the limits are understood, where is the actual remaining work?

10. The Protocols Are the Remaining Work

Here is the thesis in one line: the primitive is a pip install away, and it is still nearly useless to most developers. That is not a paradox. It is the definition of the remaining work.

The defining open problem is protocol integration. TLS, SSH, X.509 and the public-key infrastructure built on it, and package signing all have to be redesigned around KEM-shaped, kilobyte-scale objects without breaking the length fields, buffers, and packet-size assumptions surveyed in Section 6 [@tob-2026]. Trail of Bits is blunt about what that means for the average engineer.

You're unlikely to use PQ algorithms directly in tools like Certbot or Ansible until common protocols add support. -- Trail of Bits [@tob-2026]

The good news is that the hardest-to-defer half is already moving.

Note: Hybrid key establishment -- the part with the harvest-now-decrypt-later urgency -- is solved and deployed. OpenSSH 9.9 (September 19, 2024) made mlkem768x25519-sha256 available by default [@openssh-99], and OpenSSL 3.5.0 made X25519MLKEM768 its default TLS keyshare [@openssl-35]. Authentication is the laggard: post-quantum signatures inside protocols and certificate chains trail behind, and even in pyca/cryptography, X.509 certificate signing with ML-DSA only arrived in v49.0.0 on June 12, 2026 [@pyca-changelog].

The portfolio is also still incomplete in the shipping code. SLH-DSA, the conservative hash-based backstop, is not yet in pyca/cryptography; the maintainers have only started on it [@tob-2026]. Falcon, standardized as FN-DSA, remains pending as FIPS 206 in 2026, held up in part because its floating-point Gaussian sampler is hard to implement safely at standardization quality [@tob-2026] [@nist-2022]. So even a developer who wants the full toolbox cannot yet pip install all of it.

And some problems have nothing to do with new code. Long-lived trust anchors -- root certificates and firmware keys with lifetimes measured in decades -- must migrate while still interoperating with everything already deployed, and they run straight into the fixed-size hardware limits from Section 6, where an extra security level can overrun a command buffer that has no chunking [@tpm2-spec]. The deeper governance problem is crypto-agility: building systems so that the next forced migration -- prompted by, say, a lattice break of the kind that felled SIKE -- does not take another thirty years [@sike-break].

None of this is theoretical anymore. So what should a working engineer actually do on Monday?

11. Using It Today

Concrete and actionable: the one command, the one gotcha, and the three decisions.

The command is pip install "cryptography>=48". The gotcha is that the version pin alone does not guarantee you get anything post-quantum.

Note: First, pip install "cryptography>=48" does not by itself guarantee post-quantum support: ML-KEM and ML-DSA appear only when the wheel is backed by OpenSSL 3.5.0 or later, AWS-LC, or BoringSSL, and the changelog cautions that functionality is not guaranteed across every OpenSSL build [@pyca-changelog] [@openssl-35]. Second, unless you author the protocol or library yourself, do not hand-roll a wire format around a raw KEM -- the size and shape traps from Section 6 are exactly what vetted protocol work exists to absorb [@tob-2026].

The API is small enough to hold in your head.A version pin alone is not enough: as the callout above warns, the primitives appear only when the wheel is built against a supported backend [@pyca-changelog]. The mldsa module gives you generate, public_key, sign, and verify -- the familiar signature shape. The mlkem module gives you encapsulate, which returns a (shared_secret, ciphertext) pair, and decapsulate, which takes a ciphertext and returns the shared secret. There is deliberately no separate share-combining step: that is the KEM shape from Section 6, not a Diffie-Hellman exchange [@tob-2026].

Import the module and generate a key; a backend without support raises instead of silently degrading. Running `mlkem.MLKEM768PrivateKey.generate()` after `from cryptography.hazmat.primitives.asymmetric import mlkem` should complete without error. A clean run means your wheel is backed by a build that actually carries ML-KEM -- one of the supported backends named in the warning above -- while an exception means it is not [@pyca-changelog].

Three decisions follow.

Which parameter set? Default to ML-KEM-768 and ML-DSA-65 -- NIST Category 3, roughly AES-192, and more than 128 bits of security under conservative analysis [@kyber] [@dilithium]. Go higher only for data whose confidentiality must outlive decades, and when you do, watch the 4,096-byte wall from Section 6. Prefer ML-DSA over SLH-DSA as your default signature, and do not wait for Falcon in Python -- it is not standardized yet. Performance rarely decides this: even on a constrained ARM Cortex-M4, ML-KEM-768 runs in around a million cycles per operation, and on modern hardware the cost is imperceptible for normal use [@pqm4] [@tob-2026].

Pure or hybrid? Prefer hybrid where a protocol offers it.

Note: Use hybrid key establishment (X25519MLKEM768) wherever a protocol supports it -- it is already the TLS and SSH default and keeps you safe if either half is broken [@openssl-35] [@openssh-99] [@kyber]. And inventory before you install: build a cryptographic bill of materials, then migrate harvest-now-decrypt-later confidentiality assets first, since those carry the only clock that is already running [@eo14412].

Where do you start? Not with code -- with an inventory.

A machine-readable inventory of the cryptography a system uses: which algorithms, key sizes, protocols, and libraries appear where. A CBOM is the migration's first practical step -- you cannot replace what you cannot find -- and Executive Order 14412 directs CISA to publish minimum-elements guidance for exactly this kind of inventory [@eo14412].

You can install the primitive in five seconds; you should deploy it with a plan. The last mile after the pip install is yours.

12. Frequently Asked Questions

No. It gives you primitives, not a protocol, and only when the wheel is backed by OpenSSL 3.5.0 or later, AWS-LC, or BoringSSL. Being able to call ML-KEM and ML-DSA is not the same as having a quantum-resistant TLS connection or certificate chain, which depend on protocol integration that is still in progress [@pyca-changelog] [@tob-2026]. No. ML-KEM is a key-encapsulation mechanism, not a Diffie-Hellman exchange: one side encapsulates a fresh secret to the other's public key rather than both sides combining shares. The message shape differs, and the objects are roughly 34 to 37 times larger, so protocols must be redesigned rather than merely re-parameterized [@tob-2026] [@fips203]. No. Earlier versions of the library could already expose ML-KEM and ML-DSA when built against AWS-LC or BoringSSL. What v48.0.0 changed was distribution: it put the primitives in the default OpenSSL-backed wheels, so a plain `pip install` reaches them [@pyca-changelog]. Not in the near term. Harvest-now-decrypt-later means an adversary can record today's encrypted traffic and decrypt it once a quantum computer exists, so the pressing driver is the confidentiality of data with a long shelf life, not the arrival date of the hardware [@tob-2024] [@eo14412]. Harvest-now-decrypt-later is a confidentiality horizon: recorded ciphertext can be broken retroactively, so key establishment is urgent now. Signature forgery is an authentication threat that only bites once a quantum computer exists, because you cannot forge a signature that was already verified and trusted in the past. That is why the federal key-establishment deadline precedes the signature deadline [@eo14412]. No. `pyca/cryptography` v48.0.0 shipped ML-KEM and ML-DSA on May 4, 2026; Executive Order 14412 was signed on June 22, 2026, about seven weeks later; and v49.0.0 (June 12) was the release current at the signing. No pyca release landed in the order's week [@pyca-changelog] [@eo14412]. No. Post-quantum cryptography is classical software -- ordinary algorithms on ordinary computers -- designed to resist quantum attack, which is exactly what FIPS 203 and 204 standardize [@fips203] [@fips204]. Quantum key distribution is a hardware and physics approach that transmits keys over quantum channels; it is a different technology often confused with PQC.

Conclusion: The Primitive Shipped, the Protocols Remain

A threat named in 1994 set a thirty-year relay in motion. Ajtai and Regev found lattice math that plausibly survives Shor's algorithm; Ring-LWE and Module-LWE made that math small enough to ship; an open competition from 2016 to 2022 chose a deliberately diverse portfolio and watched two serious candidates break along the way; and in August 2024, NIST turned the winners into standards with fixed byte counts and validated test vectors [@ajtai1996] [@regev-lwe] [@module-lwe] [@nist-2022] [@fips203] [@fips204].

Then, on May 4, 2026, the primitive quietly crossed its last visible milestone -- not by decree, but by distribution. pyca/cryptography v48.0.0 put ML-KEM and ML-DSA in the default wheels that a billion-download-a-month slice of the Python world already installs, roughly seven weeks before Executive Order 14412 set the federal deadlines [@pyca-changelog] [@eo14412]. The primitive shipped; the policy set the clock; and the protocols are the work that remains [@pyca-changelog] [@eo14412] [@tob-2026].

That last clause is the whole point. ML-KEM and ML-DSA are larger, differently shaped, and hostile to the fixed-width assumptions that TLS, SSH, X.509, and hardware buffers were quietly built around. Installing the primitive took thirty years and now takes five seconds. Making the protocols accept it -- redesigning wire formats around KEM-shaped, kilobyte-scale objects without breaking the length fields and command budgets that assumed 32-byte keys and 64-byte signatures -- is the migration that is actually left. A primitive is not a protocol, and the last mile after the pip install is the one we are still walking.