ETSI TS 103 744 V1.2.1 (2025-03)

CYBER; Quantum-Safe Cryptography (QSC); Quantum-safe Hybrid Key Establishment

RTS/CYBER-QSC-0019

General Information

• Status: Not Published
• Technical Committee: CYBER QSC - Quantum-Safe Cryptography
• Current Stage: 12 - Completion
• Due Date: 15-Apr-2025
• Completion Date: 25-Mar-2025

Standards Content (Sample)

TECHNICAL SPECIFICATION
CYBER;
Quantum-Safe Cryptography (QSC);
Quantum-safe Hybrid Key Establishment

2 ETSI TS 103 744 V1.2.1 (2025-03)

Reference
RTS/CYBER-QSC-0019
Keywords
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 2025.
All rights reserved.
ETSI
3 ETSI TS 103 744 V1.2.1 (2025-03)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 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 . 9
4 Purpose of quantum-safe hybrid key establishment . 9
4.1 Status of quantum-safe key encapsulation mechanisms . 9
5 Architecture for quantum-safe hybrid key establishment. 10
5.1 Functional entities . 10
5.2 Information relationships (reference points) . 10
6 Introductory information . 11
6.1 Introduction . 11
6.2 Notation . 11
6.2.1 Radix . 11
6.2.2 Conventions . 11
6.2.3 Bit/Byte ordering . 11
6.2.4 Integer encoding . 11
7 Cryptographic primitives . 12
7.1 Hash functions (hash) . 12
7.2 Context formatting function (f) . 12
7.2.1 Context formatting function (f) description . 12
7.2.2 Concatenate-based context formatting function. 12
7.2.3 Concatenate-and-hash-based context formatting function . 13
7.3 PseudoRandom Function (PRF) . 14
7.3.1 PRF description . 14
7.3.2 PRF to HMAC mapping . 14
7.3.3 PRF to KMAC mapping . 14
7.4 Key Derivation Functions (KDFs) . 15
7.4.1 KDF description . 15
7.4.2 KDF to HKDF mapping . 16
7.4.3 KDF to HMAC mapping . 16
7.4.4 KDF to KMAC mapping . 17
7.5 Elliptic Curve Diffie-Hellman (ECDH) . 17
7.5.1 ECDH description . 17
7.5.2 Elliptic curve domain parameters . 18
7.6 Key Encapsulation Mechanisms (KEMs) . 18
7.6.1 KEM description . 18
7.6.2 Post-quantum KEMs . 18
7.7 Primitive parameter sets . 18
7.7.1 Parameter set description . 18
7.7.2 Parameter sets . 19
8 Hybrid key establishment schemes . 20
8.1 General . 20
8.1.1 Key establishment abstraction . 20
ETSI
4 ETSI TS 103 744 V1.2.1 (2025-03)
8.1.2 Key establishment abstraction to ECDHE . 21
8.1.3 Key establishment abstraction to KEM . 21
8.2 Concatenate hybrid key establishment scheme . 21
8.2.1 Concatenate hybrid key establishment scheme - ephemeral . 21
8.2.2 Concatenate hybrid key establishment scheme - static . 22
8.2.3 Concatenate hybrid key combiner - CatKDF . 23
8.3 Cascade hybrid key establishment scheme . 24
8.3.1 Cascade hybrid key establishment scheme - ephemeral . 24
8.3.2 Cascade hybrid key establishment scheme - static . 25
8.3.3 Cascade hybrid key combiner - CasKDF . 26
Annex A (informative): Background . 28
A.1 Quantum computing threats to traditional key exchange protocols . 28
A.2 Rationale for quantum-safe hybrid key establishment . 28
Annex B (informative): Security consideration . 30
B.1 Security definitions . 30
Annex C (informative): Message Encoding for Test Vector Generation . 31
C.1 Message Formatting Function for Test Vector Generation . 31
Annex D (informative): Test Vectors . 33
D.1 Introduction . 33
D.2 Test vectors for CatKDF . 33
D.2.1 KDF as HKDF with SHA256, ECDH with NIST P-256, and ML-KEM768 . 33
D.2.2 KDF as HMAC with SHA256, ECDH with NIST P-256, and ML-KEM768 . 34
D.2.3 KDF as KAMC128, ECDH with NIST P-256, and ML-KEM768 . 35
D.2.4 KDF as HKDF with SHA256, ECDH with Curve25519, and ML-KEM768. 36
D.2.5 KDF as HMAC with SHA256, ECDH with Curve25519, and ML-KEM768 . 37
D.2.6 KDF as KAMC128, ECDH with Curve25519, and ML-KEM768 . 38
D.3 Test vectors for CasKDF . 39
D.3.1 KDF as HKDF with SHA256, ECDH with NIST P-256, and ML-KEM768 . 39
D.3.2 KDF as HMAC with SHA256, ECDH with NIST P-256, and ML-KEM768 . 40
D.3.3 KDF as KMAC128, ECDH with NIST P-256, and ML-KEM768 . 41
D.3.4 KDF as HKDF with SHA256, ECDH with Curve25519, and ML-KEM768. 42
D.3.5 KDF as HMAC with SHA256, ECDH with Curve25519, and ML-KEM768 . 43
D.3.6 KDF as KMAC128, ECDH with Curve25519, and ML-KEM768 . 44
Annex E (informative): Change history . 46
History . 47

