← Back to the blog
ENGINEERING 2 July 2026 · By Magdalena Zdunkiewicz · 7 min read

Cryptographic agility: why the whole algorithm fits in one string

The post-quantum migration will not be the last time the world changes algorithms. The real lesson of the past two years isn't ML-KEM — it's the design discipline that made switching to ML-KEM cheap. Here is how that discipline works in OpenSSL and in KMIP.

Reading time · 7 minutes Filed under · Crypto agility, KMIP 3.0, OpenSSL

§1 — the KEM ideaStop building key exchange out of steps.

For decades, key exchange was something you assembled yourself. The series of steps you perform for ECDH and the series you perform for RSA are different — and every application had its own hand-built version of each. The key encapsulation mechanism (KEM) turns that on its head: model the concept as a single primitive, not as how it's made up inside.

Under a KEM interface, "ECDH done this way" and "RSA done that way" are implementation details behind one uniform operation. From the application programmer's point of view, you're just doing a key establishment. And once your application talks to the higher-level model, something important becomes possible: very different mathematics can be swapped in underneath — lattice-based ML-KEM included — without the application ever becoming aware of it.

"This won't be the last time we change algorithms. If we're going to change algorithms on a regular basis, we need to build to make change less expensive."

§2 — one labelThe whole algorithm, named by a string.

The second half of the discipline is naming. Classical algorithms leak their internals into your code: for ECDH you must supply the name of the curve; for RSA, the size of the key. Extra parameters, extra steps, extra places for the migration to snag.

The approach used in both OpenSSL and KMIP is to specify an algorithm by a single string name that carries everything it needs. You don't ask for "an ML-KEM of this size" — you ask for ML-KEM-768. What it's made of inside, you don't know and don't need to know. One label identifies the algorithm and all of its properties.

Family
Standard
You ask for, by name
{{ f.fam }}
{{ f.spec }}
{{ f.names }}

SLH-DSA is the extreme case — a whole pile of published variants — which is exactly why one-label naming matters: the label absorbs the variation so your code doesn't have to.

§3 — why it mattersAgility is the product. PQC was just the test.

Cryptographic agility means that when new algorithms or techniques come along, changing to them is easy — you don't wait five years for everybody to change over. If a new algorithm needs a new type of parameter passed everywhere, all the code has to change. If the algorithm is one label, you change one label. That property was designed into KMIP: one identifier per algorithm, no companion parameters, the same discipline OpenSSL applies.

The post-quantum migration was the first full-scale test of that design, and the reason the industry could move as fast as it did: browsers, servers, and toolkits switched to hybrid ML-KEM within months of NIST finalising the standards, not years. The next algorithm change — and there will be one — should be cheaper still. That's the point.

PQC in our SDKs → Proven interoperability