ML-KEM Overview

Table of contents
  1. FIPS-203 ML-KEM
  2. ML-KEM advantages over classical KEM
    1. FIPS 203 applications
  3. NIST’s Known Answer Tests (KAT)
  4. Leveraging ML-KEM and True Entropy
  5. ML-KEM - Parameter set summary
  6. API overview
  7. Example

FIPS-203 ML-KEM

FIPS 203 is the Module-Lattice-Based Key-Encapsulation Mechanism Standard, developed by the National Institute of Standards and Technology (NIST). It specifies the ML-KEM algorithms, derived from the CRYSTALS-KYBER submission, which are designed for key generation, encapsulation, and decapsulation. These algorithms are part of a broader effort to create cryptographic systems that can resist attacks by quantum computers.

The primary focus of FIPS 203 is to provide secure, quantum-resistant methods for establishing shared secret keys between two parties communicating over a public channel. This is achieved through the use of ML-KEM, which is based on the computational difficulty of the Module Learning with Errors problem. The standard specifies three parameter sets for ML-KEM: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, each offering different levels of security and performance

FIPS 203 aims to provide sufficient information for implementing ML-KEM in a manner that can pass validation through the Cryptographic Module Validation Program (CMVP). This ensures that implementations of ML-KEM adhere to rigorous security standards and are suitable for use in protecting sensitive information across various applications

ML-KEM advantages over classical KEM

  • ML-KEMs are designed to be quantum-secure, meaning they offer protection against potential attacks by quantum computers, which pose significant threats to traditional cryptographic systems In contrast, classical KEMs such as those based on RSA or ECC are vulnerable to quantum attacks, as quantum algorithms like Shor’s algorithm can efficiently break them.
  • ML-KEM, particularly the CRYSTALS-Kyber variant, balances performance with security. It supports various parameter sets that provide different levels of security, ranging from ML-KEM-512 with security equivalence to AES-128, to ML-KEM-1024, equivalent to AES-256. This flexibility allows it to cater to different security requirements and resource constraints. Classical KEMs often do not provide such a wide range of parameter sets, limiting their adaptability to different security needs.

FIPS 203 applications

FIPS 203, which standardizes Module-Lattice-based Key-Encapsulation Mechanisms (ML-KEM), has a variety of applications across multiple domains. Given its quantum-resistant properties, its primary utility is in securing communications and data against potential quantum computing threats. Here are some specific applications of FIPS 203:

  • Integrate ML-KEM into Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols to ensure encrypted communication channels are secure against quantum attacks.
  • Use ML-KEM to secure connections in Virtual Private Networks (VPNs), ensuring that remote communications are protected.
  • Secure communication between IoT devices and central hubs using ML-KEM to prevent eavesdropping and unauthorized access.
  • Enhance the security of online transactions and account management by using ML-KEM to protect sensitive financial data.
  • Secure private keys and transactions in cryptocurrency systems to prevent theft and tampering.
  • Use ML-KEM to secure classified communications, ensuring that sensitive governmental and military information remains confidential.

NIST’s Known Answer Tests (KAT)

The TQ42 Cryptography ML-KEM algorithm implementation has successfully passed the Known Answer Tests (KAT) provided by NIST. This confirms that the algorithm performs reliably as anticipated. For those interested in a deeper dive into the specifics of these tests, they are available for review.

Leveraging ML-KEM and True Entropy

The customization of the ML-KEM algorithm within TQ42 Cryptography is designed to work in synergy with true entropy, sourced from the Single Photon Quantum Random Number Generator (QRNG). This technology ensures that the randomness required for cryptographic keys is of the highest quality, providing unparalleled security for company data. Since the effectiveness of any cryptographic algorithm heavily relies on the randomness of its keys, incorporating QRNG-derived true entropy with TQ42’s customized ML-KEM algorithm ensures that your company’s sensitive information is safeguarded in the most robust manner possible.

