ETSI TR 104 239-2 V1.1.1 (2026-06)

TECHNICAL REPORT
Cyber Security (CYBER);
Quantum-Safe Cryptography (QSC);
Secure Implementation Guidance for
Key Encapsulation Mechanisms and
Digital Signature Schemes;
Part 2: ML-KEM
2 ETSI TR 104 239-2 V1.1.1 (2026-06)

Reference
DTR/CYBER-QSC-0027-2
Keywords
cyber security, key exchange,
quantum safe cryptography
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced in any form or by any means except for the purpose of implementation of standards.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2026.
All rights reserved.
ETSI
3 ETSI TR 104 239-2 V1.1.1 (2026-06)

Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Introduction . 8
5 ML-KEM interfaces . 9
5.1 Parameters . 9
5.2 Key generation . 9
5.2.1 Full key generation . 9
5.2.2 Key formats . 10
5.2.3 Seed format key generation . 10
5.3 Encapsulation . 11
5.4 Decapsulation . 11
6 General implementation considerations . 12
6.1 Perform input validation . 12
6.1.1 Encapsulation inputs . 12
6.1.2 Decapsulation inputs . 12
6.1.3 Internal algorithms . 13
6.2 Perform output validation . 14
6.2.1 Ciphertext re-encryption check . 14
6.2.2 Pairwise consistency test . 14
6.2.3 Self testing . 15
6.2.4 Public key linting . 16
6.3 Prevent leakage of intermediate values . 16
6.3.1 Zeroise intermediate values after use . 16
6.3.2 Limit external access to internal functions . 17
6.4 Handle errors gracefully . 17
6.4.1 Specified errors . 17
6.4.2 Unspecified errors . 17
6.4.3 Implicit rejection . 18
6.5 Randomness . 18
7 Side-channel and fault attack considerations . 18
7.1 Introduction . 18
7.2 Key generation . 18
7.2.1 Overview . 18
7.2.2 Timing analysis considerations . 19
7.2.3 Power analysis considerations . 19
7.2.4 Fault attack considerations . 20
7.3 Encapsulation . 21
7.3.1 Overview . 21
7.3.2 Timing analysis considerations . 21
7.3.3 Power analysis considerations . 21
7.3.4 Fault attack considerations . 22
7.4 Decapsulation . 22
7.4.1 Overview . 22
ETSI
4 ETSI TR 104 239-2 V1.1.1 (2026-06)

7.4.2 Timing analysis considerations . 23
7.4.3 Power analysis considerations . 23
7.4.4 Fault attack considerations . 23
8 Testing and formal verification considerations . 24
8.1 Testing considerations . 24
8.2 Formal verification considerations . 24
Annex A: NIST FIPS 203 algorithms . 25
A.1 Key encapsulation (external) . 25
A.2 De-randomized key encapsulation (internal only) . 25
A.3 Public-key encryption (internal only) . 25
A.4 Sampling . 25
A.5 Arithmetic . 25
A.6 Encoding . 26
Annex B: ML-KEM security properties . 27
B.1 Indistinguishability . 27
B.1.1 IND-CPA security . 27
B.1.2 IND-CCA security . 27
B.2 Binding . 28
B.2.1 Re-encapsulation attacks . 28
B.2.2 Binding properties . 29
Annex C: Hybrid ML-KEM . 31
C.1 Deployment considerations . 31
C.2 Implementation considerations . 31
Annex D: Change history . 33
History . 34

ETSI
5 ETSI TR 104 239-2 V1.1.1 (2026-06)

Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Cyber Security (CYBER).
The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.3].
The present document provides implementation guidance for the Module-Lattice-based Key Encapsulation Mechanism
(ML-KEM).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TR 104 239-2 V1.1.1 (2026-06)

