Depuis le 8 avril 2025, OpenSSL 3.5.0 embarque nativement le support de ML-KEM, l’algorithme d’échange de clés post-quantique standardisé par le NIST. Concrètement, cela signifie que n’importe quel serveur TLS compilé avec cette version peut négocier une session hybride résistante aux ordinateurs quantiques, sans provider externe ni patch maison. L’ANSSI a publié son avis sur la migration post-quantique le 23 juin 2025, et recommande explicitement l’hybridation : combiner un algorithme classique éprouvé (X25519 ou ECDHE) avec un algorithme post-quantique comme ML-KEM-768. Ce tutoriel vous montre comment mettre en place cette hybridation de bout en bout, du serveur Node.js au reverse proxy Nginx, avec du code que vous pouvez copier et faire tourner aujourd’hui.

Pourquoi la migration post-quantique presse en 2026

Le NIST a finalisé trois standards de cryptographie post-quantique le 13 août 2024 : FIPS 203 pour ML-KEM (échange de clés), FIPS 204 pour ML-DSA (signatures) et FIPS 205 pour SLH-DSA (signatures sans état). En mars 2025, le NIST a ajouté HQC comme cinquième mécanisme, un algorithme de secours pour ML-KEM dont le brouillon de norme est attendu début 2026 et la version finale en 2027. Ces standards ne sont plus expérimentaux, ils constituent la base sur laquelle les éditeurs et les régulateurs construisent leurs exigences pour les prochaines années.

Côté français, l’ANSSI a fixé un cadre précis pour les Opérateurs d’Importance Vitale (OIV) et les Opérateurs de Services Essentiels (OSE) : un inventaire cryptographique complet (CBOM) doit être transmis avant le 31 décembre 2026, une feuille de route PQC doit être validée pour les systèmes critiques, et l’hybridation TLS devient obligatoire pour tout nouveau déploiement exposé sur Internet. L’horizon 2030 est fixé pour que les systèmes qualifiés soient entièrement compatibles post-quantique. Aux États-Unis, le calendrier CNSA 2.0 impose déjà ML-KEM sur les serveurs et navigateurs TLS depuis 2025, et ML-KEM combiné à ML-DSA sur les équipements réseau (VPN, MACsec) dès 2026.

ANSSI recommends to start transitioning with hybrid quantum-resistant cryptography as soon as possible for security products aimed at offering a long-lasting protection of information (after 2030).

ANSSI, agence nationale de la sécurité des systèmes d’information – recommandations sur le plan de migration

La menace concrète n’est pas un ordinateur quantique disponible demain. C’est la capture aujourd’hui, par un adversaire patient, de trafic chiffré qu’il stockera pour le déchiffrer plus tard, une fois la puissance de calcul nécessaire disponible. Ce scénario porte un nom dans la littérature de sécurité, “harvest now, decrypt later”, et il justifie à lui seul d’agir avant que la menace ne soit techniquement mature. Pour un DSI ou un RSSI, la question n’est plus de savoir si la migration aura lieu, mais de savoir si elle sera pilotée à froid en 2026 ou subie dans l’urgence en 2029.

Ce risque touche en priorité les secteurs qui manipulent des données à longue durée de vie. Un dossier médical, un brevet industriel ou une correspondance diplomatique gardent leur valeur bien au-delà de dix ans. Un attaquant étatique n’a donc aucune raison d’attendre qu’un ordinateur quantique existe pour commencer à collecter du trafic chiffré : il lui suffit de le stocker aujourd’hui et de patienter. C’est cette asymétrie temporelle, entre la durée de vie de la donnée et la date d’apparition d’une menace quantique mature, qui pousse l’ANSSI à fixer des échéances dès 2025-2026 plutôt qu’en 2030 directement.

Ce tutoriel vous accompagne pas à pas sur un cas concret : un serveur Node.js derrière un reverse proxy Nginx, tous deux configurés pour négocier le groupe hybride X25519MLKEM768 en TLS 1.3. Vous repartirez avec un projet complet et fonctionnel, un pipeline de vérification automatisée en CI/CD, et un modèle de document CBOM pour votre inventaire cryptographique. Chaque étape inclut la commande exacte à exécuter et la sortie attendue, pour que vous puissiez valider votre progression sans deviner si une configuration a réellement fonctionné.