ETSI
5 ETSI TS 103 744 V1.2.1 (2025-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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Cyber Security (CYBER).
Modal verbs terminology
In the present document "shall", "shall not", "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.
Introduction
Hybrid Key Establishments are constructions that combine a traditional key establishment method, such as elliptic
curve Diffie Hellman [1], with a quantum-safe key encapsulation mechanism, such as Module-Lattice-based Key
Encapsulation Mechanism (ML-KEM) [11], into a single key establishment method. Hybrid key establishments are a
migration technique to move to quantum-safe technology in advance of establishing full security assurance in the
underlying post-quantum cryptographic scheme.

ETSI
6 ETSI TS 103 744 V1.2.1 (2025-03)
1 Scope
The present document specifies several methods for deriving cryptographic keys from multiple shared secrets. The
shared secrets are established using existing traditional key establishment schemes, like Elliptic Curve Diffie-Hellman
(ECDH) in NIST SP800-56Ar3 [1], and new quantum-safe Key Encapsulation Mechanisms (KEMs).
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
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 are necessary for the application of the present document.
[1] NIST SP800-56Ar3: "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete
Logarithm Cryptography".
[2] IETF RFC 2104: "HMAC: Keyed-Hashing for Message Authentication".
[3] IETF RFC 5869: "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)".
[4] FIPS PUB 180-4: "Secure Hash Standard (SHS)".
[5] Void.
[6] NIST SP 800-186: "Recommendations for Discrete Logarithm-Based Cryptography: Elliptic
Curve Domain Parameters".
[7] IETF RFC 5639: "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve
Generation".
[8] IETF RFC 7748: "Elliptic Curves for Security".
[9] NIST SP800-185: "SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash".
[10] NIST SP800-56Cr2: "Recommendation for Key-Derivation Methods in Key-Establishment
Schemes".
[11] FIPS 203: "Module-Lattice-Based Key-Encapsulation Mechanism Standard".
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.
ETSI
7 ETSI TS 103 744 V1.2.1 (2025-03)
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Y. Dodis, R. Gennaro, J. Håstad, H. Krawczyk, and T. Rabin: "Randomness Extraction and Key
derivation Using the CBC, Cascade, and HMAC Modes", Crypto 04, LNCS 3152, pp. 494-510.
Springer Verlag, 2004.
[i.2] Void.
[i.3] N. Bindel, J. Brendel, M. Fischlin, B. Goncalves, D. Stebila: "Hybrid Key Encapsulation
Mechanisms and Authenticated Key Exchange", IACR eprint 2018-903.
[i.4] Void.
th
[i.5] Simon D. R.: "On the power of quantum computation", SFCS 94 Proceedings of the 35 Annual
Symposium on Foundations of Computer Science, November 1994, Pages 116-123.
[i.6] Shor P.W.: "Algorithms for quantum computation: discrete logarithms and factoring", SFCS 94:
th
Proceedings of the 35 Annual Symposium on Foundations of Computer Science,
November 1994, Pages 124-134.
[i.7] NIST CAVP SP 800-56A: "ECC CDH Primitive Test Vectors".
[i.8] IETF RFC 8734 (2020): "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport
Layer Security (TLS) Version 1.3". RFC Editor.
[i.9] Void.
[i.10] Kwiatkowski K. (2024): "Post Quantum Cryptography KATs".
[i.11] Campagna M., Petcher A.: "Security of Hybrid Key Encapsulation", IACR eprint 2020-1364,
November 2020.
[i.12] Campagna M., Petcher A.: "Security of Hybrid Key Establishment using Concatenation", IACR
eprint 2023-972, June 2023.
[i.13] Void.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
asymmetric cryptography: cryptographic system that utilizes a pair of keys, a private key known only to one entity,
and a public key that can be openly distributed without loss of security
big-endian: octet ordering that signifies "big-end", or most significant octet value is stored to the left, or at the lowest
storage location
EXAMPLE: The decimal value 108591, which is 0x0001A82F as a hex encoded 32-bit integer, is encoded as a
length 4 octet string as 0001A82F.
cryptographic hash function: function that maps a bit string of arbitrary length to a fixed length bit string (message
digest or digest for short)
NOTE: Hash functions are designed to satisfy the following properties:
1) (One-way) It is computationally infeasible to find any input that maps to any pre-specified output.
2) (Collision resistant) It is computationally infeasible to find any two distinct inputs that map to the
same output.
ETSI
8 ETSI TS 103 744 V1.2.1 (2025-03)
cryptographic key: binary string used as a secret by a cryptographic algorithm
EXAMPLE: AES-256 requires a random 256-bit string as a secret key.
entity: person, device, or system that is executing the steps of a process
NOTE: Steps of one of the processes defined or referenced in the present document.
info: octet string set by the application as additional information
EXAMPLE: An application specific value like an ASCII encoded string,
e.g. info = "ETSI_QSHKE_TEST_VECTORS_V_1_2".
key agreement scheme: key establishment procedure in which the resultant secret keying material is a function of
contributions of the entities participating, such that no entity can predetermine the value of the secret keying material
independently of the other entities' contributions
key derivation: process to derive key material from one or more shared secrets
key encapsulation mechanism: set of methods to establish a shared secret key between two parties
key establishment/exchange method: cryptographic procedure by which cryptographic keys are established between
two parties
label: octet string that specifies a separation of use for the instance of the key derivation or exchange, such as a random
nonce.
message digest/digest: fixed-length output of a cryptographic hash function over a variable length input
octet string: ordered sequence of octets/bytes consisting of 8-bits each
private key: key in an asymmetric cryptographic scheme that is kept secret
public key: key in an asymmetric cryptographic scheme that can be made public without loss of security
public key cryptography: See asymmetric cryptography.
random oracle: theoretical black box that responds to every unique query with a uniformly random selection from the
set of possible responses, with repeated queries receiving the same response
security level: value n for which the best-known attack against breaking the security properties of a cryptographic
algorithm requires 2^n operations.
NOTE: Sometimes also referred to as bit-strength.
shared secret: secret value that has been computed using a key-establishment scheme
3.2 Symbols
For the purposes of the present document, the following symbols apply:
A || B The concatenation of binary strings A followed by B
∅ A zero-length octet string
[x] An integer value x expressed as an n-bit integer
n
q The least integer value x greater than or equal to q
len(A) The number of octets in an octet string A
hash( ) A cryptographic hash function
digest_len The length in octets of a hash function's digest
block_len The block length in octets of a hash function's block size
C A ciphertext value created by a KEM
d A private key for elliptic curve cryptography
k A cryptographic secret or key
P/R A public key for an asymmetric cryptographic scheme
psk A pre-shared key
Q A public key for elliptic curve cryptography
ETSI
9 ETSI TS 103 744 V1.2.1 (2025-03)
sk A private key for an asymmetric cryptographic scheme
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AES Advanced Encryption Standard
CAVP Cryptographic Algorithm Validation Program
CDH Cofactor Diffie-Hellman
CID Ciphersuite IDentifier
ECC Elliptic Curve Cryptography
ECDH Elliptic Curve Diffie-Hellman
ECDHE Elliptic Curve Diffie-Hellman Ephemeral
HKDF HMAC-based Key Derivation Function
HMAC Hash-based Message Authentication Code
IND-CCA INDistinguishability under Chosen-Ciphertext Attacks
IND-CPA INDistinguishability under Chosen-Plaintext Attacks
KDF Key Derivation Function
KEM Key Encapsulation Mechanism
KMAC Keccak Message Authentication Code
LNCS Lecture Notes in Computer Science
MA Message from entity A
MB Message from entity B
ML-KEM Module-Lattice-Based Key Encapsulation Mechanism
NIST National Institute of Standards and Technology
OW-CCA One Way Chosen Ciphertext Attack
OW-CPA One-Way Chosen-Plaintext Attack
PRF PseudoRandom Function
QKD Quantum Key Distribution
RSA Rivest, Shamir and Adelman
SP Special Publication
SSH Secure Shell
TLS Transport Layer Security
4 Purpose of quantum-safe hybrid key establishment
4.1 Status of quantum-safe key encapsulation mechanisms
NIST has initiated a process of analysing and standardizing one or more new quantum-safe key encapsulation
mechanisms suitable to replace traditional key establishment schemes. At the time of the present document, there is one
FIPS approved standard, FIPS 203 [11].
The present document addresses the following cases:
1) One or more key exchange method establishes a shared secret from which randomness extraction is necessary.
2) One or more key exchange method incorporates a hash-based key derivation function prior to use within the
hybrid method defined in the present document.
Quantum-safe hybrid key establishment specified in the present document ensures that the derived key is at least as
secure as the maximum security of the key establishment schemes. The resulting hybrid scheme will remain secure if
one of the key establishment schemes remains secure.
Quantum Key Distribution (QKD) provides an alternative method of establishing a shared secret between two entities
using quantum mechanics. The scope of the present document is limited to elliptic curve Diffie-Hellman and
quantum-safe key encapsulation mechanisms.
ETSI
…
10 ETSI TS 103 744 V1.2.1 (2025-03)
5 Architecture for quantum-safe hybrid key
establishment
5.1 Functional entities
There are two entities defined for quantum-safe hybrid key establishment, an Initiator A that initiates a key
establishment scheme, and a Responder B who responds to the request. The entities communicate over a network
medium.
EXAMPLE: Examples of such mediums are: ethernet, wireless and cellular networks.

