En 2021, une université chinoise a présenté Zuchongzhi1, un ordinateur surpassant celui de Google. La possibilité de compromettre ECC et RSA constitue un enjeu majeur pour la sécurité informatique. La réalité concrète de cette machine soulève des interrogations et pourrait relever d’une course technologique confrontée à des limites techniques.
La question porte donc sur la supposition suivante : si cette machine n’existe pas, dans quelle mesure des produits comme LetReco et MFT Online se trouvent concernés par le post-quantique ?
LetReco constitue un produit qualifié eIDAS, garantissant la confiance dans les transactions numériques. Les preuves d’envoi, de téléchargement et assimilées restent stockées de manière pérenne et chiffrée afin de prévenir toute mise en danger des données utilisateurs en cas d’exfiltration malveillante.
Or, l’ANSSI adopte une position claire sur ce sujet de chiffrement, considérant que l’acquisition de produits sans support PQC perdrait toute pertinence après 20302. Lors du stockage des pièces, LetReco s’appuie sur un chiffrement robuste, combinant l’AES-GCM et des mécanismes asymétriques. Or, cette dernière catégorie d’algorithmes présente donc une vulnérabilité face aux capacités du post-quantique.
La durée de conservation des preuves s’étendant sur un minimum de 7 ans, une préparation à cette mutation s’impose dès à présent.
Une des questions consiste donc à comprendre le risque associé à un ordinateur quantique. Le premier concerne la cassure des méthodes actuelles de chiffrement standard : l’émergence d’un monde où l’échange d’une clé publique via « Diffie-Hellman » ou « ECDH » deviendrait impossible. Ce risque ne se matérialise qu’avec l’apparition d’un ordinateur quantique suffisamment puissant.
Un autre risque, plus pernicieux, correspond au concept de « Harvest Now, Decrypt Later ». Ce scénario peut sembler tiré d’un mauvais film d’espionnage, mais il rappelle la situation de juin 20133, lorsque Edward Snowden, à travers la plume de Greenwald, a révélé la collecte massive des enregistrements téléphoniques par la NSA. Si cette capture massive remonte à plus de dix ans, son actualité demeure probable.
La cryptographie a réagi face à cette menace, et une série d’algorithmes dits post-quantiques commence à être normalisé par le NIST. Parmi ceux-ci, figurent Kyber et NTRU pour le chiffrement, ainsi que Dilithium pour la signature.
La raison fondamentale expliquant pourquoi un ordinateur quantique pourrait casser RSA mais pas Kyber repose sur les problèmes mathématiques sous-jacents. Shor transforme la factorisation d’un entier en problème de recherche de période, puis utilise la transformée de Fourier quantique pour détecter cette période efficacement, permettant ainsi de casser RSA. Kyber repose sur le problème Learning With Errors (LWE), pour lequel aucun algorithme quantique polynomial connu ne permet de le résoudre, ce qui lui confère une résistance face aux ordinateurs quantiques.
Les KEM, un mécanisme central de la cryptographie post-quantique
Les algorithmes post-quantiques utilisent la notion de Key Encapsulation Mechanism (KEM) pour les échanges de clefs, notion qui mérite un examen approfondi.
Un KEM, tel que décrit dans l’article cité en référence4, se définit comme un mécanisme cryptographique dont le rôle principal est d’échanger une clé symétrique de session via la cryptographie à clé publique. En tant que mécanisme, il n’impose aucune méthode mathématique particulière, ce qui permet de construire un KEM basé aussi bien sur des algorithmes standards que post-quantiques.
Les 3 opérations d’un KEM
Trois opérations composent un KEM :
- La génération de clef
- L’encapsulation, qui génère une clé symétrique aléatoire ainsi qu’une capsule chiffrée avec la clé publique,
- la décapsulation, qui permet de retrouver la clef symétrique en utilisant la clef privée.
Bien que cette méthode apparaisse moins courante que celle de DH/ECDH, on la retrouve normalisée via la JEP 4525 et les fonctions C_EncapsulateKey/C_DecapsulateKey de la norme PKCS#11 v36.
Qu’ils reposent sur des algorithmes classiques ou post-quantiques, les KEM présentent une caractéristique marquante : la mise en place du chiffrement post-quantique passe nécessairement par eux.
L’hybridation : combiner cryptographie et post-quantique
La question centrale ne porte pas tant sur la manière d’utiliser un algorithme que sur la pertinence d’adopter dès maintenant un algorithme post-quantique. Les algorithmes « classiques » bénéficient d’une trentaine d’années de recul sur leur usage. Par usage, il faut entendre à la fois la résistance mathématique et l’implémentation. À contrario, la librairie open source liboqs de Postquantum Cryptography Alliance7 voit le jour en 2018 et atteint actuellement la version 0.15. L’implémentation dans BouncyCastle apparaît depuis 20248.
Les limites d’un passage immédiat au post-quantique
L’usage exclusif d’un algorithme post-quantique risquerait, en voulant prévenir un risque potentiel futur, de mettre en péril le chiffrement actuel. Nous nous retrouverions alors dans une situation intermédiaire avec des algorithmes standards ne protégeant pas du futur, et d’autres palliant ces problématiques mais présentant encore des risques à ce jour. D’autre part, une impossibilité technique empêche l’adoption uniquement post-quantique. Les HSM et validateurs de certificat ne répondent pour l’instant pas à la norme.
Le principe de l’hybridation cryptographique
L’idée en vogue consiste à pratiquer l’hybridation, soit vulgairement le fait de chiffrer à la fois avec un algorithme standard et avec un algorithme post-quantique. De ce fait, on se protègerait à la fois des périls actuels et futurs, sous l’hypothèse que les algorithmes post-quantiques ne soient pas cassés.
Cependant, derrière cette simplicité affirmant que deux chiffrements/signatures valent mieux qu’un, des problématiques diverses apparaissent. En premier lieu, l’implémentation gagne en complexité. Disposer de deux implémentations portant sur deux familles d’algorithmes constitue déjà une gageure, mais l’implémentation en sus de l’hybridation doit également répondre à des exigences de qualité.
Les certificats issus de ces hybridations doivent répondre à des contraintes supplémentaires, notamment sur le plan opérationnel. Un certificat doublement signé, une fois en quantique et en classique, implique une complexité supplémentaire dans la gestion des révocations.
Enfin, et cela ne pose peut-être plus problème à ce jour, mais fatalement la taille des clefs et signatures se voit augmenter à minima de la somme de celles de deux algorithmes.
XWing, un KEM hybride
L’algorithmique derrière la mise en place des KEM hybrides regroupe une pléthore de méthodes. X25519Kyber768Draft00 (HPKE)9 propose de mixer du Kyber 768 avec du X25519. FrodoKEM10 propose quant à lui de mixer FrodoKEM-976 + X25519. Enfin, on pourrait citer SM2MLKEM adapté aux contraintes chinoises.
Parmi les KEM disponibles figure également le papier de X-Wing11 12, qui trouve son origine dans la recherche européenne.
X‑Wing constitue donc un système de partage de clés sécurisé qui combine deux technologies : X25519, largement reconnue et standardisée, ainsi que MLKEM768, résistante aux ordinateurs quantiques. En combinant ces deux technologies, X‑Wing fonctionne plus efficacement qu’un système générique mélangeant plusieurs méthodes de sécurité.
Ce dernier KEM offre une sécurité garantie tant que MLKEM768 reste sûr et que SHA3256 fonctionne correctement comme générateur de nombres aléatoires.
Enfin, le mot-clef de X-Wing réside dans sa simplicité tant dans sa démarche que dans sa description.
Dans ce KEM, les tailles des clés d’encapsulation/décapsulation ainsi que le secret partagé restent fixes. On note particulièrement que ce dernier occupe 32 bytes :
- Decapsulation key (private): 32 bytes
- Encapsulation key (public): 1216 bytes
- Ciphertext: 1120 bytes
- Shared secret: 32 bytes
La génération de clé passe par la création de clés publiques/privées pour les deux algorithmes via une expansion du secret de 32 bytes.
Génération de clés
def expandDecapsulationKey(sk):
expanded = SHAKE256(sk, 96*8) # usage SHAKE256 pour avoir 96 octet
(pk_M, sk_M) = ML-KEM-768.KeyGen_internal(expanded[0:32], expanded[32:64])
sk_X = expanded[64:96]
pk_X = X25519(sk_X, X25519_BASE)
return (sk_M, sk_X, pk_M, pk_X)
Enfin, la génération de clé produit le couple formé du secret partagé et de la concaténation des clés publiques.
def GenerateKeyPair():
sk = random(32)
(sk_M, sk_X, pk_M, pk_X) = expandDecapsulationKey(sk)
return sk, concat(pk_M, pk_X)
L’expéditeur génère un secret partagé et l’encapsule avec la clé publique du destinataire.
def Encapsulate(pk):
# 1. Séparation des composants
pkM = pk[0:1184]
# Clé publique ML-KEM-768
pkX = pk[1184:1216]
# Clé publique X25519 (32 octets)
Puis vient la génération d’une clé jetable ekX, le calcul de sa clé publique ctX (destinée à la transmission) et enfin le calcul du secret ECDH ssX avec la clé publique du destinataire.
# Génération d'une clé privée aléatoire (usage unique)
ekX = random(32)
# Calcul de la clé publique éphémère
ctX = X25519(ekX, G) # G = point générateur Curve25519
# ctX = 32 octets
# Calcul du secret partagé X25519
ssX = X25519(ekX, pkX) # ECDH classique
# ssX = 32 octets
Cette étape accomplie, vient l’encapsulation avec ML-KEM-768 puis la combinaison. Cette dernière doit contenir, après les secrets et contextes, le label X-Wing en dernière position.
# Étape 3 : ML-KEM
(ssM, ctM) = ML-KEM-768.Encaps(pkM)
# Étape 4 : Combiner
label = bytes([0x5c, 0x2e, 0x2f, 0x2f, 0x5e, 0x5c])
ss = SHA3-256(ssM + ssX + ctX + pkX + label)
# Étape 5 : Construire ciphertext
ct = ctM + ctX
De façon imagée, pour partager un secret avec le destinataire, l’expéditeur utilise deux méthodes en parallèle : placement d’un premier secret (ssM) dans un coffre-fort quantique (ctM) verrouillé avec l’adresse publique du destinataire (pkM), et génération d’une clé jetable (ekX) créant un second secret (ssX) via une enveloppe classique dont l’empreinte visible (ctX) résulte du calcul avec l’adresse publique du destinataire (pkX). Le protocole mélange ensuite ces deux secrets avec les contextes (ctX, pkX) puis le label X-Wing, avant hachage en SHA3-256 produisant le secret final unique (ss).
L’expéditeur transmet le coffre-fort verrouillé (ctM) plus l’empreinte du sceau (ctX), formant au total le ciphertext (ct). Le destinataire ouvre le coffre avec sa combinaison privée (skM) pour récupérer ssM, utilise sa clé privée (skX) avec l’empreinte reçue (ctX) pour recalculer ssX, puis applique le même mélange pour obtenir exactement le même secret final (ss). L’expéditeur détruit immédiatement la clé jetable (ekX) après usage.
Conclusion : vers une transition progressive vers le post-quantique
Le monde du post-quantique connaît une effervescence avec cette volonté à la fois de se protéger des attaques futures et de résister aux risques présents.
La mise en place d’un KEM hybride tel que dans cet article représente en fait la partie simple de la problématique car cela constitue une brique de base. D’un point de vue industriel, l’hybridation touche toute la chaîne de la cryptographie. Comment faire un certificat hybride, comment modifier les HSM pour intégrer des KEM hybrides, quid des sessions TLS hybrides.
Cet article tente de lever gentiment le voile sur ces aspects via une implémentation de X-Wing disponible sur https://github.com/equisign/xwing intégrant les API JCE. Cette implémentation présente l’avantage en Java/Kotlin de rester directement utilisable et s’est confrontée aux vecteurs de test du draft. Par-delà cette implémentation, nous contribuons, en tant qu’implémentation de référence pour les JVM, au draft aux côtés de Google pour le langage C, d’Apple à travers CryptoKit, ainsi que de Cloudflare pour le Go.
***
À propos de l’auteur :
Pierre-Emmanuel GROS, Docteur Ingénieur
Auteur d’articles sur l’innovation et la culture tech, conteur d’expériences et semeur d’idées, j’aime explorer ce qui se joue en coulisses, derrière les lignes de code… et rappeler qu’au fond, toute aventure technologique est d’abord collective.
Références citées dans l’articles
- Wu, Y., Bao, W.-S., Cao, S., Chen, F., Chen, M.-C., Chen, X., et al. (2021). Strong quantum computational advantage using a superconducting quantum processor. Physical Review Letters, 127(18), 180501, https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.127.180501 ↩︎
- ANSSI. FaQ sur la cryptographie post-quantique (PQC). Agence nationale de la sécurité des systèmes d’information., https://cyber.gouv.fr/enjeux-technologiques/cryptographie-post-quantique/faq-pqc/ ↩︎
- Greenwald, Glenn et al. “NSA collecting phone records of millions of Verizon customers daily”, The Guardian, 6 juin 2013. ↩︎
- Bellare, M., Boldyreva, A., Micali, S. (2000). Public-Key Encryption in a Multi-user Setting: Security Proofs and Improvements. In: Preneel, B. (eds) Advances in Cryptology — EUROCRYPT 2000. EUROCRYPT 2000. Lecture Notes in Computer Science, vol 1807. Springer, Berlin, Heidelberg. https://doi.org/10.1007/3-540-45539-6_18 ↩︎
- OpenJDK JEP 452 — Key Encapsulation Mechanism API (Release 21) ↩︎
- OASIS, PKCS #11 Cryptographic Token Interface Specification Version 3.0, ↩︎
- Post-Quantum Cryptography Alliance. (2024). Post-Quantum Cryptography Alliance. Linux Foundation. https://pqca.org/ ↩︎
- Bouncy Castle Java 1.79, https://www.bouncycastle.org/resources/latest-nist-pqc-standards-and-more-bouncy-castle-java-1-79/?utm_source=chatgpt.com ↩︎
- X. Yang et al., “Hybrid postquantum key exchange SM2MLKEM for TLS 1.3,” InternetDraft, draftyangtlshybridsm2mlkem03, Internet Engineering Task Force, 2025. https://datatracker.ietf.org/doc/draft-yang-tls-hybrid-sm2-mlkem/ ↩︎
- G. Wang, L. Bruckert, et V. Smyslov, “Postquantum Hybrid Key Exchange in IKEv2 with FrodoKEM,” InternetDraft, draftwangipsecmehybridkemikev2frodo03, Internet Engineering Task Force, 2025. https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/ ↩︎
- D. Connolly, P. Schwabe, et B. Westerbaan, “XWing: generalpurpose hybrid postquantum KEM,” InternetDraft, draft-connolly-cfrg-xwing-kem-09, IETF, 2025, https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/ ↩︎
- M. Barbosa, D. Connolly, J. D. Duarte, A. Kaiser, P. Schwabe, K. Varner, et B. Westerbaan, “X‑Wing: The Hybrid KEM You’ve Been Looking For,” IACR Communications in Cryptology, vol. 1, no. 1, Cryptology ePrint Archive, Paper 2024/039, 2024 ↩︎