ML-KEM, ML-DSA et l’hybridation expliqués simplement

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) remplace RSA et l’échange Diffie-Hellman classique pour établir une clé de session partagée. Il dérive de l’algorithme CRYSTALS-Kyber et repose sur la difficulté de résoudre certains problèmes sur des réseaux euclidiens (lattices), un problème mathématique que même un ordinateur quantique ne sait pas casser efficacement à ce jour. ML-DSA (dérivé de CRYSTALS-Dilithium) joue le même rôle que RSA-PSS ou ECDSA pour les signatures numériques. SLH-DSA, basé sur les fonctions de hachage, sert de filet de sécurité pour les cas où la robustesse des réseaux euclidiens serait un jour remise en cause.

Aucun de ces algorithmes n’est déployé seul en production aujourd’hui. La pratique standard, et la recommandation ANSSI, consiste à les combiner à un algorithme classique dans un mécanisme hybride. En TLS 1.3, cela prend la forme d’un groupe nommé X25519MLKEM768, qui associe la courbe elliptique X25519 à ML-KEM-768. Ce groupe porte le code point 0x11EC dans le registre IANA des groupes TLS pris en charge, et il est enregistré dans un brouillon de l’IETF.

This draft defines three hybrid key agreement mechanisms for TLS 1.3 – X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 – that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie-Hellman) exchange.

Groupe de travail TLS de l’IETF – draft-ietf-tls-ecdhe-mlkem

L’intérêt de l’hybridation est simple à comprendre : si une faille venait à être découverte dans ML-KEM (un algorithme encore jeune), la partie classique X25519 continue de protéger la session. Et si un ordinateur quantique suffisamment puissant venait à casser X25519, ML-KEM prend le relais. Un attaquant doit casser les deux composants pour lire le trafic, ce qui explique pourquoi ce tutoriel se concentre sur le déploiement hybride plutôt que sur du ML-KEM pur.

Le NIST a également retenu HQC comme cinquième algorithme de la famille KEM, spécifiquement pensé comme filet de secours si une faiblesse structurelle venait à toucher les réseaux euclidiens sur lesquels repose ML-KEM. Cette diversité algorithmique n’est pas un détail académique : elle reflète une leçon tirée de l’histoire de la cryptographie, où s’appuyer sur une seule famille mathématique a déjà exposé des systèmes entiers lors de la découverte tardive d’une faiblesse. Pour un projet de migration, retenez surtout que ML-KEM reste la priorité opérationnelle en 2026, HQC n’étant attendu qu’en version finale en 2027.

Prérequis : versions et outils nécessaires

Vérifiez que votre environnement correspond à ces versions avant de commencer. Le point bloquant le plus fréquent est une version d’OpenSSL antérieure à 3.5, qui ne propose ML-KEM que via un provider externe (oqs-provider), une configuration plus fragile et non recommandée en production.

OutilVersion minimaleRôle dans le tutoriel
OpenSSL3.5.0 (avril 2025) ou supérieureFournit ML-KEM, ML-DSA et SLH-DSA nativement dans le provider par défaut
Node.js22 LTS ou supérieure, liée à OpenSSL 3.5+Serveur applicatif TLS et vérification du groupe négocié
curlCompilé contre une libcurl liée à OpenSSL 3.5+Test client en ligne de commande avec l’option –curves
NginxCompilé contre OpenSSL 3.5+Reverse proxy TLS en frontal
DockerToute version récenteIsoler l’environnement de test sans toucher au système hôte

Si votre distribution Linux embarque encore OpenSSL 3.0 ou 3.1 (le cas sur beaucoup de serveurs Debian 12 ou Ubuntu 22.04 en 2026), deux options s’offrent à vous : compiler OpenSSL 3.5 depuis les sources dans un conteneur dédié, ou passer par une image Docker qui l’embarque déjà. La seconde option est largement plus rapide pour suivre ce tutoriel.

Prévoyez également un accès en écriture à votre configuration Nginx ou à votre reverse proxy équivalent si vous comptez reproduire l’étape de terminaison TLS en frontal. Si vous testez uniquement le serveur Node.js en local, vous pouvez ignorer cette partie et passer directement à la génération des clés.

Étape 1 : vérifier votre version d’OpenSSL

Commencez toujours par un diagnostic. Cette commande vous dit immédiatement si vous êtes prêt ou si une mise à niveau est nécessaire avant d’aller plus loin.

