AWS KMS Embraces the Quantum Era with ML-DSA Digital Signature Support

As quantum computing creeps closer, the cryptographic mechanisms on which today’s digital world relies are becoming more and more fragile.

In a prescient move, AWS Key Management Service (KMS) now supports ML-DSA, one of the first post-quantum digital signatures, which has become a standard under FIPS 203.

This is an important step in AWS’s broader efforts to prepare customers for the post-quantum secure future. To protect against quantum attacks, Google uses two NIST-accepted PQC algorithms in Cloud KMS. One is the ML-DSA-65 (FIPS 204), which is a lattice-based digital signature algorithm.

The other is SLH-DSA-SHA2-128S (FIPS 205), a stateless hash-based signature algorithm. These algorithms feature a quantum-attack-resistant mechanism for signing and verifying data, allowing organizations to continue using secure encryption even against powerful quantum attackers.

A Leap Toward Quantum-Resistant Cryptography

ML-DSA, or Module-Lattice-Based Digital Signature Algorithm, is one of the few standards approved by NIST for its robustness against quantum attacks.

Unlike traditional algorithms that can be broken by quantum computers (e.g., RSA or ECC), lattice-based algorithms like ML-DSA help protect your mechanisms against such risks.

This is particularly relevant to sectors with embedded cryptographic signatures in firmware, such as IoT or long-lived hardware systems, where the signatures are baked in at production, with limited or no ability to apply updates afterwards.

Thus, it is now critical to ensure that these signatures remain valid and secure in a future ecosystem with quantum computing.

What’s New in AWS KMS?

AWS KMS has released three new key specs: ML_DSA_44, ML_DSA_65, and ML_DSA_87, which you can use with the new SigningAlgorithm ML_DSA_SHAKE_256, which is post-quantum.

We wanted to quickly highlight that, like the other signing algorithms, this name includes the hash function that is used in the signature scheme to digest messages before signing or verification.

This hash function is SHAKE256, which is part of the SHA-3 family of hash functions that has become standardized and approved by NIST as part of FIPS 202.

The table below provides the specifics on these key specs, their NIST security categories, and their key sizes in bytes. Each of the ML-DSA key specs represents a compromise between security strength and resource needs.

For example, ML-DSA-44 is sufficient for applications that have security objectives that are similar to classical 128-bit encryption, and ML-DSA-65 and ML-DSA-87 provide stronger performance that have classical 192-bit and 256-bit encryption security strength, respectively.

As you increase security strength, you will see increases in key and signature sizes, so you can select the key spec that matches your security objectives and engineering limitations.

Key Spec	Security Level (NIST)	Public Key (Bytes)	Private Key (Bytes)	Signature Size (Bytes)
ML_DSA_44	Level 1 (128-bit)	1312	2560	2420
ML_DSA_65	Level 3 (192-bit)	1952	4032	3309
ML_DSA_87	Level 5 (256-bit)	2592	4896	4627

With AWS KMS Sign API, when using a RAW MessageType, the message to be signed is limited to 4096 bytes.

For message inputs that are larger than 4096 bytes, the message must first be pre-processed, outside of the AWS KMS system, into what is known as µ (mu) to produce a smaller size message for the KMS Sign API.

This mu process will pre-digest the message, requiring only the public key of the ML-DSA signing key pair before generating a message with a size of 64 bytes.

To support this launch, Amazon added a message type called EXTERNAL_MU, which can be used in either ML-DSA signing or verification calls, to identify when a message has gone through pre-processing that used µ (mu) before being submitted to AWS KMS.

Availability and Use Cases

The ML-DSA feature is currently available in the AWS US West (N. California) and Europe (Milan) regions, with a wider commercial roll-out to follow in the coming days.

This feature is particularly useful to manufacturers of firmware and hardware who embed cryptographic roots of trust during manufacturing, and cannot update them after implementation.

It is also useful to software developers and enterprises signing applications or documents that require long-term validity, and organisations that are preparing for compliance with post-quantum cryptographic standards.

More importantly, by supporting ML-DSA, AWS KMS opens the door to these use cases, believing that the signature integrity will carry far into the quantum future, without having to completely revamp their infrastructure.

Conclusion

The addition of ML-DSA support to AWS KMS is evidence of AWS’s ongoing leadership in readiness for a post-quantum future.

With this release, organisations are now able to begin deploying and testing quantum-resistant cryptographic solutions using their trusted tools and APIs.

This represents an important milestone for any party interested in securing their sensitive digital assets for the foreseeable future, now and even well beyond current cryptographic threats.

Search