Si vous préparez l’examen AWS SAP-C03, vous croiserez ces deux acronymes. Compétence 2.2.4 : concevoir des stratégies de cryptographie post-quantique (par exemple avec AWS KMS et ML-DSA, Module-Lattice Digital Signature Algorithm, ou ML-KEM, Module-Lattice-Based Key-Encapsulation Mechanism).
- FIPS 203 est le standard de ML-KEM, pour l’établissement de clés (anciennement CRYSTALS-Kyber).
- FIPS 204 est le standard de ML-DSA, pour les signatures numériques (anciennement CRYSTALS-Dilithium).
ML-KEM, c’est le secret
Il permet à deux parties de s’accorder sur une clé partagée, de sorte que personne à l’écoute ne puisse lire leurs échanges, même quelqu’un qui les enregistre aujourd’hui en espérant les casser plus tard avec un ordinateur quantique. Sur AWS, on le retrouve dans le TLS hybride (échange de clés classique et post-quantique combinés) sur des endpoints comme S3, KMS, ACM et Secrets Manager, et KMS propose désormais aussi des clés ML-KEM. Une subtilité : le serveur ne l’utilise que si votre client le demande. Mettre à jour vos SDK, c’est donc à vous.
ML-DSA, c’est la confiance
C’est une signature numérique : elle prouve qui a signé un code, un jeton ou un certificat, et que rien n’a changé depuis. Dans KMS, la clé privée reste à l’intérieur du service, et AWS Private CA le prend également en charge. Le prix à payer, c’est la taille : une signature fait 3 309 octets, contre 71 en ECDSA.
Lequel en premier ?
Le secret, parce qu’un trafic chiffré volé peut attendre des années avant d’être cassé. Les signatures comptent surtout pour ce qui doit rester digne de confiance longtemps, comme les firmwares ou les certificats racines. L’un ne remplace pas l’autre, et les données au repos chiffrées en AES-256 sont déjà considérées comme résistantes au quantique.
La démo
Pour mesurer le coût moi-même, j’ai construit une démo jetable. Un template CloudFormation crée deux clés KMS (ML-DSA-65, plus une ECDSA P-256 classique pour comparer), une instance EC2 sans port ouvert et un petit programme Java. Il signe un message, vérifie la signature dans KMS puis hors ligne dans le JDK, confirme qu’un message modifié est rejeté, teste le mode EXTERNAL_MU pour les messages de plus de 4 Ko, puis chronomètre le tout. Quatre scripts bash vérifient l’installation et la configuration KMS, lancent les tests fonctionnels et le benchmark.
L’environnement : un petit VPC et une instance EC2 (Amazon Linux 2023, sans port entrant, accès SSM) qui installe le JDK 25 et Maven, compile la démo Java intégrée, l’exécute et enregistre les résultats. Les scripts de vérification et de benchmark sont intégrés eux aussi (/opt/kms-mldsa-demo/scripts).
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), et 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 octets contre 91.
Code : https://lnkd.in/eVxvf8WH
Sources
- NIST FIPS 203 : https://lnkd.in/eXQErqSS
- NIST FIPS 204 : https://lnkd.in/ep6eTKgE
- AWS, cryptographie post-quantique : https://lnkd.in/evfw8X8y
- KMS ML-DSA : https://lnkd.in/erN8X2Dk
- KMS Encapsulate : https://lnkd.in/eQXfBXwv
- S3 PQ-TLS : https://lnkd.in/eSfFpGAu
Publié initialement en anglais sur LinkedIn, le 3 novembre 2026.
