Hybrid ML-KEM and ECDH, or Why Two Algorithms Beat One

When you encrypt data for a recipient, you do not encrypt the data with their public key. You draw a random content key, encrypt the data with it (AES-256), then pass that content key to the recipient in a way only they can recover. That last step, the key exchange, is what the quantum computer threatens.

Today it relies on RSA or elliptic curves (ECDH). Tomorrow, a large enough quantum computer will break them with Shor's algorithm. ML-KEM, standardized by NIST in 2024 (FIPS 203), is designed to resist it.

Why not switch to ML-KEM alone

Because a cryptographic algorithm earns trust over time. RSA and elliptic curves have withstood decades of attacks. ML-KEM rests on well-studied mathematical problems, but its implementations are young, and recent history has shown that promising post-quantum candidates can fall. SIKE, still a candidate in the fourth round of the NIST competition, was broken in 2022 in about an hour of computing on an ordinary computer.

Hybridization answers that uncertainty. You perform both exchanges, ML-KEM and ECDH, and combine both secrets into a single key. An attacker has to break both to recover it.

• Against a quantum computer, ECDH falls, but ML-KEM holds.
• Against a flaw found in ML-KEM, ML-KEM falls, but ECDH holds, at least while no quantum computer exists.
• In every case, the protection is never weaker than today's.

That is the position of ANSSI, the French national cybersecurity agency, which strongly insists on hybridization in the short and medium term, and requires it for restricted data and regulated systems.

How the two secrets are combined

Feranor PQC Suite follows the composite ML-KEM of the IETF LAMPS drafts. A single public key holds the ML-KEM key and the ECDH key, and a single message carries both. On receipt, both shared secrets are combined, with the public elements of the exchange, by a key derivation function. The result protects the content key.

All of it fits in a standard CMS message (RFC 5652, and RFC 9629 for key encapsulation mechanisms). The structure stays readable by any conforming tool, and nothing changes for applications when the algorithms evolve.

What it costs, measured

You might think two exchanges cost twice as much. The measurements say otherwise, here on a recent workstation (Intel Core Ultra 9, Linux, OpenSSL 3.5).

• ML-KEM-1024 alone. It encapsulates in 0.05 ms and decapsulates in 0.04 ms.
• MLKEM1024-ECDH-P384. The ANSSI profile's default encapsulates in 0.69 ms and decapsulates in 0.38 ms.
• MLKEM768-ECDH-P256. For comparison, it encapsulates in 0.15 ms and decapsulates in 0.11 ms.

Most of the cost therefore comes from the classical part, the P-384 curve, not from ML-KEM, which is very fast. All in all, encrypting a 1 KB message for one recipient takes about 0.7 ms and decrypting it 0.4 ms. For documents, archives or exchanges between applications, that is negligible.

Size grows a little. An ML-KEM-1024 public key or ciphertext weighs 1,568 bytes, against 97 bytes for a P-384 point. In the order of 2 KB more per recipient, whatever the size of the message.

And for signatures

The same reasoning applies to authenticity. The suite signs with SLH-DSA (FIPS 205), whose security rests on hash functions only, the most conservative assumption there is. ANSSI does not systematically ask for hybridization of these signatures; the suite still adds an ECDSA P-384 co-signature by default, and verifies both.

Hybridization does not bet on one algorithm. It guarantees the protection is never weaker than today's.