J V
All notes

NOTES · · 1 min read

Developer-centric security in post-quantum cryptography

Why the hard part of the post-quantum migration may not be the maths, but the moment a developer opens the documentation.

Diagram of an ML-KEM key exchange: key generation, encapsulation and decapsulation producing a shared secret on both sides.
ML-KEM in one picture: whoever holds the secret key can recover the shared secret from the ciphertext.

This is example text to show the note layout. Replace it in the CMS.

Post-quantum cryptography is often discussed as a problem of algorithms: lattices, parameter sets and security levels. For most developers, though, the migration starts somewhere much more ordinary: a header file, a code sample and a deadline.

Key encapsulation is not key exchange

ML-KEM (standardised as FIPS 203) is a key encapsulation mechanism. Instead of both parties contributing to a shared value, as in Diffie–Hellman, one side encapsulates a fresh secret to the other side's public key:

  1. The receiver generates a key pair and publishes the public key.
  2. The sender runs Encaps(pk) and gets a ciphertext and a shared secret.
  3. The receiver runs Decaps(sk, ct) and recovers the same shared secret.

That difference is small on paper, but it changes function signatures, error handling and what "the key" even refers to in an API.

A developer who has to understand the scheme to use it safely is a developer who might use it unsafely.

What I looked for

  • Can a developer complete a hybrid key exchange from the documentation alone?
  • Does the API make it hard to reuse or leak the shared secret?
  • Are failures reported in a way that is hard to ignore?
A layered view of a cryptographic API
Where developers meet the cryptography: the higher the layer, the fewer ways to get it wrong.

Takeaway

The safest post-quantum API is the one that looks boring: one obvious function, one obvious return value, and no way to forget a step.