1 Scope
The present document provides developers with guidance to aid the secure implementation of the quantum-safe key
encapsulation mechanism ML-KEM as specified by NIST FIPS 203 [i.5]. This highlights some potential ML-KEM
implementation hazards; identifies some side-channel and fault attack issues specific to ML-KEM; considers some
testing and formal verification aspects relevant to ML-KEM; and briefly discusses the secure usage of ML-KEM.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI TS 103 744 (V1.2.2): "CYBER; Quantum-Safe Cryptography (QSC); Quantum-safe Hybrid
Key Establishment".
[i.2] ETSI TR 103 966: "CYBER Security (CYBER); Quantum-Safe Cryptography (QSC);
Deployment Considerations for Hybrid Schemes".
[i.3] ETSI TR 104 239-1: "Cyber Security (CYBER); Quantum-Safe Cryptography (QSC); Secure
Implementation Guidance for Key Encapsulation Mechanisms and Digital Signature Schemes;
Part 1: General".
[i.4] IETF RFC 9935: "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-
Lattice-Based Key-Encapsulation Mechanism (ML-KEM)".
[i.5] NIST FIPS 203: "Module-Lattice-Based Key-Encapsulation Mechanism Standard".
[i.6] NIST SP 800-133 Rev. 2: "Recommendation for Cryptographic Key Generation".
[i.7] NIST SP 800-227: "Recommendations for Key-Encapsulation Mechanisms".
[i.8] NIST: "Automated Cryptographic Validation Test System".
[i.9] NIST: "Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation
Program".
[i.10] C. Aguilar Melchor et al.: "Hamming Quasi-Cyclic (HQC): Fourth round version". NIST Post-
Quantum Cryptography Standardization Process.
[i.11] J.B. Almeida et al.: "Formally verifying Kyber Episode V: Machine-checked IND-CCA security
and correctness of ML-KEM in EasyCrypt". CRYPTO 2024.
[i.12] R. Avanzi et al.: "CRYSTALS-Kyber: Algorithm specification and supporting documentation
(version 3.02)". NIST Post-Quantum Cryptography Standardization Process.
[i.13] D.J. Bernstein et al.: "KyberSlash: Exploiting secret-dependent division timings in Kyber
implementations". CHES 2025.
ETSI
7 ETSI TR 104 239-2 V1.1.1 (2026-06)

[i.14] J. Bos et al.: "CRYSTALS-Kyber: A CCA-secure module-lattice-based KEM". Euro S&P 2018.
[i.15] J. Bos et al.: "Masking Kyber: First- and higher-order implementations". CHES 2021.
[i.16] BSI TR-02102-1: "Cryptographic mechanisms: Recommendations and key lengths", January 2026.
[i.17] Community Cryptography Specification Project: "Project Wycheproof".
[i.18] C. Cremers, A. Dax and N. Medinger: "Keeping up with the KEMs: Stronger security notions for
KEMs and automated analysis of KEM-based protocols". CCS 2024.
[i.19] Cybersecurity & Infrastructure Security Agency, US Government: "Secure-by-Design - Shifting
the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software".
[i.20] Department of Science, Innovation and Technology, UK Government: "Software Security Code of
Practice".
[i.21] B. Gierlichs et al.: "Mutual information analysis". CHES 2008.
[i.22] C. Glénaz et al.: "Finding bugs in implementations of HQC, the fifth post-quantum standard".
[i.23] Q. Guo, T. Johansson and A. Nilsson: "A key-recovery timing attack on post-quantum primitives
using the Fujisaki-Okamoto transformation and its application on FrodoKEM". CRYPTO 2020.
[i.24] J. Hermelink, P. Pessl and T. Pöppelmann: "Fault-enabled chosen-ciphertext attacks on Kyber".
INDOCRYPT 2021.
[i.25] K. Hövelmanns and M. Kudinov: "Treating dishonest ciphertexts in post-quantum KEMs -
Explicit vs. implicit rejection in the FO transform". PQCrypto 2025.
[i.26] M.J. Kannwischer, P. Pessl and R. Primas: "Single-trace attacks on Keccak". CHES 2020.
[i.27] E. Karatsiolis et al.: "Public Key Linting for ML-KEM and ML-DSA". ACNS 2025.
[i.28] S. Nkotto: "Template and CPA side channel attacks on the Kyber/ML-KEM pair-pointwise
multiplication". IACR ePrint Archive 2025/1577.
[i.29] Post-Quantum Cryptography Alliance: "mlkem-native".
[i.30] P. Ravi et al.: "Number 'not used' once - Practical fault attack on pqm4 implementations of NIST
candidates". COSADE 2019.
[i.31] P. Ravi et al.: "On configurable SCA countermeasures against single trace attacks for the NTT".
SPACE 2020.
[i.32] S. Schmieg: "Unbindable Kemmy Schmidt: ML-KEM is neither MAL-BIND-K-CT nor
MAL-BIND-K-PK". IACR ePrint Archive 2024/523.
[i.33] Symbolic Software: "Crucible".
[i.34] T. Tosun, E. Oswald and E. Savaş: "Non-profiled higher-order side-channel attacks against lattice-
based post-quantum cryptography". IACR Communications in Cryptology, 2025.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
ETSI
8 ETSI TR 104 239-2 V1.1.1 (2026-06)

