Authors: John Craig, Gregg Arquero, Richard Kisley

Introduction

The National Institute of Standards and Technology (NIST) recently completed the standardization of three of the four post-quantum cryptography algorithms. This event marks the completion of their evaluation of the submissions received after their call for post-quantum algorithms in 2016. In 2022, NIST selected four of the submissions as the winners. 

Among the four winners were the CRYSTALS-Kyber and CRYSTALS-Dilithium algorithms, which would go on to be standardized as ML-KEM (FIPS 203) and ML-DSA (FIPS 204). In the final standardization process, NIST introduced several key differences between the final specification and their Round 3 submissions.

ML-KEM differences

The Module Lattice-based Key Encapsulation Mechanism (ML-KEM) differs from its submission specification due to being a key encapsulation mechanism rather than a key encryption mechanism. Under a key encryption mechanism, an existing secret key may be specified by a user for encryption, whereas under key encapsulation, the secret key being encapsulated must be randomly generated at the time of the encapsulation operation.

The decision to utilize a key encapsulation mechanism over a key encryption mechanism was made to enhance the security of the algorithm and decrease the possibility of the plain key material being leaked from the system.

ML-DSA differences

The Module Lattice-based Digital Signature Mechanism (ML-DSA), has had its usage domains broken up into two distinct sub-mechanisms: pre-hash and pure digital signatures. When generating a pre-hashed digital signature, the user may specify the hash of the message they wish to sign which has been created before calling the signature generation mechanism. The hash may be any SHA-2 or SHA-3 message digest, although IBM recommends that the hash message strength used is aligned with the security level of the chosen ML-DSA parameter set (from ML-DSA-44, ML-DSA-65, ML-DSA-87). When generating a pure digital signature, the user must specify the entire message they wish to sign, and the hash (SHAKE-256) is generated in the course of the algorithm itself.

Originally, the NIST specification was intended to only include pure digital signature generation, however the decision was made to allow both pure and pre-hashed digital signatures, as the ability to create the message hash independently of the digital signature algorithm allows users to sign substantially larger pieces of data, such as binary executables.

This change has also introduced domain separation with unique Object Identifiers (OIDs) for the mechanisms and by pre-fixing the message that is pre-hashed (HashML-DSA) or passed to ML-DSA.Sign with a domain separation constant and a context string of up to 255 bytes. The domain separation constant is required to be the value that is unique for the 2 mechanism types, while the context string is left to the implementation to choose. An ML-DSA key pair generated for pre-hash usage is recommended by NIST to only sign pre-hashed data and vice versa for pure signatures, although this is not required. IBM strongly recommends this policy as it combines the domain separation of the message prefix with the best practice of only using a key for a single purpose - including the intended mechanism, which helps mitigate the potential for cross-mode attacks.