Le principe est simple : des données chiffrées aujourd’hui peuvent être interceptées et stockées, puis déchiffrées demain par un ordinateur quantique.
Ce que disent le NIST et l’ANSSI
- NIST : ML-KEM est l’échange de clés post-quantique standardisé (FIPS 203). Les algorithmes à clé publique vulnérables au quantique seront dépréciés après 2030 et interdits après 2035. TLS est une priorité de migration, et les configurations hybrides sont autorisées.
- ANSSI : elle recommande fortement la cryptographie hybride (classique + post-quantique) partout où une protection à long terme est nécessaire. Les données qui doivent rester confidentielles au-delà de 2030 devraient déjà être protégées par de la cryptographie post-quantique.
Pour les données à longue durée de vie, Amazon S3 prend déjà en charge le TLS hybride post-quantique, qui combine un échange de clés classique (ECDH) avec ML-KEM.
Ce qu’AWS dit de S3
- Couverture : depuis novembre 2025, tous les endpoints régionaux S3, S3 Tables et S3 Express One Zone prennent en charge l’échange de clés ML-KEM dans toutes les Régions AWS, sans surcoût.
- Côté client : S3 n’utilise le TLS post-quantique que si votre client propose ML-KEM. Le serveur ne peut pas l’activer seul : c’est une responsabilité partagée.
- SDK : les SDK récents le négocient automatiquement. Par exemple, le SDK AWS pour Java 2.x l’active par défaut après la v2.35.11 (22 octobre 2025).
- Au repos : le chiffrement côté serveur AES-256 par défaut de S3 est considéré comme résistant au quantique. Avec le PQ-TLS, les données sont couvertes en transit comme au repos.
- Tests : les handshakes hybrides sont plus lourds. AWS recommande des tests de charge et l’augmentation des délais d’expiration (y compris dans Lambda). Les proxys ou pare-feux avec inspection approfondie des paquets peuvent bloquer les messages de handshake plus volumineux.
Que faire : mettez à jour vos SDK, vérifiez que vos clients négocient réellement ML-KEM, et donnez la priorité aux données qui doivent rester secrètes au-delà de 2030.
L’atelier pratique
Le cours Skill Builder « An Overview of Post-Quantum Cryptography in AWS – Technical » n’a pas d’atelier associé, alors j’en ai construit un : un environnement CloudFormation jetable pour vérifier qu’Amazon S3 négocie le TLS hybride post-quantique (ECDH + ML-KEM) et en mesurer l’impact.
Objectif de performance
- Mesurer le coût réel en latence du TLS hybride post-quantique (X25519MLKEM768) par rapport au TLS classique (X25519) lors d’une connexion à Amazon S3.
- Séparer le coût du handshake, où les messages ML-KEM plus volumineux ont un impact, du coût des requêtes sur une connexion déjà ouverte, où il devrait être négligeable.
- Décider si le surcoût est assez faible pour activer le PQ-TLS partout sans modifier les délais d’expiration ni le comportement des applications.
Ce qui est déployé
- Un bucket S3 privé (chiffré, accès public bloqué, politique TLS uniquement).
- Une instance EC2 sans port entrant, accessible via SSM Session Manager, avec OpenSSL 3.5, AWS CLI, Java 17 et Maven.
- Des commandes prêtes à l’emploi : pq-demo, pq-bench, pq-java-bench et pq-capture, pour ne rien avoir à télécharger après le déploiement.
Ce que ça montre
- S3 négocie le groupe hybride X25519MLKEM768 en TLS 1.3.
- Surcoût du handshake mesuré d’EC2 vers S3 en eu-west-3 : environ +0,4 ms en médiane (20,6 ms en classique contre 21,0 ms en hybride).
- Aucun problème de compatibilité depuis l’intérieur d’AWS.
Limites
- Les mesures ont été faites entièrement à l’intérieur d’AWS. Les réseaux d’entreprise avec proxys, pare-feux ou inspection approfondie des paquets peuvent se comporter différemment avec des messages de handshake plus volumineux : ils méritent d’être retestés.
- Le benchmark Java exécute le mode classique en premier, donc la mise en route peut le biaiser. Fiez-vous au benchmark de handshake (pq-bench) plutôt qu’aux chiffres Java.
Mode d’emploi
- Déployez pqtls-demo-stack.yaml (CloudFormation, avec l’acquittement IAM).
- Attendez 10 à 15 minutes pour l’installation, puis connectez-vous via Session Manager.
- Lancez pq-demo, puis pq-bench –runs 30.
- Supprimez la stack à la fin (videz d’abord le bucket) pour éviter des frais inutiles.
Le kit (template, scripts et README) : https://github.com/alcabeza/pqtls-bench
Sources
- NIST IR 8547, Transition to Post-Quantum Cryptography Standards : https://csrc.nist.gov/pubs/ir/8547/final
- ANSSI, avis sur la migration vers la cryptographie post-quantique : https://messervices.cyber.gouv.fr/guides/en-follow-position-paper-post-quantum-cryptography
- ANSSI, Transition post-quantique de TLS 1.3 (fiche technique, février 2026) : https://messervices.cyber.gouv.fr/documents-guides/transition_post_quantique_tls_1_3.pdf
- AWS, Configuring hybrid post-quantum TLS for your S3 client : https://docs.aws.amazon.com/AmazonS3/latest/userguide/pqtls-how-to.html
- Annonce AWS, échange de clés TLS post-quantique sur S3 (19 novembre 2025) : https://aws.amazon.com/about-aws/whats-new/2025/11/s3-post-quantum-tls-key-exchange-endpoints/
Publié initialement en anglais sur LinkedIn, le 2 novembre 2026.