3.2 Symbols
For the purposes of the present document, the following symbols apply:
�[�:�] Sub-string � …� of the byte string � ∶= � .�
� ��� � ���
(�,�) Ordered pair of values � and �
� || � Concatenation of the byte strings � and �
� = � Return true if the values � and � are equal and false otherwise
� ← � Assign the value � to the variable �
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AES Advanced Encryption Standard
CBD Centred Binomial Distribution
CVE Common Vulnerabilities and Exposures
DPA Differential Power Analysis
ECDH Elliptic Curve Diffie-Hellman
FIPS Federal Information Processing Standard
FO Fujisaki-Okamoto
HMAC Hash-based Message Authentication Code
HQC Hamming Quasi-Cyclic
IND-CCA Indistinguishability against Chosen Ciphertext Attacks
IND-CPA Indistinguishability against Chosen Plaintext Attacks
KDF Key Derivation Function
KEM Key Encapsulation Mechanism
LWE Learning With Errors
ML-DSA Module-Lattice-based Digital Signature Algorithm
ML-KEM Module-Lattice-based Key Encapsulation Mechanism
NIST National Institute of Standards and Technology
NTT Number Theoretic Transform
PKE Public Key Encryption
PKE Public-Key Encryption
PQC Post-Quantum Cryptography
RBG Random Bit Generator
SHA Secure Hash Algorithm
SHAKE Secure Hash Algorithm Keccak
SLH-DSA Stateless Hash-based Digital Signature Algorithm
SP Special Publication
TLS Transport Layer Security
4 Introduction
The Module-Lattice-based Key Encapsulation Mechanism (ML-KEM) is a post-quantum Key Encapsulation
Mechanism (KEM) selected for standardization following the multi-year NIST Post-Quantum Cryptography (PQC)
Standardization Process. It is specified in NIST FIPS 203 [i.5] and support for ML-KEM is being integrated into
internet protocols such as TLS.
NOTE: ML-KEM is based on the CRYSTALS-Kyber submission to the NIST PQC Process [i.12], but changes
made during the development of NIST FIPS 203 [i.5] mean that it is not interoperable with Kyber.
ML-KEM received a significant amount of analysis during the NIST PQC Process, but its security also depends on the
way in which it is implemented and used. The present document builds on the general guidance in ETSI
TR 104 239-1 [i.3] to provide developers with some specific guidance to aid the secure implementation of ML-KEM:
• It describes the ML-KEM interfaces and different options for private key formats (clause 5).
ETSI
9 ETSI TR 104 239-2 V1.1.1 (2026-06)

