ML-KEM et ECDH en hybride, ou pourquoi deux algorithmes valent mieux qu'un

Quand on chiffre une donnée pour un destinataire, on ne chiffre pas la donnée avec sa clé publique. On tire une clé de contenu au hasard, on chiffre la donnée avec elle (AES-256), puis on transmet cette clé de contenu au destinataire de façon à ce que lui seul puisse la retrouver. C'est cette dernière étape, l'échange de clé, que l'ordinateur quantique menace.

Aujourd'hui, elle repose sur RSA ou sur les courbes elliptiques (ECDH). Demain, un ordinateur quantique suffisamment puissant les cassera avec l'algorithme de Shor. ML-KEM, normalisé par le NIST en 2024 (FIPS 203), est conçu pour lui résister.

Pourquoi ne pas passer directement à ML-KEM

Parce qu'un algorithme cryptographique gagne la confiance avec le temps. RSA et les courbes elliptiques ont résisté à des décennies d'attaques. ML-KEM repose sur des problèmes mathématiques bien étudiés, mais ses implémentations sont jeunes, et l'histoire récente a montré que des candidats post-quantiques prometteurs pouvaient tomber. SIKE, encore candidat au quatrième tour du concours du NIST, a été cassé en 2022 en une heure de calcul sur un ordinateur ordinaire.

L'hybridation répond à cette incertitude. On fait les deux échanges, ML-KEM et ECDH, et on combine les deux secrets en une seule clé. Un attaquant doit casser les deux pour la retrouver.

• Face à un ordinateur quantique, ECDH tombe, mais ML-KEM tient.
• Face à une faille découverte dans ML-KEM, ML-KEM tombe, mais ECDH tient, au moins tant que l'ordinateur quantique n'existe pas.
• Dans tous les cas, la protection n'est jamais plus faible qu'aujourd'hui.

C'est la position de l'ANSSI, qui insiste fortement sur l'hybridation à court et moyen terme, et l'impose pour les données Diffusion Restreinte et les systèmes réglementés.

Comment les deux secrets sont combinés

Feranor PQC Suite suit le ML-KEM composite des brouillons IETF LAMPS. Une seule clé publique réunit la clé ML-KEM et la clé ECDH, et un seul message transporte les deux. À la réception, les deux secrets partagés sont combinés, avec les éléments publics de l'échange, par une fonction de dérivation. Le résultat protège la clé de contenu.

Le tout s'inscrit dans un message CMS standard (RFC 5652, et RFC 9629 pour les mécanismes d'encapsulation de clé). La structure reste lisible par tout outil conforme, et rien ne change pour les applications quand les algorithmes évoluent.

Ce que ça coûte, mesuré

On pourrait croire que faire deux échanges coûte deux fois plus cher. Les mesures disent autre chose, ici sur un poste récent (Intel Core Ultra 9, Linux, OpenSSL 3.5).

• ML-KEM-1024 seul. Il encapsule en 0,05 ms et décapsule en 0,04 ms.
• MLKEM1024-ECDH-P384. Le défaut du profil ANSSI encapsule en 0,69 ms et décapsule en 0,38 ms.
• MLKEM768-ECDH-P256. Pour comparaison, il encapsule en 0,15 ms et décapsule en 0,11 ms.

L'essentiel du coût vient donc de la partie classique, la courbe P-384, pas de ML-KEM, qui est très rapide. Au total, chiffrer un message de 1 Ko pour un destinataire prend environ 0,7 ms et le déchiffrer 0,4 ms. Pour des documents, des archives ou des échanges entre applications, c'est négligeable.

La taille, elle, augmente un peu. Une clé publique ou un texte chiffré ML-KEM-1024 pèse 1 568 octets, contre 97 octets pour un point P-384. De l'ordre de 2 Ko de plus par destinataire, quelle que soit la taille du message.

Et pour les signatures

Le même raisonnement vaut pour l'authenticité. La suite signe avec SLH-DSA (FIPS 205), dont la sécurité ne repose que sur des fonctions de hachage, l'hypothèse la plus prudente qui soit. L'ANSSI ne demande pas systématiquement d'hybridation pour ces signatures ; la suite ajoute pourtant par défaut une cosignature ECDSA P-384, et vérifie les deux.

L'hybridation ne parie pas sur un algorithme. Elle garantit que la protection n'est jamais plus faible qu'aujourd'hui.