ETSI TR 104 239-1 V1.1.1 (2026-03)

Cyber Security (CYBER); Quantum-Safe Cryptography (QSC); Secure Implementation Guidance for Key Encapsulation Mechanisms and Digital Signature Schemes; Part 1: General

DTR/CYBER-QSC-0027-1

General Information

• Status: Not Published
• Technical Committee: CYBER QSC - Quantum-Safe Cryptography
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 25-Mar-2026
• Completion Date: 27-Mar-2026

Standards Content (Sample)

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

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

Tel.: [phone]  Fax: [phone]

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 or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
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-1 V1.1.1 (2026-03)
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 . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 9
4 Introduction . 9
5 Interfaces . 10
5.1 Key encapsulation mechanisms . 10
5.1.1 Key encapsulation interface . 10
5.1.2 Errors . 10
5.1.3 Decapsulation failures . 11
5.2 Digital signature schemes . 11
5.2.1 Digital signature interface . 11
5.2.2 Errors . 12
5.2.3 Pre-hashing . 12
5.2.4 Context strings . 13
6 Best practice guidance . 13
6.1 Reuse existing implementations . 13
6.2 Perform input validation . 14
6.2.1 Check input formats . 14
6.2.2 Check cryptographic inputs . 14
6.3 Perform output validation . 15
6.3.1 Include consistency checks . 15
6.3.2 Use expected output formats . 15
6.4 Prevent leakage of intermediate values . 15
6.4.1 Zeroise intermediate values after use . 15
6.4.2 Limit access to intermediate functions . 16
6.5 Handle errors gracefully . 16
6.5.1 Include specified error handling . 16
6.5.2 Avoid leaking information through errors . 17
6.5.3 Indicate the severity of errors . 17
6.6 Use good randomness . 17
6.6.1 Use a secure random bit generator . 17
6.6.2 Use good entropy . 17
6.6.3 Perform de-randomisation correctly . 18
7 Side-Channels and Fault Attacks . 18
7.1 Introduction . 18
7.1.1 Concept . 18
7.1.2 Physical Access . 19
7.1.3 Duration . 19
7.1.4 Control . 19
7.2 Timing Analysis . 19
7.2.1 Concept . 19
7.2.2 Secret-Dependent Branching . 20
7.2.3 Variable Time Operations . 20
7.2.4 Secret-Dependent Memory Addressing . 20
ETSI
4 ETSI TR 104 239-1 V1.1.1 (2026-03)
7.2.5 Mitigations . 20
7.3 Power and EM Analysis . 21
7.3.1 Concept . 21
7.3.2 Mitigations . 22
7.3.3 Randomisation . 22
7.3.4 Masking . 22
7.4 Fault Attacks . 23
7.4.1 Concept . 23
7.4.2 Mitigations . 23
8 Testing and Formal Verification . 24
8.1 Introduction . 24
8.2 Testing . 24
8.2.1 Concept . 24
8.2.2 Benefits and Limitations  . 25
8.3 Functional Correctness  . 25
8.3.1 Concept . 25
8.3.2 Benefits and limitations  . 26
8.4 Memory-safety and Type-safety . 26
8.4.1 Concept . 26
8.4.2 Benefits and Limitations  . 27
History . 28