• It extends the general implementation considerations from ETSI TR 104 239-1 [i.3] with ML-KEM specific
aspects such as input validation, consistency checks, and error handling (clause 6).
• It discusses different side-channel considerations for ML-KEM key generation, encapsulation and
decapsulation (clause 7).
• It touches on testing and formal validation for ML-KEM implementations (clause 8).
The present document also gives some background on ML-KEM security properties (annex B) and some considerations
on the use of ML-KEM in hybrid schemes (annex C).
As with ETSI TR 104 239-1 [i.3], the guidance is primarily aimed at secure implementations in software, although
some of the recommendations will also be relevant to hardware implementations. Developers implementing ML-KEM
should also ensure that they follow best practice for developing secure systems in general [i.19] and [i.20].
5 ML-KEM interfaces
5.1 Parameters
NIST FIPS 203 [i.5] specifies three approved parameter sets for ML-KEM:
• ML-KEM-512 targets security category 1, which is equivalent to key recovery for AES-128;
• ML-KEM-768 targets security category 3, which is equivalent to key recovery for AES-192; and
• ML-KEM-1024 targets security category 5, which is equivalent to key recovery for AES-256.
ML-KEM-768 is recommended as the default parameter set. ML-KEM-512 can be used in applications that require
smaller public keys or ciphertexts. ML-KEM-1024 can be used in applications that require a higher level of security.
Table 1 lists the sizes of the ML-KEM private decapsulation keys, public encapsulation keys and ciphertexts.
Table 1: ML-KEM private key, public key, ciphertext and shared secret lengths (in bytes)
Private Public Shared
Parameter set Ciphertext
decapsulation key encapsulation key secret
ML-KEM-512 1 632 800 768 32
ML-KEM-768 2 400 1 184 1 088 32
ML-KEM-1024 3 168 1 568 1 568 32

5.2 Key generation
5.2.1 Full key generation
The specification of ML-KEM key generation in NIST FIPS 203 [i.5], algorithm 19 samples a pair of 32-byte values
and deterministically generates the key pair from those values via an internal key generation function (see table 2).
ETSI
10 ETSI TR 104 239-2 V1.1.1 (2026-06)

Table 2: ML-KEM key generation interface
ML-KEM.KeyGen()
Input: None
Output: Public encapsulation key �� and private decapsulation key ��, or
Error
1. � ← RBG(32)
2. � ← RBG(32)
3.
if � = NULL or � = NULL then
4.   return Error (RBG failure)
5. end if
6. (��, ��) ← ML-KEM.KeyGen_internal(�, �) (Generate key pair from private seed)
7. return (��, ��)
5.2.2 Key formats
The ML-KEM public encapsulation key �� is a byte array that encodes a pair of values (�̂, �).
The ML-KEM private decapsulation key �� is a byte array that encodes a 4-tuple of values (�̂, ��, ℎ, �).
NOTE 1: The private decapsulation key �� contains a copy of the public encapsulation key �� as it is needed for
the re-encryption step of decapsulation (see clause 6.2.1) and it would not otherwise be possible to
re-derive �� from ��.
NOTE 2: The private decapsulation key �� separately contains the SHA3-256 hash value ℎ of the public
encapsulation key ��. This is needed when deriving the shared secret and the randomness used in the
re-encryption step of decapsulation. Although the hash can be computed from the copy of �� contained in
��, including ℎ avoids the cost of the hash computation.
NOTE 3: If an adversary can change the value of ℎ contained in the private decapsulation key, then they could
potentially construct two different ciphertexts that decapsulate to the same shared secret for different
private keys [i.32]. To avoid issues with protocols that assume a binding between the ciphertext and
shared secret, private key validation includes a check that ℎ= SHA3-256(��) (see clauses 6.1.2 and
B.2.2).
NOTE 4: The private decapsulation key �� includes a value � that is used to derive a pseudo-random shared secret
from the ciphertext when the re-encryption check fails during decapsulation (see clause 6.2.1).
NOTE 5: If an adversary can change the value of � contained in the private decapsulation key, then they could
potentially construct a single ciphertext that decapsulates to the same shared secret for two private keys
corresponding to different public keys [i.32]. This binding failure cannot be mitigated through private key
validation (see clause B.2.2).
5.2.3 Seed format key generation
ML-KEM private decapsulation keys are significantly larger than the public encapsulation keys or ciphertexts. Large
private keys could be problematic for applications where secure key storage is limited or where there are many private
keys.
Further, ML-KEM private decapsulation keys require private key validation before use to prevent certain binding
attacks (see clauses 6.1.2 and B.2.2).
As a consequence of this, NIST FIPS 203 [i.5], section 3.3 explicitly allows a 64-byte private seed to be stored and used
in place of the full private decapsulation key, provided that it is given the same level of protection as the private key.
The change to key generation is minimal (see table 3).
ETSI
11 ETSI TR 104 239-2 V1.1.1 (2026-06)

