Trois petits environnements à jeter après usage, pour la compétence 2.2.4 de l’examen AWS Certified Solutions Architect – Professional (SAP-C03) : ML-KEM (FIPS 203) pour l’échange de clés sur S3 et sur les ALB, ML-DSA (FIPS 204) pour les signatures dans KMS.
Ce que je retiens : ça fonctionne déjà, ça coûte peu, et il reste toujours une décision à prendre de votre côté.
S3 : ML-KEM en TLS hybride (ECDH + ML-KEM)
La documentation décrit ce que le client doit faire : proposer l’échange hybride. Avec le SDK Java 2.x, il faut le client CRT, et c’est actif par défaut après la version 2.35.11. La démo vérifie la négociation hybride et mesure la latence : handshake X25519 contre X25519MLKEM768, puis benchmark Java avec et sans PQ-TLS.
Résultat : le surcoût médian du handshake est d’environ +0,4 ms (20,6 ms en classique contre 21,0 ms en hybride, sur 30 handshakes par mode, EC2 vers S3 en eu-west-3). L’écart est dans le bruit de mesure.
Dépôt : https://lnkd.in/ebmcYEMv
KMS : signatures ML-DSA
Mesuré depuis une t3.medium à Paris, 5 séries de 200 appels. Signer coûte environ 1,8 ms de plus qu’en ECDSA P-256 (9,04 contre 7,25 ms au p50). La vérification en local est même plus rapide (1,20 contre 2,15 ms). Le vrai prix, ce sont les tailles : signature de 3 309 octets contre 71, clé publique de 1 974 contre 91.
Dépôt : https://lnkd.in/eVxvf8WH
ALB : politiques TLS post-quantiques
Trois listeners, deux politiques PQ et une classique. Un client qui propose ML-KEM obtient un échange hybride (X25519MLKEM768 par exemple). Un client qui ne le propose pas passe quand même, en x25519 : une politique PQ ajoute une capacité, elle ne l’impose pas. Seule une version de TLS peut être refusée. Surcoût du handshake hybride : de l’ordre d’une fraction de milliseconde, avec un seul client dans la même Région.
Dépôt : https://lnkd.in/eA2hc8Qr
Ce que j’en tire pour l’examen et pour le terrain
- ML-KEM protège la confidentialité des échanges contre « récolter maintenant, déchiffrer plus tard ». ML-DSA protège l’authenticité, avec des signatures bien plus grosses.
- Rien n’est vraiment automatique : choisir la politique ou activer le client, puis vérifier dans les journaux qui est encore en classique.
Un détail technique sur la démo ALB
Le certificat auto-signé est généré dans le template lui-même, en Python pur, parce que je voulais un seul template CloudFormation autonome, sans bucket de packaging ni layer. Le code en ligne d’une Lambda est limité à 4 096 caractères et la bibliothèque cryptography n’est pas fournie. La fonction fait tout à la main : clé RSA 2048, certificat X.509 encodé en DER, signature SHA-256, puis import dans ACM. Le code est compressé dans le template (environ 3 200 caractères).
Sources (documentation AWS)
- S3, PQ-TLS côté client : https://lnkd.in/enFnf83d
- KMS, signatures ML-DSA (annonce) : https://lnkd.in/eWNT7B8C
- KMS, créer des signatures ML-DSA : https://lnkd.in/er9w-Hy9
- ALB, politiques de sécurité : https://lnkd.in/ex7giDyy
- ALB et NLB, échange de clés post-quantique : https://lnkd.in/ec-jyWv3
- Post-Quantum Cryptography chez AWS : https://lnkd.in/eVq93kYj
Publié initialement sur LinkedIn, novembre 2026.