openssl version
# Sortie attendue si vous êtes prêt :
# OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)

# Si la sortie affiche 3.0.x, 3.1.x ou 3.2.x, passez par un conteneur Docker
# à jour plutôt que de recompiler sur votre système hôte

Si la version affichée est inférieure à 3.5, ne tentez pas de forcer ML-KEM sur cette installation. Le provider par défaut ne connaîtra pas l’algorithme, et vous obtiendrez une erreur du type Algorithm (ML-KEM-768 : 0) is not supported qui ne dit rien sur la cause réelle du problème.

Étape 2 : lancer un environnement Docker avec OpenSSL 3.5

Pour éviter de casser les dépendances système de votre serveur, isolez le test dans un conteneur basé sur une distribution récente qui embarque déjà OpenSSL 3.5 ou plus.

mkdir pqc-tls-demo && cd pqc-tls-demo

cat > Dockerfile <<'EOF'
FROM debian:trixie-slim
RUN apt-get update && apt-get install -y openssl nodejs npm curl nginx \
    && rm -rf /var/lib/apt/lists/*
WORKDIR /app
EOF

docker build -t pqc-tls-demo .
docker run -it --rm -p 8443:8443 pqc-tls-demo openssl version

Adaptez l’image de base à ce qui est disponible chez vous : l’essentiel est que openssl version retourne bien 3.5.x ou plus à l’intérieur du conteneur avant de passer à l’étape suivante.

Étape 3 : générer une paire de clés ML-KEM-768

OpenSSL 3.5 expose ML-KEM comme n’importe quel autre algorithme asymétrique via genpkey. Cette commande génère une paire de clés que vous pouvez inspecter et manipuler comme vous le feriez avec une clé RSA ou EC.

openssl genpkey -algorithm ML-KEM-768 -out mlkem768_private.pem
openssl pkey -in mlkem768_private.pem -pubout -out mlkem768_public.pem

# Vérifier que l'algorithme est bien reconnu et listé
openssl list -kem-algorithms | grep -i mlkem
# ML-KEM-512 @ default
# ML-KEM-768 @ default
# ML-KEM-1024 @ default

Retenez ML-KEM-768 comme le niveau de sécurité par défaut recommandé pour la majorité des usages, l’équivalent approximatif d’AES-192 en résistance. ML-KEM-1024 s’utilise pour les données à très longue durée de vie, ML-KEM-512 uniquement dans des contextes contraints où la performance prime sur la marge de sécurité.

Étape 4 : configurer un serveur Node.js avec TLS 1.3 hybride

Node.js ne réimplémente pas ML-KEM de son côté, il s’appuie entièrement sur l’OpenSSL contre lequel il a été compilé. Si votre binaire Node.js est lié à OpenSSL 3.5+, le groupe hybride est négocié automatiquement dès qu’un client compatible se connecte, sans configuration additionnelle côté groupes. Voici un serveur HTTPS minimal pour le vérifier.

// server.js
const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  minVersion: 'TLSv1.3',
};

const server = https.createServer(options, (req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Connexion sécurisée établie\n');
});

server.on('secureConnection', (socket) => {
  const info = socket.getEphemeralKeyInfo();
  console.log('Groupe négocié :', info);
  // Sortie attendue si le client supporte l'hybridation :
  // Groupe négocié : { type: 'TLSGroup', name: 'X25519MLKEM768' }
});

server.listen(8443, () => console.log('Serveur PQC sur le port 8443'));

La méthode getEphemeralKeyInfo() retourne le nom exact du groupe négocié pendant la poignée de main. C’est le seul moyen fiable de confirmer, côté applicatif, qu’une session donnée a bien basculé en mode hybride plutôt qu’en repli sur X25519 seul. Avant de lancer ce serveur, vérifiez la version d’OpenSSL à laquelle votre binaire Node.js est réellement lié, car un même numéro de version majeure de Node.js peut être packagé avec des versions d’OpenSSL différentes selon la distribution ou l’image Docker utilisée.

node -e "console.log(process.versions.openssl)"
# Doit afficher 3.5.x ou plus pour que l'hybridation fonctionne

Étape 5 : générer un certificat auto-signé pour les tests

Le certificat lui-même peut rester classique (RSA ou ECDSA) pour ce test, car c’est l’échange de clés qui devient post-quantique en priorité. La migration des signatures de certificats vers ML-DSA suit un calendrier plus long, souvent aligné sur le renouvellement naturel des autorités de certification internes.

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -keyout server-key.pem -out server-cert.pem -days 90 -nodes \
  -subj "/CN=localhost"

node server.js
# Serveur PQC sur le port 8443

Étape 6 : tester la négociation avec openssl s_client et curl

Une fois le serveur lancé, forcez le groupe hybride côté client pour confirmer que la poignée de main aboutit. Deux outils suffisent pour ce test : openssl s_client pour un diagnostic détaillé, et curl pour un test rapide en une ligne.

# Diagnostic complet avec openssl
openssl s_client -connect localhost:8443 -groups X25519MLKEM768

# Ligne à chercher dans la sortie :
# Server Temp Key: X25519MLKEM768, 3168 bits

# Test rapide avec curl (build lié à OpenSSL 3.5+)
curl -v --curves X25519MLKEM768 https://localhost:8443 -k

Si la mention X25519MLKEM768 apparaît dans la ligne “Server Temp Key”, la session est bien hybride post-quantique. Si openssl s_client retombe silencieusement sur X25519 seul, retournez à l’étape 1 : c’est le symptôme classique d’une version d’OpenSSL trop ancienne côté client ou côté serveur.

Étape 7 : configurer Nginx comme reverse proxy hybride

En production, la terminaison TLS se fait rarement directement dans Node.js. Nginx en frontal permet de centraliser la configuration cryptographique pour tous vos services applicatifs.

# /etc/nginx/sites-available/pqc-demo.conf
server {
    listen 443 ssl;
    server_name votre-domaine.fr;

    ssl_certificate     /etc/nginx/ssl/server-cert.pem;
    ssl_certificate_key /etc/nginx/ssl/server-key.pem;

    ssl_protocols       TLSv1.3;
    ssl_ecdh_curve       X25519MLKEM768:X25519:secp384r1;

    location / {
        proxy_pass https://127.0.0.1:8443;
        proxy_ssl_verify off;
    }
}

La directive ssl_ecdh_curve accepte une liste ordonnée par préférence. En plaçant X25519MLKEM768 en tête, vous demandez à Nginx de le proposer en priorité tout en gardant X25519 et secp384r1 comme repli pour les clients qui ne supportent pas encore l’hybridation, notamment certains clients API ou anciens navigateurs mobiles.

Étape 8 : construire une PKI hybride pour vos certificats internes

Pour une autorité de certification interne, ML-DSA remplace progressivement RSA ou ECDSA pour signer les certificats. Cette étape est plus lourde que l’échange de clés car elle touche à la confiance racine de votre PKI, donc traitez-la comme un chantier séparé après avoir validé l’hybridation TLS.

# Générer une clé ML-DSA pour l'autorité de certification interne
openssl genpkey -algorithm ML-DSA-65 -out ca-mldsa-key.pem
openssl req -x509 -new -key ca-mldsa-key.pem -out ca-mldsa-cert.pem \
  -days 3650 -subj "/CN=CA-Interne-PQC" -nodes

# Vérifier l'algorithme de signature du certificat généré
openssl x509 -in ca-mldsa-cert.pem -noout -text | grep "Signature Algorithm"

Ne remplacez jamais votre CA racine en production sans plan de double signature. Gardez une chaîne de confiance classique en parallèle tant que vos clients internes (postes de travail, équipements réseau, applications tierces) n’ont pas tous validé leur compatibilité avec les certificats ML-DSA.

Le nom ML-DSA-65 fait référence au niveau de sécurité intermédiaire de la famille définie dans FIPS 204, à mettre en regard de ML-DSA-44 pour des contextes moins sensibles et ML-DSA-87 pour une marge de sécurité maximale. Le choix du niveau suit la même logique que pour ML-KEM : plus le niveau est élevé, plus les signatures et les clés sont volumineuses, un compromis à arbitrer selon la sensibilité réelle de votre autorité de certification.

Étape 9 : automatiser la vérification dans votre pipeline CI/CD

Un test manuel une fois ne suffit pas. Ajoutez une vérification automatisée à chaque déploiement pour détecter une régression silencieuse, par exemple après une mise à jour d’image de base qui repasserait sur une OpenSSL plus ancienne.

# .github/workflows/pqc-check.yml
name: Verify hybrid PQC TLS
on: [push]
jobs:
  check-tls-group:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Start server
        run: docker compose up -d
      - name: Verify negotiated group
        run: |
          RESULT=$(openssl s_client -connect localhost:8443 \
            -groups X25519MLKEM768 &1 | grep "Server Temp Key")
          echo "$RESULT"
          echo "$RESULT" | grep -q "X25519MLKEM768" || exit 1

Ce job échoue explicitement si le groupe hybride n’est plus négocié, ce qui vous évite de découvrir la régression en production après un audit de conformité ou un incident.

Étape 10 : mesurer l’impact sur les performances

ML-KEM-768 alourdit la poignée de main TLS par rapport à X25519 seul, principalement à cause de la taille des clés échangées (environ 1 184 octets pour la clé publique ML-KEM-768 contre 32 octets pour X25519). En pratique, sur un lien réseau normal, ce surcoût reste de l’ordre de quelques millisecondes par nouvelle connexion et devient négligeable dès que la reprise de session TLS 1.3 (session resumption) entre en jeu, car elle évite de refaire l’échange complet à chaque requête.

# Comparer le temps de poignée de main hybride vs classique
time openssl s_client -connect localhost:8443 -groups X25519MLKEM768 \
  &1

time openssl s_client -connect localhost:8443 -groups X25519 \
  &1

Faites ce comparatif sur votre propre infrastructure plutôt que de vous fier à un chiffre générique : la latence réseau, le nombre de connexions simultanées et la charge CPU du serveur pèsent bien plus que le choix de l’algorithme lui-même dans l’expérience finale.

Pour situer les ordres de grandeur, voici la taille des clés publiques échangées selon l’algorithme. C’est cette différence de taille, et non un surcoût de calcul massif, qui explique l’essentiel du delta de latence observé sur les nouvelles connexions.

AlgorithmeTaille de la clé publiqueUsage recommandé
X25519 (classique)32 octetsComposant classique de l’hybride, déjà déployé partout
ML-KEM-512800 octetsContextes très contraints, marge de sécurité réduite
ML-KEM-7681 184 octetsNiveau par défaut recommandé pour la majorité des usages
ML-KEM-10241 568 octetsDonnées à très longue durée de vie, marge de sécurité maximale

Un ClientHello TLS 1.3 classique en X25519 pèse quelques centaines d’octets. Avec X25519MLKEM768, il grossit d’environ 1,2 kilo-octet supplémentaire. Sur une connexion fibre ou 4G/5G standard en Europe, ce delta reste imperceptible pour l’utilisateur final. Il devient significatif uniquement sur des liens très contraints (objets connectés en LPWAN, satellite) ou lorsque des milliers de nouvelles connexions TLS s’établissent chaque seconde sans reprise de session, un scénario que la mise en cache des tickets de session permet justement d’éviter.

Étape 11 : planifier le retrait progressif du legacy

L’hybridation n’est pas la destination finale, c’est une étape de transition. Documentez dès maintenant les jalons de retrait des algorithmes purement classiques, en cohérence avec votre feuille de route ANSSI si vous êtes un OIV ou un OSE : audit et hybridation TLS en 2025-2026, migration des PKI internes vers ML-DSA avant fin 2028, retrait complet du RSA seul et de l’ECDHE non hybride à l’horizon 2030 pour les systèmes qualifiés.

Consignez chaque jalon avec une date, un propriétaire et un critère de sortie mesurable (par exemple, “100 % des terminaisons TLS publiques négocient X25519MLKEM768 en priorité”). Un plan sans date de vérification reste une intention, pas un projet.

Priorisez vos services selon deux critères croisés : la sensibilité des données transportées et leur durée de vie utile. Un service qui traite des paiements ponctuels a une fenêtre de risque courte, tandis qu’un service qui archive des dossiers médicaux ou des correspondances juridiques garde une valeur d’attaque pendant des décennies. Migrez d’abord les seconds, même s’ils semblent moins critiques au quotidien d’un point de vue purement opérationnel.

Étape 12 : documenter votre inventaire cryptographique (CBOM)

Le CBOM (Cryptography Bill of Materials) recense tous les algorithmes, bibliothèques et tailles de clés utilisés dans votre système d’information. Pour les OIV et OSE français, ce document doit être transmis à l’ANSSI avant le 31 décembre 2026. Même hors de cette obligation réglementaire, un CBOM structuré reste l’outil le plus utile pour prioriser vos migrations, car il révèle souvent des dépendances cryptographiques oubliées dans des services tiers ou des bibliothèques legacy.

{
  "component": "reverse-proxy-frontal",
  "algorithm": "X25519MLKEM768",
  "algorithm_type": "hybrid-kem",
  "library": "OpenSSL 3.5.4",
  "protocol": "TLS 1.3",
  "certificate_signature": "ECDSA-P256",
  "migration_status": "hybride-actif",
  "next_review": "2027-01-15"
}

Un CBOM ne se remplit pas manuellement à l’échelle d’une infrastructure entière. Scriptez l’extraction depuis vos configurations Nginx, vos certificats et vos manifestes Kubernetes, puis consolidez le résultat dans un format structuré comme celui-ci avant de le transmettre ou de l’archiver.

Ne limitez pas cet inventaire aux composants que vous exploitez directement. Vos fournisseurs SaaS, vos API tierces et vos bibliothèques open source embarquent eux aussi des choix cryptographiques qui deviennent votre responsabilité indirecte. Demandez à vos fournisseurs critiques leur propre feuille de route post-quantique : un maillon faible chez un sous-traitant expose l’ensemble de la chaîne, y compris les données que vous pensiez avoir correctement protégées de votre côté.

Erreurs fréquentes à éviter pendant la migration

La plupart des incidents observés sur des migrations post-quantiques en 2025 et 2026 ne viennent pas d’une faille dans les algorithmes eux-mêmes, mais d’erreurs opérationnelles évitables. Voici les cinq pièges les plus fréquents rencontrés par les équipes qui déploient l’hybridation pour la première fois.

  • Déployer ML-KEM sans hybridation. C’est encore un algorithme jeune. L’ANSSI et le NIST recommandent tous deux de le combiner à un algorithme classique éprouvé, jamais de le déployer seul en production.
  • Confondre échange de clés et signature. Migrer vers X25519MLKEM768 sécurise la négociation de session, pas la signature des certificats. Ce sont deux chantiers distincts, avec ML-DSA pour le second.
  • Oublier les clients legacy. Certains clients API, objets connectés ou anciens SDK mobiles ne savent pas négocier de groupe hybride. Gardez toujours un repli classique dans votre liste de groupes plutôt que de forcer X25519MLKEM768 exclusivement.
  • Recompiler OpenSSL à la main sur un serveur de production. Une compilation manuelle mal packagée casse souvent les mises à jour de sécurité futures. Préférez une image Docker maintenue ou un dépôt de paquets officiel.
  • Ignorer la taille des paquets réseau. Les clés ML-KEM sont plus volumineuses que les clés EC classiques. Si votre infrastructure fragmente mal les paquets UDP (cas de QUIC/HTTP3 avec des MTU mal configurés), testez spécifiquement ce chemin avant la bascule.

Dépannage : 8 problèmes courants et leurs solutions

Gardez ce tableau à portée de main pendant vos premiers déploiements. La grande majorité des blocages rencontrés en pratique se résolvent en quelques minutes une fois la cause correctement identifiée, à condition de ne pas confondre un problème de version d’OpenSSL avec un problème de configuration réseau.

SymptômeCause probableSolution
Erreur “Algorithm (ML-KEM-768 : 0) is not supported”OpenSSL antérieur à 3.5 sans provider PQCMettre à jour vers OpenSSL 3.5+ ou installer oqs-provider en solution temporaire
s_client négocie X25519 au lieu du groupe hybrideLe client ou le serveur ne propose pas X25519MLKEM768 dans sa liste de groupesForcer explicitement avec l’option -groups des deux côtés et vérifier les deux versions d’OpenSSL
Node.js ne reporte aucun groupe via getEphemeralKeyInfo()Binaire Node.js lié à une OpenSSL embarquée trop ancienneVérifier avec process.versions.openssl et recompiler ou changer de distribution Node.js si besoin
Nginx refuse de démarrer après ajout de ssl_ecdh_curveNginx compilé contre une libssl sans support ML-KEMRecompiler Nginx contre OpenSSL 3.5+ ou utiliser une image Docker qui l’inclut déjà
curl ignore l’option –curveslibcurl liée à une bibliothèque TLS différente d’OpenSSL 3.5 (BoringSSL, ancienne GnuTLS)Vérifier curl -V et recompiler contre OpenSSL 3.5+ si nécessaire
Handshake TLS échoue uniquement sur mobileAncien SDK mobile sans support des groupes hybridesGarder X25519 en repli et surveiller le taux d’utilisation réel du groupe hybride par type de client
Latence anormalement élevée sur les nouvelles connexionsAbsence de reprise de session TLS 1.3 (session resumption)Activer les tickets de session ou le cache côté serveur pour éviter de refaire l’échange complet à chaque requête
Le pipeline CI/CD échoue après une mise à jour d’image de baseRégression silencieuse de la version d’OpenSSL dans l’image DockerÉpingler explicitement la version d’OpenSSL dans le Dockerfile et ajouter le test de groupe négocié en CI

Conseils avancés pour les équipes DevSecOps

Une fois l’hybridation validée sur un service pilote, quelques pratiques supplémentaires font la différence entre une migration robuste et une migration fragile. D’abord, journalisez systématiquement le groupe négocié par connexion dans vos logs applicatifs, pas seulement au niveau du reverse proxy : cela vous donne une visibilité réelle sur le taux d’adoption côté client, service par service, plutôt qu’une estimation globale peu actionnable.

Ensuite, testez le comportement de vos équilibreurs de charge et de vos WAF face aux paquets TLS plus volumineux générés par ML-KEM. Certains équipements réseau plus anciens appliquent des limites de taille sur les messages ClientHello qui n’anticipaient pas des clés post-quantiques, ce qui peut provoquer des échecs de connexion silencieux et difficiles à diagnostiquer sans capture réseau. Une capture Wireshark sur un segment de test, avant bascule en production, reste le moyen le plus rapide de repérer ce genre de blocage.

Enfin, pour les environnements soumis à NIS 2 ou DORA, alignez votre calendrier de migration PQC avec vos cycles d’audit réglementaires existants plutôt que de créer un chantier parallèle. La cryptographie post-quantique devient un critère de conformité comme un autre, autant l’intégrer dans les processus déjà en place que vos équipes connaissent.

Un dernier point mérite votre attention si vous gérez une infrastructure multi-cloud ou hybride : vérifiez que vos passerelles internes entre environnements (VPN site-à-site, tunnels IPsec, liaisons inter-datacenters) supportent elles aussi l’hybridation. Ces liaisons transportent souvent le trafic le plus sensible de l’entreprise, et elles restent fréquemment oubliées dans les premières vagues de migration qui se concentrent sur les terminaisons TLS publiques les plus visibles.

Le projet complet : structure du dépôt de référence

En rassemblant toutes les étapes précédentes, voici l’arborescence d’un projet fonctionnel que vous pouvez reproduire pour votre propre démonstration ou votre environnement de test.

pqc-tls-demo/
├── Dockerfile
├── docker-compose.yml
├── server.js
├── package.json
├── certs/
│   ├── server-key.pem
│   ├── server-cert.pem
│   ├── ca-mldsa-key.pem
│   └── ca-mldsa-cert.pem
├── nginx/
│   └── pqc-demo.conf
├── cbom/
│   └── inventory.json
└── .github/
    └── workflows/
        └── pqc-check.yml

Ce squelette couvre les trois couches d’une migration réelle : l’applicatif (Node.js), la terminaison réseau (Nginx) et la gouvernance (CBOM et CI/CD). Vous pouvez le versionner tel quel et l’étendre service par service à mesure que votre inventaire cryptographique grandit. Le fichier docker-compose.yml assemble les deux services pour un test de bout en bout en une seule commande.

# docker-compose.yml
services:
  app:
    build: .
    command: node server.js
    volumes:
      - ./certs:/app/certs
    ports:
      - "8443:8443"
  proxy:
    image: nginx:latest
    volumes:
      - ./nginx/pqc-demo.conf:/etc/nginx/conf.d/default.conf
      - ./certs:/etc/nginx/ssl
    ports:
      - "443:443"
    depends_on:
      - app

Lancez l’ensemble avec docker compose up, puis rejouez la commande openssl s_client -connect localhost:443 -groups X25519MLKEM768 de l’étape 6 contre le port 443 cette fois, pour valider que le proxy Nginx négocie bien le groupe hybride avant de transmettre la connexion à Node.js.

Foire aux questions sur la cryptographie post-quantique

ML-KEM seul suffit-il, sans hybridation ?
Non. L’ANSSI et le NIST recommandent tous deux l’hybridation tant que ML-KEM n’a pas accumulé plusieurs années de retour d’expérience en production à grande échelle. Le combiner à X25519 ne coûte presque rien et élimine le risque d’une régression de sécurité si une faille était découverte.

Quelle est la différence entre ML-KEM-768 et Kyber768 ?
Aucune différence algorithmique fondamentale. ML-KEM est le nom donné par le NIST à la version standardisée et finalisée de l’algorithme Kyber dans FIPS 203. Les anciennes implémentations qui utilisaient encore le nom “Kyber” avant août 2024 doivent être mises à jour vers la version ML-KEM finale, les paramètres ayant légèrement changé entre le candidat et le standard. Si votre code référence encore “Kyber768” quelque part, traitez-le comme une dette technique à migrer vers “ML-KEM-768” au prochain cycle de mise à jour.

Faut-il migrer les certificats vers ML-DSA immédiatement ?
Pas dans l’urgence. La priorité recommandée par l’ANSSI est l’hybridation de l’échange de clés (ML-KEM), car c’est ce qui protège contre le “harvest now, decrypt later”. La migration des signatures de certificats vers ML-DSA peut suivre un calendrier plus long, aligné sur le renouvellement naturel de votre PKI, avec une échéance à fin 2028 pour les PKI internes des OIV et OSE.

Quel est l’impact réel sur les performances ?
Le surcoût se mesure en millisecondes sur la poignée de main initiale à cause de la taille plus importante des clés ML-KEM. Avec la reprise de session TLS 1.3 activée, l’impact devient négligeable pour la majorité des connexions HTTP répétées.

Mon navigateur supporte-t-il déjà X25519MLKEM768 ?
Les versions actuelles de Chrome et de Firefox l’activent par défaut, tout comme Cloudflare côté infrastructure. Vérifiez la configuration de votre propre navigateur si vous avez un doute, certaines entreprises désactivent encore les groupes expérimentaux via des politiques de sécurité internes.

Suis-je obligé d’agir si je ne suis pas un OIV ou un OSE ?
L’obligation réglementaire stricte de l’ANSSI cible en priorité les OIV et OSE. Mais toute organisation qui traite des données à longue durée de vie (santé, propriété intellectuelle, secrets industriels) a intérêt à anticiper, car ces données interceptées aujourd’hui restent sensibles dans dix ou vingt ans. Une PME sous-traitante d’un OIV peut aussi se voir imposer des exigences contractuelles similaires par son donneur d’ordre, bien avant toute obligation légale directe.

OpenSSL 3.5 est-il une version stable pour la production ?
Oui. OpenSSL 3.5 est une version LTS (Long Term Support), maintenue jusqu’en avril 2030, ce qui en fait un choix raisonnable pour un déploiement de production plutôt qu’une version expérimentale à court terme.

Que se passe-t-il si mon client ne supporte pas du tout l’hybridation ?
Tant que vous gardez X25519 dans votre liste de groupes ordonnée, la connexion aboutit normalement en retombant sur l’algorithme classique. C’est justement l’intérêt de configurer une liste de repli plutôt que de forcer exclusivement X25519MLKEM768 : vous gagnez la protection post-quantique pour les clients compatibles sans casser la compatibilité avec les autres.

ANSSI strongly recommends to use hybrid protocols in the short and medium term.

ANSSI, agence nationale de la sécurité des systèmes d’information – recommandations sur le plan de migration

Pour aller plus loin sur les fondations théoriques, la documentation officielle du NIST détaille l’algorithme dans FIPS 203 (ML-KEM) et FIPS 204 (ML-DSA). Côté français, l’avis complet de l’ANSSI sur la migration post-quantique reste la référence à suivre pour toute feuille de route réglementaire. Les équipes qui veulent creuser l’implémentation peuvent consulter la documentation OpenSSL, la documentation du module crypto de Node.js et le guide de Cloudflare sur la cryptographie post-quantique, qui documente son propre déploiement à grande échelle.

Sur le même sujet