Table 3: ML-KEM seed format key generation interface
ML-KEM.SeedKeyGen()
Input: None
Output: Public encapsulation key �� and private seed ����, or
Error
1. � ← RBG(32)
2. � ← RBG(32)
3.
if � = NULL or � = NULL then
4.   return Error (RBG failure)
5. end if
6. (��, _) ← ML-KEM.KeyGen_internal(�, �) (Expand public key from private seed)
7. ���� ← (� || �)
8. return (��, ����)
It is possible to recompute the private decapsulation key from the private seed via private key expansion (see table 4).
Table 4: ML-KEM private key expansion
ML-KEM.ExpandSK(����)
Input: Private seed ����
Output:
Private key ��
1.
� ← ����[0 : 32]
2. � ← ����[32 : 64]
3. (_, ��) ← ML-KEM.KeyGen_internal(�, �) (Expand private key from private seed)
4. return ��
However, it is generally not possible to recover the private seed from the private decapsulation key. Some protocols
therefore allow the use of the private decapsulation key, the private seed, or both [i.4].
5.3 Encapsulation
The specification of ML-KEM encapsulation in NIST FIPS 203 [i.5], algorithm 20 samples a 32-byte value � and
deterministically generates a shared secret and a ciphertext that encapsulate the shared secret from � and the public
encapsulation key via an internal encapsulation function (see table 5).
Table 5: ML-KEM encapsulation interface
ML-KEM.Encaps(��)
Input: Public encapsulation key ��.
Output: Shared secret � and ciphertext �, or
Error
1. � ← RBG(32)
2. if � = NULL then
3.   return Error (RBG failure)
4. end if
5. (�, �) ← ML-KEM.Encaps_internal(��, �) (Encapsulate using random seed)
6.
return (�, �)
5.4 Decapsulation
The specification of ML-KEM decapsulation in NIST FIPS 203 [i.5], algorithm 21 simply calls an internal
decapsulation function (see table 6).
ETSI
12 ETSI TR 104 239-2 V1.1.1 (2026-06)

Table 6: ML-KEM decapsulation interface
ML-KEM.Decaps(��, �)
Input: Private decapsulation key �� and ciphertext �.
Output: Shared secret �.
1. � ← ML-KEM.Decaps_internal(��, �)
2. return �
When a private seed is used in place of the private decapsulation key, the only change to the decapsulation routine is
that it needs to expand the private seed to recover the private key before calling the internal decapsulation function (see
table 7).
Table 7: ML-KEM seed format decapsulation interface
ML-KEM.Decaps(����, �)
Input: Private seed ���� and ciphertext �.
Output: Shared secret �.
1. �� ← ML-KEM.ExpandSK(����)
2. � ← ML-KEM.Decaps_internal(��, �)
3. return �
6 General implementation considerations
6.1 Perform input validation
6.1.1 Encapsulation inputs
NIST FIPS 203 [i.5] requires validation of the public encapsulation key before it can be used in ML-KEM
encapsulation (see section 7.2). Validation of the public encapsulation key involves checking that it is a byte array of
the expected length and that the encoding of �̂ corresponds to a sequence of integers in the expected range.
EXAMPLE 1: The hash of the public key is used directly in the derivation of the shared secret (see table 8). If the
public key has not been encoded correctly, then the shared secret returned by encapsulation will
also be incorrect.
NOTE 1: These checks do not guarantee that the public encapsulation key is valid output from ML-KEM key
generation. Full validation of the public key is not possible without access to the private seed used to
generate it.
Validation of the public encapsulation key is not necessarily required every time it is used. There are some cases where
input validation might not be needed (see [i.7], section 3.2).
EXAMPLE 2: If a public encapsulation key has previously been validated and it has subsequently been stored in
a way that prevents modification, then it does not need to be validated again.
EXAMPLE 3: If a public encapsulation key has been provided by a trusted third party with assurances that it is
valid and it has subsequently been stored in a way that prevents modification, then it does not need
to be validated.
NOTE 2: If the implementation supports different ML-KEM parameter sets, then checking the length of the public
encapsulation key can prevent the key from being used with the wrong parameter set.
6.1.2 Decapsulation inputs
NIST FIPS 203 [i.5] requires validation of the private decapsulation key and ciphertext before they can be used in
ML-KEM decapsulation (see section 7.3). Validation of the private decapsulation key involves checking that it is a byte
array of the expected length and that ℎ= SHA3-256(��) for the hash value ℎ and copy of the public encapsulation key
�� encoded in the private key.
ETSI
13 ETSI TR 104 239-2 V1.1.1 (2026-06)