ML-KEM - Parameter set summary

  • ML-KEM-1024 - security category 5.
  • Encapsulation key - 1568 bytes
  • Decapsulation key - 3168 bytes
  • Ciphertext - 1568 bytes
  • Shared secret key - 32 bytes

API overview

To include the necessary library, please refer to the Getting Started Guide. After following the guide, include the pqc/ml-kem.h header in your code. All Key Exchange Mechanism algorithms have a unified API. For ML-KEM, you can set the algorithm to work using the constant PQC_CIPHER_ML_KEM. To learn about all the available methods for Key Exchange Mechanism APIs, visit the KEM API Overview page.

Example

Code

#include <cstring>
#include <iostream>

#include <pqc/aes.h>
#include <pqc/ml-kem.h>

/*
Example of Key exchange mechanism using asymmetric encryption.
Algorythms KYBER, ML-KEM, McEliece are used similarly.
Alice and Bob create their key pairs. Public keys and encoded message are shared
Message is encoded  and shared from Alice to Bob with PQC_kem_encode_secret
Message is decoded by Bob with PQC_kem_decode_secret


This example for ML-KEM system
*/

int main()
{
    // Bob's private and public keys
    pqc_ml_kem_private_key priv_bob;
    pqc_ml_kem_public_key pub_bob;

    // buffers to store shared info (PQC_ML_KEM_SHARED_LENGTH == PQC_AES_KEYLEN == 32 bytes)
    uint8_t shared_alice[PQC_ML_KEM_SHARED_LENGTH], shared_bob[PQC_ML_KEM_SHARED_LENGTH];

    pqc_ml_kem_message message;

    const size_t info_size = 10;
    // party_a_info (in): additional data to be used for key derivation
    uint8_t party_a_info[info_size] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};

    size_t key_pair = PQC_generate_key_pair(
        PQC_CIPHER_ML_KEM, (uint8_t *)&pub_bob, sizeof(pub_bob), (uint8_t *)&priv_bob, sizeof(priv_bob)
    );
    if (key_pair != PQC_OK)
        std::cout << "ERROR!!! Key pair hasn't been successfully created" << std::endl;

    // context of algorithm object
    CIPHER_HANDLE bob = PQC_init_context(PQC_CIPHER_ML_KEM, (uint8_t *)&priv_bob, sizeof(priv_bob));
    if (bob == PQC_BAD_CIPHER)
        std::cout << "ERROR!!! During context creation: Unknown/unsupported cipher" << std::endl;

    // To derive shared key to be used for data encryption and message for other party call
    size_t encode = PQC_kem_encode(
        PQC_CIPHER_ML_KEM, (uint8_t *)&message, sizeof(message), party_a_info, info_size, (uint8_t *)&pub_bob,
        sizeof(pub_bob), (uint8_t *)&shared_alice, sizeof(shared_alice)
    );

    // encode should be equal to PQC_OK
    if (encode != PQC_OK)
        std::cout << "ERROR!!! Secret hasn't been successfully encoding" << std::endl;

    //(Bob) To derive shared key from message and private key
    size_t decode = PQC_kem_decode(
        bob, (uint8_t *)&message, sizeof(message), party_a_info, info_size, (uint8_t *)&shared_bob, sizeof(shared_alice)
    );

    // decode shoul be equal to PQC_OK
    if (decode != PQC_OK)
        std::cout << "ERROR!!! Secret hasn't been successfully decoded" << std::endl;

    // Decoded message on the Bob's side should be equal to the message shared by Alice
    //(PQC_ML_KEM_SHARED_LENGTH == PQC_AES_KEYLEN == 32 bytes)

    if (memcmp(shared_bob, shared_alice, PQC_AES_KEYLEN) != 0)
        std::cout << "ERROR!!! Messages are not equal" << std::endl;

    PQC_close_context(bob);

    return 0;
}

© Copyright 2024, Terra Quantum AG.