Figure 1: Communicating entities A and B
5.2 Information relationships (reference points)
The network media over which the Initiator and Responder communicate will have a packet formatting scheme that
allows the encoding and transmission of octet (byte) strings. The Initiator and Responder will exchange messages,
where each message is an octet string that can span multiple packets. MA denotes a message from A to B, and MB
denotes a message sent from B to A.
A may initiate a hybrid key establishment by the transmission of a message to B. B responds to this message. The
exchange between the entities can consist of a single message or multiple rounds of messages.
A B
MA
MB
MA
MB
MA
n
MB
n
Figure 2: Messages exchanged between entities A and B
The transcript of the key establishment is the list of all messages exchanged between A and B, in the sequence order
they were sent:
transcript = (MA , MB , MA , MB , … MA , MB )
1 1 2 2 n n
In other embodiments, B may be in possession of authentic public keys belonging to A. The exchange of messages may
consist solely of messages from B to A.
ETSI
11 ETSI TS 103 744 V1.2.1 (2025-03)
6 Introductory information
6.1 Introduction
Quantum-safe hybrid key establishment combines a traditional key establishment scheme, like ECDH and a quantum-
safe Key Encapsulation Mechanism (KEM). Hybrid key establishment schemes specified in the present document use
two or more shared secrets to derive cryptographic key material using a key derivation function. The key derivation
functions for hybrid key establishment specified in the present document provide both the key expansion property and
random extraction as per Crypto 04, LNCS 3152 [i.1].
6.2 Notation
6.2.1 Radix
The prefix "0x" indicates hexadecimal numbers.
6.2.2 Conventions
The assignment operator "=", as used in several programming languages:
=
means that assumes the value that had before the assignment took place. For instance:
x = x + y + 3
means:
(new value of x) becomes (old value of x) + (old value of y) + 3.
6.2.3 Bit/Byte ordering
All data variables are represented with the most significant bit (or byte) on the left-hand side and the least significant bit
(or byte) on the right-hand side. Where a variable is broken down into a number of sub-strings, the left most (most
significant) sub-string is numbered 0, the next most significant is numbered, 1 and so on, through to the least
significant.
EXAMPLE: An n-bit MESSAGE is subdivided into 64-bit substrings M , M , …, M so if the message is:
0 1 i
0x0123456789ABCDEFFEDCBA987654321086545381AB594FC28786404C50A37…
then:
M = 0x0123456789ABCDEF
M = 0xFEDCBA9876543210
M = 0x86545381AB594FC2
M = 0x8786404C50A37…
6.2.4 Integer encoding
Integers are represented in the bit/byte ordering defined in clause 6.2.3. The most significant bit (or byte) on the
left-hand side and the least significant bit (or byte) on the right-hand side.
EXAMPLE: A 32-bit integer of the value I = 37 is encoded as:
I = 0x00000025
NOTE: This is big-endian or network byte ordering.
ETSI
12 ETSI TS 103 744 V1.2.1 (2025-03)
7 Cryptographic primitives
7.1 Hash functions (hash)
A hash function maps an arbitrary length bit string (input) to a fixed length (digest_len) octet string output (digest):
digest = hash(input)
Approved hash functions for the purpose of the present document shall be limited to those in the following list:
• SHA-256, SHA-384 as defined in FIPS PUB 180-4 [4].
7.2 Context formatting function (f)
7.2.1 Context formatting function (f) description
The context formatting functions used in the present document take a list of inputs and return an octet string. A generic
calling interface to the context function f used in the present document is defined in the present clause:
context = f(val1, val2,…)
where the parameters and output shall be defined as follows.
Input:
val , val , …, val - an ordered sequence of octet strings each of length less than 2 octets, where n > 0.
1 2 n
Output:
context - an octet string representing the context value.
7.2.2 Concatenate-based context formatting function
The present clause defines a concatenate-based context formatting function. The concatenate-based context formatting
function takes an ordered sequence of octet strings and converts them into a length-delimited single octet string. The
concatenate-based context formatting function f has the following calling interface:
context = cb_f(val , val , …)
1 2
where the parameters, procedure and output shall be as follows.
Input:
val , val , …, val - an ordered sequence of octet strings each of length less than 2 octets, where n > 0.
1 2 n
Process:
1) Set context = ∅.
2) For i = 1, …, n.
a) Set len = len(val ), returns the length of val in octets.
i i i
i) If len > 2 - 1, return error.
i
ii) L = [len ] - a 32-bit integer value expressed as 4 octets.
i i 32
b) Set context = context || L || val .
i i
3) Return context.
ETSI
13 ETSI TS 103 744 V1.2.1 (2025-03)
Output:
context - an octet string representing the context value or an error.
The concatenate-based formatting function is designed to be used in conjunction with the KMAC variety of KDFs.
HKDF implementations do not perform efficiently when instantiated with a concatenate-based context formatting
function. The context value is passed as the 'info' input to the HKDF function. See OpenSSL's documentation on length
limits for context - https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_CTX_add1_hkdf_info.html. IETF
RFC 5869 [3] does not limit the length of the 'info' input value; however, for efficiency reasons, it is recommended to
keep the length relatively short since it is processed through a hash function in every execution of HKDF expand step.
7.2.3 Concatenate-and-hash-based context formatting function
The present clause defines a concatenate-and-hash context formatting function. The concatenate-and-hash context
formatting function takes an ordered sequence of octet strings and converts them into a length delimited octet string.
The concatenate-and-hash-based context formatting function f has the following calling interface:
context = cahb_f(val , val , …)
1 2
where the prerequisite, parameters, procedure and output shall be as follows.
Prerequisite:
hash - an approved hash function as per clause 7.1 that produces a digest_len-length string of octets (digest_len in {32,
48}).
Input:
val , val , …, val - an ordered sequence of octet strings each of length less than 2 octets, where n > 0.
1 2 n
Process:
1) Set buffer = ∅.
2) For i = 1, …, n.
a) Set len = len(val ), returns the length of val in octets.
i i i
i) If len > 2 - 1, return error.
i
ii) L = [len ] - a 32-bit integer value expressed as 4 octets.
i i 32
b) Set buffer = buffer || L || val .
i i
3) Set context = hash(buffer).
4) Return context.
Output:
context - a digest_len octet string representing the context value or an error.
NOTE: In practice, the concatenate-and-hash based context format function may save memory allocation, and
make use of the context value more efficiently if there are cases where it is used iteratively.
ETSI
14 ETSI TS 103 744 V1.2.1 (2025-03)
7.3 PseudoRandom Function (PRF)
7.3.1 PRF description
A PseudoRandom Function generates output from a random (or secret) seed such that the output is computationally
indistinguishable from truly random output. A generic calling interface to the PRF used in the present document is
defined in the present clause:
output = PRF(secret, val , val , …)
1 2
where the parameters and output shall be defined as follows.
Input:
secret - an octet string that constitutes the input for the pseudorandom function.
val1, val2, …, valn - an ordered sequence of octet strings each of length less than 2 octets, where n > 0.
Output:
output - the pseudorandom output, length dependent on the primitive used in the PRF.
Approved PRF functions for the purpose of the present document shall be limited to HMAC as defined in IETF
RFC 2104 [2] with a SHA2 hash function from clause 7.1, or KMAC128 or KMAC256 as defined in
NIST SP800-185 [9].
7.3.2 PRF to HMAC mapping
This clause specifies a mapping from the PRF definition to HMAC with a specified hash function.
HMAC shall be as defined in IETF RFC 2104 [2] with an approved SHA2 hash function from clause 7.1 and has a
calling interface:
output = HMAC(secret, data)
where the prerequisite, parameters, and output shall be defined as follows.
Prerequisite:
cahb_f - a context formatting function as defined in clause 7.2.3.
Input:
secret - an octet string that constitutes the input for the pseudorandom function.
data - an octet string that is included in the HMAC.
Output:
output - pseudorandom output of a fixed length (of the underlying hash function).
The mapping shall be defined as follows:
output = PRF (secret, val , val , …) = HMAC(secret, cahb_f(val , val , …)).
1 2 1 2
7.3.3 PRF to KMAC mapping
This clause specifies a mapping from the PRF definition to KMAC function, KMAC128 or KMAC256. KMAC shall be
as defined in NIST SP800-185 [9] and has a calling interface:
output = KMAC(K, X, L, S)
where the prerequisite, parameters, and output shall be defined as follows.
ETSI
15 ETSI TS 103 744 V1.2.1 (2025-03)
Prerequisite:
cb_f - a context formatting function as defined in clause 7.2.2.
Input:
K - a key bit string of any length, at least security strength in length.
X - an input bit string of any length.
L - is an integer representation of the output length in bits.
S - is an optional customization bit string of any length.
Output:
output - pseudorandom output of bit length L.
The mapping shall be defined as follows:
output = PRF (secret, val , val , …) = KMAC (secret, cb_f(val , val , …), kmac_outlen, ∅),
1 2 1 2
where kmac_outlen is set to 32 or 48 octets for KMAC128 and KMAC256, respectively, corresponding to the minimum
security level of the underlying key establishment schemes, and ∅ represents an empty octet string.
If a secret value is not specified or is the empty string, then a secret value of a zero string of 164 octets shall be used for
KMAC128, and a secret value of a zero string of 132 octets shall be used for KMAC256. This shall only happen in the
case when a psk is not used in the cascade combiner, see clause 8.3.3.
7.4 Key Derivation Functions (KDFs)
7.4.1 KDF description
The key derivation functions used in the present document are derived from PRFs. A generic calling interface to the
KDFs used in the present document is defined in the present clause:
key_material = KDF(secret, label, context, length)
where the parameters and output shall be defined as follows.
Input:
secret - an octet string that constitutes the input for the key derivation function.
label - an optional octet string that specifies a separation of use for the instance of the key derivation or exchange, such
as a random nonce.
context - an octet string that constitutes an input for the key derivation function. It may include identity information
specific to the entities deriving keys or exchanged messages.
length - the length in octets of the derived keying material.
Output:
key_material - the derived keying material of length length.
Approved KDF functions for the purpose of the present document shall be limited to HKDF as defined in IETF
RFC 5869 [3] with an approved SHA2 hash function from clause 7.1, or KMAC128 or KMAC256 as defined in NIST
SP800-185 [9].
NOTE: The KDFs selected for this specification are based on meeting the random oracle property used in the
security proof [i.12], and their availability in existing cryptographic modules.
ETSI
16 ETSI TS 103 744 V1.2.1 (2025-03)
7.4.2 KDF to HKDF mapping
This clause specifies a mapping from the KDF definition to HKDF with a SHA2 hash function from clause 7.1.
HKDF shall be as defined in IETF RFC 5869 [3] and has a calling interface:
key_material = HKDF(secret, salt, info, length)
where the parameters and output shall be defined as follows.
Input:
secret - an octet string that constitutes the input for the key derivation function. It shall be present.
salt - optional salt value (a non-secret random value); it may be present. If it is not present it shall be set to a digest_len
octet string of zero values. The digest_len is defined by the underlying hash function.
info - an octet string that contains application specific information. It may be a zero-length string.
length - the length in octets of the derived keying material. It shall be present.
Output:
key_material - the derived keying material of length length.
The mapping shall set salt = label, and info = context, as follows:
key_material = KDF(secret, label, context, length) = HKDF(secret, label, context, length).
7.4.3 KDF to HMAC mapping
This clause specifies a mapping from the KDF definition to an HMAC implementation of the NIST SP800-56Cr2 [10]
One step Key Derivation Function using HMAC. HMAC shall be as defined in IETF RFC 2104 [2] with an approved
SHA2 hash function from clause 7.1 and has a calling interface:
output = HMAC(secret, data)
where the prerequisite, parameters, and output shall be defined as follows.
Input:
secret - an octet string that constitutes the input for the pseudorandom function.
data - an octet string that is included in the HMAC.
Output:
output - pseudorandom output of a fixed length (of the underlying hash function).
The mapping shall set the secret = label and data = counter || secret || context, where HMAC(label, counter || secret ||
context) is iteratively executed to generate at least length output octets, with a 32-bit counter value. The streamed output
is truncated (if needed) to output key_material of exactly length-octets. The mapping adheres to the following process.
Process:
1) Let n = length/digest_len.
2) If n > 2 - 1 retur
...