EXAMPLE 1: The hash value ℎ is used in decapsulation to bind the shared secret to the public encapsulation key.
Failure to check that ℎ= SHA3-256(��) can break this binding (see clauses 5.2.2 and B.2.2).
NOTE 1: These checks do not guarantee that the private decapsulation key is valid output from ML-KEM key
generation. Full validation of the private key is not possible without access to the private seed used to
generate it.
NOTE 2: Additional checks can be performed on the private decapsulation key; for example, validating the copy of
the public encapsulation key contained in the private key. However, these checks are not required by
NIST FIPS 203 [i.5]. Any issues would likely be identified by a pairwise consistency test, provided that
the public encapsulation key is also accessible (see clause 6.2.2).
Validation of the private decapsulation key is not necessarily required every time it is used. There are some cases where
input validation might not be needed (see [i.7], section 3.2).
EXAMPLE 2: An ephemeral private decapsulation key generated by the implementation and used immediately
does not need to be validated.
EXAMPLE 3: A static private decapsulation key generated by the implementation and subsequently stored in a
way that prevents modification does not need to be validated.
NOTE 3: If the implementation supports different ML-KEM parameter sets, then checking the length of the private
decapsulation key can prevent the key from being used with the wrong parameter set.
EXAMPLE 4: The private decapsulation key contains a copy of the corresponding public encapsulation key, ��,
its public hash value, ℎ, and a private value � used for implicit rejection (see clause 6.2.1). If the
private key was used with a smaller parameter set than intended, an implementation could take �
from part of the public data in the key and implicit rejection would lead to predictable shared
secrets.
Validation of the ciphertext only involves checking that it is a byte array of the expected length. This is required every
time the ciphertext is used in ML-KEM decapsulation (see [i.5], section 7.3). The ciphertext will generally have been
received by the implementation from another source to be decapsulated, and hence the examples above do not apply.
EXAMPLE 5: An implementation that accepted a longer-than-expected ciphertext and ignored the extra bytes
instead of returning an error could potentially allow an adversary to take a valid ciphertext and
create a second ciphertext that decapsulates to the same shared secret. This violates the IND-CCA
security of ML-KEM (see clause B.1.2)
EXAMPLE 6: An implementation that accepted a shorter-than-expected ciphertext and attempted to perform
decapsulation using this ciphertext instead of returning an error could potentially leak information
from memory.
NOTE 4: ML-KEM decapsulation involves a re-encryption check. When implemented correctly, any ciphertext that
passes this check is guaranteed to be valid output from ML-KEM encapsulation (see clause 6.2.1).
When a private seed is used in place of the private decapsulation key, this also needs validation before it can be used in
ML-KEM decapsulation. The only possible check is that it is a byte array of length 64 bytes.
6.1.3 Internal algorithms
The specification of ML-KEM [i.5] does not require input validation for any of the internal ML-KEM algorithms.
However, it is good practice for an implementation to perform input validation on all functions, especially if these
functions are exposed to the user, for example for testing purposes.
EXAMPLE 1: ML-KEM.KeyGen_internal ([i.5], algorithm 16) deterministically generates a key pair from two
32-byte values, � and �. Allowing key generation to use shorter byte arrays for � could potentially
lead to predictable key pairs.
EXAMPLE 2: ML-KEM.Encaps_internal ([i.5], algorithm 17) deterministically generates a shared secret and
ciphertext from the public encapsulation key �� and a 32-byte value �. Allowing encapsulation to
use shorter byte arrays for � could potentially lead to predictable shared secrets (see, for example,
CVE-2023-1732).
ETSI
14 ETSI TR 104 239-2 V1.1.1 (2026-06)