ETSI
5 ETSI TR 104 239-1 V1.1.1 (2026-03)
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. ®
BLUETOOTH is a trademark registered and owned by Bluetooth SIG, Inc.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Cyber Security (CYBER).
The present document is part 1 of a multi-part deliverable covering implementation guidance for quantum-safe key
encapsulation mechanisms and digital signature schemes, as identified below:
Part 1: "General";
Part 2: "ML-KEM";
Part 3: "ML-DSA";
Part 4: "SLH-DSA".
Later parts of this multi-part deliverable will provide implementation guidance for specific algorithms, building on the
general guidance provided in the present document.
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-1 V1.1.1 (2026-03)
1 Scope
The present document provides developers with general guidance to aid the secure implementation of quantum-safe
algorithms. This includes an overview of the interfaces and expected security properties of quantum-safe algorithms;
some general good practice guidance for cryptographic implementations; some background on side-channel and fault
attacks; and a brief discussion of testing and formal verification.
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 EN 303 645: "CYBER; Cyber Security for Consumer Internet of Things: Baseline
Requirements".
[i.2] ETSI TR 104 239-2: "Cyber Security (CYBER); Quantum-Safe Cryptography (QSC); Secure
Implementation Guidance for Key Encapsulation Mechanisms and Digital Signature Schemes;
Part 2: ML-KEM".
[i.3] ETSI TR 104 239-3: " Cyber Security (CYBER); Quantum-Safe Cryptography (QSC); Secure
Implementation Guidance for Key Encapsulation Mechanisms and Digital Signature Schemes;
Part 3: ML-DSA".
[i.4] ETSI TR 104 239-4: " Cyber Security (CYBER); Quantum-Safe Cryptography (QSC); Secure
Implementation Guidance for Key Encapsulation Mechanisms and Digital Signature Schemes;
Part 4: SLH-DSA".
[i.5] IRTF RFC 7748: "Elliptic Curves for Security".
[i.6] IETF RFC 8017: "PKCS #1: RSA cryptography specifications version 2.2".
[i.7] IRTF RFC 8032: "Edwards-Curve Digital Signature Algorithm (EdDSA)".
[i.8] IRTF RFC 9180: "Hybrid Public Key Encryption".
[i.9] IRTF RFC 9474: "Blind RSA Signatures".
[i.10] ISO/IEC 14888-3:2018: "Information technology. Security techniques. Digital signatures with
appendix - Discrete logarithm based mechanisms".
[i.11] ISO/IEC 18033-2:2006: " Information technology. Security techniques. Encryption algorithms -
Asymmetric ciphers".
[i.12] NCSC: "Timelines for migration to post-quantum cryptography".
[i.13] NIST FIPS 186-5: "Digital Signature Standard (DSS)".
ETSI
7 ETSI TR 104 239-1 V1.1.1 (2026-03)
[i.14] NIST FIPS 203: "Module-Lattice-Based Key-Encapsulation Mechanism Standard".
[i.15] NIST FIPS 204: "Module-Lattice-Based Digital Signature Standard".
[i.16] NIST FIPS 205: "Stateless Hash-Based Digital Signature Standard".
[i.17] NIST SP 800-56A Rev. 3: "Recommendation for Pair-Wise Key-Establishment Schemes Using
Discrete Logarithm Cryptography".
[i.18] NIST SP 800-56B Rev. 2: "Recommendation for Pair-Wise Key-Establishment Using Integer
Factorization Cryptography".
[i.19] NIST SP 800-89: "Recommendation for Obtaining Assurances for Digital Signature Applications".
[i.20] NIST: SP 800-90 Series.
[i.21] NIST: "Automated Cryptographic Validation Test System".
[i.22] NIST: "Cryptographic Algorithm Validation Program (CAVP)".
[i.23] NIST: "Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-
Quantum Cryptography".
[i.24] J. B. Almeida et al.: "Formally verifying Kyber Episode IV: Implementation correctness". IACR
Transactions on Cryptographic Hardware and Embedded Systems, 2023(3), p164-193. 2023.
[i.25] M. Barbosa et al.: "SoK: Computer-aided cryptography", IEEE Symposium on Security and
Privacy (SP), p777-795. 2021.
[i.26] G. Becker et al.: "Test Vector Leakage Assessment (TVLA) methodology in practice".
International Cryptographic Module Conference 2013.
[i.27] R. Benadjila et al.: "Deep learning for side-channel analysis and introduction to ASCAD
database". Journal of Cryptographic Engineering Volume 10 (2020), p163-188. 2020.
[i.28] D. J. Bernstein et al.: "KyberSlash: Exploiting secret-dependent division timings in Kyber
implementations". IACR Transactions on Cryptographic Hardware and Embedded
Systems, 2025(2), p209-234. 2025.
[i.29] E. Biham and A. Shamir: "Differential fault analysis of secret key cryptosystems". Advances in
Cryptology - CRYPTO' 97. Lecture Notes in Computer Science, vol 1294. 1997.
[i.30] G. Camurati et al.: "Screaming channels: When electromagnetic side channels meet radio
transceivers". CCS '18: Proceedings of the 2018 ACM SIGSAC Conference on Computer and
Communications Security, p163-177. 2018.
[i.31] Cybersecurity & Infrastructure Security Agency, US Government: "Secure-by-Design - Shifting
the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software".
[i.32] Department of Science, Innovation and Technology, UK Government: "Software Security Code of
Practice".
th
[i.33] fail0verflow: "Console hacking 2010". 27 Chaos Communication Congress, 2010.
[i.34] A. Genêt: "On Protecting SPHINCS+ Against Fault Attacks". IACR Transactions on
Cryptographic Hardware and Embedded Systems, p80-114. 2023.
[i.35] M. Hastings et al.: "Weak keys remain widespread in network devices". Proceedings of the 2016
Internet Measurement Conference (IMC 16), p49-63. 2016.
[i.36] N. Heninger et al.: "Mining your Ps and Qs: Detection of widespread weak keys in network
st
devices". 21 USENIX Security Symposium (USENIX Security 12), p205-220.
[i.37] X. Hou et al.: "Fully automated differential fault analysis on software implementations of block
ciphers". IACR Transactions on Cryptographic Hardware and Embedded Systems, 2019(3), p1-29.
2019.
ETSI
8 ETSI TR 104 239-1 V1.1.1 (2026-03)
[i.38] J. Kilgallin and R. Vasko: "Factoring RSA keys in the IoT era". 2019 First IEEE International
Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS-ISA),
p184-189. 2019.
[i.39] Y. Kim et al.: "Flipping bits in memory without accessing them: an experimental study of DRAM
disturbance errors". ACM SIGARCH Computer Architecture News, Volume 42, Issue 3,
p361-372.
[i.40] P. Kocher, J. Jaffe and B. Jun: "Differential power analysis". Advances in Cryptology - CRYPTO'
99. Lecture Notes in Computer Science, vol 1666. 1999.
[i.41] A. K. Lenstra et al.: "Public keys". Advances in Cryptology – CRYTPO 2012, 626-642.
[i.42] N. Madden: "CVE-2022-21449: Psychic Signatures in Java".
[i.43] J. Manger: "A chosen ciphertext attack on RSA Optimal Asymmetric Encryption Padding (OAEP)
as standardized in PKCS #1 v2.0". Advances in Cryptology - CRYPTO 2001, p230-238. 2001.
[i.44] J. Mattsson, E. Thormaker and S. Ruohomaa: "Hedged ECDSA and EdDSA signatures (work in
progress)". IRTF Internet-Draft, draft-irtf-cfrg-det-sigs-with-noise-05.
[i.45] D. McCann, E. Oswald and C. Whitnall: "Towards practical tools for side channel aware software
engineering: 'Grey box' modelling for instruction leakages". Proceedings of the 26th USENIX
Security Symposium. 2017.
[i.46] Mozilla: "Cryptofuzz".
[i.47] B. Nassi et al.: "Video-Based cryptanalysis: Extracting cryptographic keys from video footage of a
th
device's power LED captured by standard video cameras". Proceedings - 45 IEEE™ Symposium
on Security and Privacy, p2442-2440. 2024.
[i.48] M. Polubelova et al.: "HACLxN: Verified generic SIMD crypto (for all your favorite platforms)".
Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security,
p899-918. 2020.
[i.49] Post-Quantum Cryptography Alliance: "mlkem-native".
[i.50] T. Roche: "EUCLEAK side-channel attack on the YubiKey 5 series (Revealing and breaking
Infineon ECDSA implementation on the way)". Proceedings - IEEE Symposium on Security and
Privacy, p4026-4043. 2025.
[i.51] C. Thuillet, P. Andouard and O. Ly: "A smart card power analysis simulator". 2009 International
Conference on Computational Science and Engineering, p847-852. 2009.
[i.52] Tromer, E., Osvik, D.A. & Shamir, A.: "Efficient Cache Attacks on AES, and Countermeasures".
Journal of Cryptology Issue 23, p37–71. 2010.
[i.53] P.W. Shor: "Algorithms for quantum computation: discrete logarithms and factoring". Proceedings
th
35 Annual Symposium on Foundations of computer Science, 1994.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
For the purposes of the present document, the following symbols apply:
ct Ciphertext
ETSI
9 ETSI TR 104 239-1 V1.1.1 (2026-03)
m Message
par Parameter set
pk Public key
sk Private key
ss Shared secret
σ Signature
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
DHKEM Diffie-Hellman Key Encapsulation Mechanism
DSS Digital Signature Scheme
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EdDSA Edwards-curve Digital Signature Algorithm
KAS Key Agreement Scheme
KEM Key Encapsulation Mechanism
ML-KEM Module-Lattice-based Key Encapsulation Mechanism
NCSC National Cyber Security Centre
NIST National Institute of Standards and Technology
RSA Rivest-Shamir-Adleman
RSAKPG RSA Key-Pair Generation
RSASVE RSA Secret-Value Encapsulation
4 Introduction
Traditional public-key algorithms such as RSA, Elliptic Curve Diffie-Hellman (ECDH) and the Elliptic Curve Digital
Signature Algorithm (ECDSA) are known to be vulnerable to quantum attacks using Shor's algorithm [i.53]. In response
to this, the US National Institute of Standards and Technology (NIST) are currently standardising the next generation of
public-key algorithms [i.23]. These algorithms include numerous Key Encapsulation Mechanisms (KEMs) and Digital
Signature Schemes (DSSs).
To prevent the new standardized algorithms being vulnerable to quantum attacks such as Shor's algorithm, their
cryptographic security relies on different mathematical problems to their predecessors. The mathematics can be more
complex to implement than the traditional algorithms, and careful consideration will be needed to avoid introducing
vulnerabilities based on subtleties in the new standards.
Secure implementations of quantum-safe cryptographic algorithms are only one small component of a larger quantum-
safe system. It is important to also consider the way in which the algorithms are used in protocols and to follow current
best practice in quantum-safe protocol standards. Introducing quantum-safe algorithms to a secure system is a
mitigation to one cyber security threat, but it is important to also ensure other cyber security risks are not created during
the transition [i.12]. Therefore, developers implementing quantum-safe algorithms should also ensure they follow best
practice for developing secure systems in general [i.32], [i.31].
The present document provides developers with general guidance to aid the secure implementation of quantum-safe
algorithms. Many of the principles are not unique to quantum-safe cryptography, and so several illustrative examples
are drawn from traditional cryptography. The guidance is primarily aimed at secure implementations in software,
although many of the recommendations are also relevant for hardware implementations. To begin, the present document
describes the interfaces and general security properties required for quantum-safe algorithms. It then outlines general
good practice guidance for secure implementations of cryptographic algorithms, such as validation of inputs and
outputs, error handling, and the use of good randomness.
The present document then provides some background about side-channel and fault attacks and describes possible
mitigations for each class of attack. Finally, it presents an overview of testing and formal verification considerations for
secure implementations. In particular, it emphasises the need to use a rigorous threat model to consciously decide the
extent to which formal verification or side-channel mitigations should be applied to an implementation.

ETSI
10 ETSI TR 104 239-1 V1.1.1 (2026-03)
5 Interfaces
5.1 Key encapsulation mechanisms
5.1.1 Key encapsulation interface
A Key Encapsulation Mechanism (KEM) consists of a collection of parameter sets and three algorithms:
• KEM.KeyGen
Input:  Parameter set par.
Output: Public encapsulation key pk and private decapsulation key sk, or an error.
• KEM.Encaps
Input:  Parameter set par and public encapsulation key pk.
Output: Shared secret ss and ciphertext ct, or an error.
• KEM.Decaps
Input:  Parameter set par, private decapsulation key sk and ciphertext ct.
Output: Shared secret ss, or an error.
NOTE 1: The parameter set par is sometimes considered to be a global variable rather than an explicit input to the
key generation, encapsulation and decapsulation algorithms.
In a key exchange such as Elliptic Curve Diffie-Hellman (ECDH), the shared secret is derived from keys contributed by
both parties in the exchange. However, in a key encapsulation mechanism the two parties have distinct roles: one party
generates a key pair, and the other party uses the public encapsulation key to generate a ciphertext that encapsulates a
shared secret which the first party can then recover from the ciphertext using their private decapsulation key.
EXAMPLE 1: The RSA Secret-Value Encapsulation (RSASVE) scheme from NIST SP 800-56B Rev. 2 [i.18] is
a key encapsulation mechanism based on the basic RSA encryption primitive. One party generates
an RSA key pair. The other party selects a random shared secret and encrypts it using the first
party's public RSA key to produce the ciphertext. The first party decrypts the ciphertext using their
private RSA key to recover the shared secret.
NOTE 2: In contrast to ECDH, the shared secret output by RSASVE is entirely controlled by the encapsulating
party. Consequently, when RSASVE is used in the key agreement scheme KAS1 from [i.18], the
RSASVE shared secret is combined with a random nonce from the decapsulating party during key
derivation to ensure that the final keying material depends on contributions from both parties.
For some key encapsulation mechanisms, decapsulation involves a key derivation step or ciphertext check that needs
the public encapsulation key. In those cases, the private key either contains a copy of the public key or can be used to
recompute the public key.
EXAMPLE 2: The Diffie-Hellman Key Encapsulation Mechanism (DHKEM) specified in IRTF RFC 9180 [i.8]
includes both the ciphertext and public encapsulation key when deriving the KEM shared secret
from the Diffie-Hellman shared secret. The public key can be recomputed from the private key.
NOTE 3: Decapsulation in DHKEM can be made more efficient by including a copy of the public key in the private
key rather than requiring it to be recomputed each time. This changes the format of the private key and
could potentially cause issues if the private key is malformed (see clause 5.1.3).
5.1.2 Errors
Each of the key generation, encapsulation and decapsulation algorithms can return an error. These errors can be caused
by a malformed input, including invalid parameters; the failure of an internal algorithm check, potentially due to an
implementation mistake elsewhere; or an error in a component relied on by the algorithm such as random bit generation.
EXAMPLE 1: The RSA Key-Pair Generation (RSAKPG) family of key generation algorithms from NIST
SP 800-56B Rev. 2 [i.18] include a pair-wise consistency check to detect badly generated key
pairs. If the pair-wise consistency check fails, the key generation algorithm will return an error.
ETSI
11 ETSI TR 104 239-1 V1.1.1 (2026-03)
NOTE: Valid RSA key pairs will not fail the pair-wise consistency check so a correctly functioning RSA key
generation algorithm is not expected to return a pair-wise consistency error. The check is intended to
detect and prevent issues caused by a faulty implementation or invalid parameters (see clause 6.3.1).
EXAMPLE 2: The RSASVE decapsulation algorithm (RSASVE.Generate) from [i.18] checks that the ciphertext
corresponds to an integer in the correct range. If the range check fails, the decapsulation algorithm
will return an error.
EXAMPLE 3: The RSASVE encapsulation algorithm (RSASVE.Recover) from [i.18] uses a random bit
generator to derive the shared secret that is encapsulated by the ciphertext. If the random bit
generator returns a catastrophic error due to a failure of the entropy source, the encapsulation
algorithm can return an error.
5.1.3 Decapsulation failures
The shared secret output by encapsulation might not always match the shared secret output by decapsulation; that is, for
a key pair (sk, pk) it is possible to have (ss, ct) = KEM.Encaps(par, pk) and ss' = KEM.Decaps(par, sk, ct) with ss ≠ ss'.
NOTE 1: This is not the same as a decapsulation error where decapsulation does not output a shared secret. In a
decapsulation failure, encapsulation and decapsulation both output shared secrets, but they are different.
Decapsulation failures can occur when the inputs to encapsulation or decapsulation are malformed, including invalid
parameters, or when there are mistakes in the implementation.
EXAMPLE 1: The RSASVE encapsulation and decapsulation algorithms from [i.18] expect correctly generated
keys and can output different shared secrets when used with a mismatched key pair; for example,
when the public and private keys use the same RSA modulus n, but the private exponent d does
not correspond to the public exponent d.
NOTE 2: The pair-wise consistency check in the RSAKPG key generation algorithms [i.18] detects malformed or
mismatched key pairs by testing for decapsulation failures. (See also clause 6.3.1).
EXAMPLE 2: Incorrectly implemented elliptic curve arithmetic can return the wrong ECDH shared secret for
specific inputs without necessarily causing an error (see, for example, CVE-2017-8932). This
would lead to a decapsulation failure if used in DHKEM [i.8].
The design of some key encapsulation mechanisms means that they can suffer from random decapsulation failures even
when they have been correctly implemented and all inputs are valid. For well-chosen parameters, random decapsulation
failures will happen with negligible probability.
EXAMPLE 3: The Module-Lattice-based Key Encapsulation Mechanism (ML-KEM) from NIST FIPS 203 [i.14]
-165
has a random decapsulation failure rate of 2 with parameter set ML-KEM-768.
NOTE 3: ML-KEM decapsulation includes a re-encryption check to detect invalid ciphertexts. If the re-encryption
check fails, decapsulation will return a different shared secret rather than an explicit decapsulation error.
This is the intended behaviour and not a random decapsulation failure.
5.2 Digital signature schemes
5.2.1 Digital signature interface
A Digital Signature Scheme (DSS) consists of a collection of parameter sets and three algorithms:
• DSS.KeyGen
Input:  Parameter set par.
Output: Public verification key pk and private signing key sk, or an error.
• DSS.Sign
Input:  Parameter set par, private signing key sk and message m.
Output: Signature σ, or an error.
ETSI
12 ETSI TR 104 239-1 V1.1.1 (2026-03)
• DSS.Verify
Input: Parameter set par, public verification key pk, message m and signature σ.
Output: Accept or reject, or an error.
NOTE: The parameter set par is sometimes considered to be a global variable rather than an explicit input to the
key generation, signature generation and verification algorithms.
For critical applications, it is sometimes recommended that the signature generation algorithm checks that the signature
verifies correctly and outputs an error if verification fails (see clause 3.2 in [i.13]). In those cases, the private key either
contains a copy of the public key or can be used to rederive the public key.
5.2.2 Errors
The key generation and signature generation algorithms can return an error. These errors can be caused by a malformed
input, including invalid parameters; the failure of an internal algorithm check, potentially due to an implementation
mistake elsewhere; or an error in a component relied on by the algorithm such as random bit generation.
EXAMPLE 1: Key generation for the Elliptic Curve Digital Signature Algorithm (ECDSA) in NIST FIPS 186-5
[i.13] converts the output of a random bit generator into an integer for use as the private key. If the
rejection sampling variant is used (clause A.2.2 in [i.13]), this conversion will fail when the integer
is not in the expected range and key generation will return an error.
EXAMPLE 2: The ECDSA signature generation algorithm (clause 6.4.1 in [i.13]) includes a step that computes a
modular inverse. This can fail if the ECDSA domain parameters are invalid; for example, if the
order n of the base point is not prime. In that case, the signature generation algorithm will return
an error.
Errors that occur in the verification algorithm are often handled by rejecting the signature rather than returning an
explicit error. However, it still might be possible for a failure in a subroutine to cause verification to return an explicit
error rather than rejecting the signature.
EXAMPLE 3: The ECDSA verification algorithm (clause 6.4.2 in [i.13]) checks that the signature corresponds to
a pair of integers in the correct range. If the range check fails, the verification algorithm will reject
the signature.
EXAMPLE 4: The ECDSA verification algorithm (clause 6.4.2 in [i.13]) includes a step that computes a modular
inverse. This can fail if the ECDSA domain parameters are invalid; for example, if the order n of
the base point is not prime. In that case, the verification algorithm could return an error rather than
rejecting the signature.
NOTE: NIST FIPS 186-5 [i.13] includes a general requirement that any verification failures, including errors, are
treated as rejections of the signature. Conversely, ISO/IEC 14888-3 [i.10] does not have this requirement.
5.2.3 Pre-hashing
In general purpose digital signature schemes, the signature generation algorithm takes a variable length message as
input. If a hardware device is being used to securely store the private signing key and perform signature generation, it
might not be feasible to transfer long messages to the device for signing; for example, if the hardware device has limited
resources or bandwidth. In those cases, it can be preferable to use the digital signature scheme to sign a hash of the
message rather than the message itself.
Pre-hashing the message is often part of the protocol layer, but some digital signature schemes include variants that
integrate pre-hashing at the algorithmic layer.
EXAMPLE 1: The EdDSA digital signature scheme [i.7], [i.13] has a pre-hash variant HashEdDSA. Distinct byte
strings are included when computing the internal message hash to provide separation between the
pure EdDSA and pre-hash HashEdDSA variants. Specifically, when used with the Ed25519
parameter set, EdDSA computes
digest = Hash(R || Q || m),
ETSI
13 ETSI TR 104 239-1 V1.1.1 (2026-03)
where R is the encoding of a point from the first half of the signature, and Q is the encoding of the
public key, whereas HashEdDSA computes
digest = Hash(str || R || Q || PreHash(m))
for a specified byte string str.
For some digital signature schemes, the internal hash computation in the signature generation algorithm does not
involve the private signing key and can be cleanly separated from the rest of the signature calculation. This allows the
internal message hash to be performed outside the hardware device, and the result can be passed to the device so that it
can complete signature generation using the private signing key stored on the device.
EXAMPLE 2: The first step of the ECDSA signature generation algorithm in [i.13] computes digest = Hash(m).
This can be cleanly separated from the rest of the signature calculation.
NOTE: The EdDSA signature generation algorithm [i.7], [i.13] hashes the message in a way that cannot be
cleanly separated from the rest of signature generation so it is not possible to use the same approach in
this case.
5.2.4 Context strings
If a protocol reuses the same private signing key to sign messages across different sessions of the protocol or for
different purposes within the protocol, this can lead to replay or cross-protocol attacks. One mitigation technique is to
include a context string which is specific to a given session or use case when signing the message.
Context strings are often part of the protocol layer, but some digital signature schemes allow context strings as optional
input to the signature generation and verification algorithms.
EXAMPLE: Some variants of the EdDSA digital signature scheme [i.7], [i.13] accept a context string ctx as
optional input to signature generation and verification. Specifically, for the Ed448 parameter set,
EdDSA computes
digest = Hash(str || len(ctx) || ctx || R || Q || m)
for a specified byte string str, where R is the encoding of a point from the first half of the
signature, and Q is the encoding of the public key. The default for ctx is the empty string.
NOTE: The pre-hash HashEdDSA variant of EdDSA accepts a context string for the Ed25519 parameter set, but
pure EdDSA does not.
6 Best practice guidance
6.1 Reuse existing implementations
If an existing cryptographic implementation has been independently reviewed and rigorously tested, then it is generally
better to reuse that implementation than to develop a new implementation. Open-source projects that are well-organised
and well-supported will
...