NOTE: General recommendations for input validation can be found in clause 6.2 of ETSI TR 104 239-1 [i.3].
6.2 Perform output validation
6.2.1 Ciphertext re-encryption check
The internal ML-KEM encapsulation function ([i.5], algorithm 17) derives the shared secret from a 32-byte value �
and encrypts � using the underlying public-key encryption scheme, K-PKE (see table 8).
Table 8: ML-KEM internal encapsulation function
ML-KEM.Encaps_internal(��, �)
Input: Public encapsulation key �� and 32-byte value �
Output: Shared secret � and ciphertext �
1. (�, �) ← SHA3-512(� || SHA3-256(��))
2. � ← K-PKE.Encrypt(��, �, �) (Encrypt � using randomness �)
3.
return (�, �)
K-PKE decryption is not guaranteed to return the correct ciphertext and decryption failures leak information about the
private decryption key. The ML-KEM parameter sets have been chosen to ensure that the probability of a random
decryption failure is negligible. However, it is straightforward for an adversary to perform a K-PKE key recovery attack
using malformed ciphertexts.
Consequently, after decrypting the ciphertext to produce a putative plaintext �′, the internal ML-KEM decapsulation
function ([i.5], algorithm 18) re-encrypts �′ and checks that this yields the original ciphertext. If this check fails,
decapsulation returns a pseudo-random shared secret �′′ that does not depend on the K-PKE private decryption key ��′
(see table 9).
NOTE 1: This is an implicit rejection variant of the Fujisaki-Okamoto (FO) transform (see clause B.1.2).
Table 9: ML-KEM internal decapsulation function
ML-KEM.Decaps_internal(��, �)
Input: Private decapsulation key �� and ciphertext �
Output: Shared secret �
1. (��′, ��′, ℎ, �) ← ��
2. �′ ← K-PKE.Decrypt(��′, �)
3. (�′, �′) ← SHA3-512(�′ || ℎ)
�
4.
� ← SHAKE256(� || �, 256)
5. �′ ← K-PKE.Encrypt(��′, �′, �′) (Re-encrypt �′ using randomness �′)
6. if � ≠�′ then
�
7. (Implicit rejection)
�′ ← �
8. end if
9.
return �′
An implementation of ML-KEM decapsulation that omitted the re-encryption check, or failed to implement it correctly,
could potentially allow a key recovery attack via decapsulation failures.
EXAMPLE: The NIST Round 4 reference implementation of HQC [i.10] contained two flaws which together
meant that the re-encryption check during decapsulation would aways pass, even for malformed
ciphertexts (see CVE-2024-54137 [i.22]).
NOTE 2: It is enough for an adversary to be able to detect when a failure of the re-encryption check was caused by
a K-PKE decryption failure; for example, via side-channel information (see clause 7.4).
6.2.2 Pairwise consistency test
NIST FIPS 203 [i.5] describes optional key pair validation (see section 7.1). Validation of the key pair involves
validating the public encapsulation key (see clause 6.1.1), validating the private decapsulation key (see clause 6.1.2),
and performing a pair-wise consistency test (see table 10).
ETSI
15 ETSI TR 104 239-2 V1.1.1 (2026-06)

Table 10: ML-KEM pairwise consistency test
ML-KEM.PairwiseConsistency(��, ��)
Input: Public encapsulation key �� and private decapsulation key ��
Output: Boolean, or
Error
1. � ← RBG(32)
2. if � = NULL then
3.   return Error (RBG failure)
4. end if
5. (�, �) ← ML-KEM.Encaps_internal(��,�)
6. �′ ← ML-KEM.Decaps_internal(��, �)
7.
return � =�′
Validation of the key pair is recommended by NIST FIPS 203 [i.5] when it has been provided by a third party that is not
trusted or has not given assurances that the key pair i
...