HMAC Based Hybrid Key Combiners for Multiple Keys
draft-wang-cfrg-key-combiners-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Guilin WANG , Haoyang Wang | ||
| Last updated | 2026-04-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-cfrg-key-combiners-01
Crypto Forum (CFRG) G. Wang, Ed.
Internet-Draft Huawei Int. Pte Ltd
Intended status: Informational H. Wang
Expires: 24 October 2026 Shanghai Jiaotong University
22 April 2026
HMAC Based Hybrid Key Combiners for Multiple Keys
draft-wang-cfrg-key-combiners-01
Abstract
As a fundamental building block in security protocols, a key combiner
is used to combine two or more input cryptographic keys, some
potentially compromised, into a single pseudorandom output key. Most
of the existing key combiners are for two input keys. This draft
specifies two provably secure constructions of key combiners for
multiple keys [WWW25], which is particularly useful in post-quantum
migration where multiple input keys may be produced by different
algorithms or even different approaches [RFC9370], [ETSI25]. Namely,
here the input keys can be two or more, and the combined output key
remains pseudorandom if at least one of the input keys is secure,
i.e., uniformly random and unknown to an attacker. The two
constructions, called HKCv1 and HKCv2, are based on the extract-then-
expand paradigm of HMAC (Keyed-Hashing for Message Authentication)
[RFC2104]. HKCv1 is designed for simultaneously available input keys
using concatenation, while HKCv2 is tailored for scenarios where
input keys arrive incrementally, using an iterative HMAC structure.
[EDNOTE: .... ]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 October 2026.
Wang & Wang Expires 24 October 2026 [Page 1]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. HMAC and HKDF . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. HKDF . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Existing Key Combiners for Multiple Keys . . . . . . . . . . 5
4.1. The Key Combiner for Multiple Keys from ETSI TS 103
744 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. The Key Combiner for Multiple Keys from NIST SP800-133 . 7
4.3. The Key Combiner for Multiple Keys from
draft-ounsworth-cfrg-kem-combiners . . . . . . . . . . . 8
5. HMAC based Key Combiners for Multiple Keys (HKC) . . . . . . 8
5.1. HKC version 1 (HKCv1) . . . . . . . . . . . . . . . . . . 8
5.2. HKC version 2 (HKCv2) . . . . . . . . . . . . . . . . . . 10
5.3. Comparison to the Existing Key Combiners for Multiple
Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Security of HKCv1 . . . . . . . . . . . . . . . . . . . . 13
6.2. Security of HKCv2 . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
A key combiner is used to combine two or more input cryptographic
keys, some potentially compromised, into a single pseudorandom output
key. It is a fundamental building block in modern cryptographic
protocols, notably employed in TLS 1.3 [RFC8446], IKEv2 [RFC7296],
and Signal [PM16]. From the output key, various work keys are
subsequently derived to secure the following communications via
symmetric-key cryptography. However, the original input keys are not
always uniformly random or may be even partially known to an
Wang & Wang Expires 24 October 2026 [Page 2]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
adversary. Key combiners are particularly useful in post-quantum
(PQ) migration scenarios where multiple input keys may be produced by
different algorithms or even different approaches.
Here are two examples. To mitigate quantum threat, a multiple key
exchange framework is specified in [RFC9370] as the PQ migration of
key exchange for the Internet Key Exchange Protocol Version 2 (IKEv2)
[RFC7296], where the input keys consist of one shared secret
negotiated via traditional Diffie-Hellman key exchange and one or
more shared secrets obtained via running additional PQ key
encapsulation mechansim (KEM) algorithms, called ADDKEs. The
Quantum-safe Hybrid Key Establishment [ETSI25] specifies key
combiners for the input keys from PSK (preshared secret key),
traditional key exchange and PQ KEM. Here, a PSK could be obtained
from QKD (Quantum Key Distribution).
However, most of the existing key combiners are for two input keys.
Examples include the key combiners used in TLS 1.3 [RFC8446], IKEv2
[RFC7296], and Signal [PM16]. The ouput key in these protocols is
obtained more or less by computing HMAC(k1,k2||CTXinfo) one or
multiple times, where k1 and k2 are two input keys or some
intermediate secrets derived from them, and CTXinfo denotes some
context info specific to the protocol and a particular execution.
For example, the key schedule of TLS 1.3 (refer to Section 7.1 in
[RFC7296]) is to obtain a Master Key by running the above HAMC
multiple times with two initial secret inputs, (EC)DHE shared secret
and PSK (a pre-shared key established externally or derived from the
resumption_master_secret value from a previous connection). The
security of using HAMC this way actually requires that HMAC(salt,
ikm) perform as a dual-PRF, which means that the output of HMAC(salt,
ikm) is pseudorandom by treating either salt or ikm as the secret
key. The security proof for dual-PRF has not been rigrously proved
until 2023 by [BBGS23]), where the condition is given as
"feasibility", some requirements on the key length.
Three key combiners for two keys are specifed in Internet Drafts
[I-D.CBG24], bound with ML-KEM [FIPS203], and all of them have
provable security. Also, the research work in [ADK22] proposes
another key combiners for two keys, but its computational overhead is
high, compared with other solutions.
For key combiners for mulitple keys, several soluitons are
standardized in [ETSI25] and [SP800-133], together with an Internet
draft given in [I-D.OWK24]. Most of these solutions are provably
secure, but either in weaker security or the solution is not very
efficient. These solutions are overviewed in Section 4. This
necessitates robust methods for combining multiple secret keys into a
single, cryptographically strong key, if at least one of the input
Wang & Wang Expires 24 October 2026 [Page 3]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
keys is secure, i.e., uniformly random and unknown to an attacker.
Note that key combination differs from key derivation functions
(KDFs), like HKDF [RFC5869] [K10] and PBKDF [RFC8018], which are
typically used to derive keys from a single high-entropy source,
which can be the output of a key combiner.
This draft specifies two provably secure constructions of key
combiners for multiple keys [WWW25], which is useful in post-quantum
migration where multiple input keys are generated by different
algorithms or even different approaches [RFC9370], [ETSI25]. Namely,
here the input keys can be two or more, and the combined output key
remains pseudorandom if at least one of the input keys is secure,
i.e., uniformly random and unknown to an attacker. The two
constructions, called HKCv1 and HKCv2, are based on the extract-then-
expand paradigm of HMAC (Keyed-Hashing for Message Authentication)
[RFC2104]. HKCv1 is designed for simultaneously available input keys
using concatenation, while HKCv2 is tailored for scenarios where
input keys arrive incrementally, using an iterative HMAC structure.
As HMAC has been widely supported in industry since its introduction
in 1997 (e.g., [RFC4868]), these two key combiners for multiple keys
are expected to be easily integrated into IETF protocols and existing
systems.
In particular, HKCv1 and HKCv2 are much more efficient than the
solutions given in [ETSI25] and [I-D.OWK24], as they decouple the
transcripts of how each input key is obtained from the output key
derivation. In PQ migration settings, the size of these transcripts
is normaly large. The detailed comparison among these solutions are
given in Section 5.3, and the security of HKCv1 and HKCv2 and the
difference with other solutions are discussed in Section 6.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. HMAC and HKDF
3.1. HMAC
HMAC (Keyed-Hashing for Message Authentication) is specified in
[RFC2104]). For easy reference, HMAC(salt, ikm) with two inputs to
generate one output, a MAC, is reviewed as following:
HMAC(s,m)=Hash((s' XOR opad)||Hash((s' XOR ipad)||m)) (1)
Wang & Wang Expires 24 October 2026 [Page 4]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
In the above, the following notations are used:
* Hash is a cryptographically hash function with bloc size b.
* m is the input message to be authenticated.
* s'=Hash(s) if |s|>b, and s'=s otherwise.
* opad is the byte-string 0x5L repeated b times.
* ipad is the byte-string 0x36 repeated b times.
3.2. HKDF
HKDF is HMAC-based key derivation function [RFC5869]), which can be
used as a building block in various security protocols and
applicaions to extract and derive cryptographically secure keys.
HKDF is conscruted via the extract-then-expand approach. Namely,
HKDF(salt, ikm, CTXinfo, L) consists of two parts.
HKDF.Extract(salt, ikm) extracts a pseudorandom secret PRK from
inputs ikm and salt, and then HKDF.Extend(PRK, CTXinfo, L) extends
PRK to an output as work keys of desired length L, with respect to
context info CTXinfo. As this specification concerns HKDF.Extract,
but not HKDF.Extend, here just reviews HKDF.Extract(salt, ikm) as
following:
HKDF.Extract(salt, ikm)=HMAC(salt, ikm)
=Hash((salt' XOR opad)||Hash((salt' XOR ipad)||imk)) (2)
In the above, the following notations are used:
* Hash is a cryptographically hash function with bloc size b.
* imk is the input material key.
* salt'=Hash(salt) if |salt|>b, and salt'=salt otherwise.
* opad is the byte-string 0x5L repeated b times.
* ipad is the byte-string 0x36 repeated b times.
4. Existing Key Combiners for Multiple Keys
Wang & Wang Expires 24 October 2026 [Page 5]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
4.1. The Key Combiner for Multiple Keys from ETSI TS 103 744
ETSI TS 103 744 "Quantum-safe Hybrid Key Establishment" [ETSI25])
specifies two HMAC based key combiners for multiple keys (More
exactly, for three input keys). One called CatKDF that concatenates
the input keys, and the other CasKDF that cascades the inputs.
CatKDF is specified as the following (Refer to Section 8.2.3 in
[ETSI25]):
K=KDF(secret, label, context, length)
=HMAC(Secret, Data) (3)
=HMAC(label, counter||(psk||k1||k2)||f(info, MA, MB)) (repeatable)
In the above formula, the following notations are used:
* secret= psk||k1||k2, where psk is a PSK (preshared secret key), k1
and k2 are obtained by running traditional and PQ KEMs. Here, psk
could be obtained from QKD (Quantum Key Distribution).
* Context=f(info, MA, MB), where f is a context formatting function,
and MA, MB are the transcripts output by parties A and B,
respectively (Section 7.2 in [ETSI25]).
CasKDF is specified as the following (Refer to Section 8.3.3 in
[ETSI25]):
c_secret0 = psk
r_secret1=PRF(c_secret0, k1, MA1, MB1)
=HMAC(c_secret0, cahb_f(k1, MA1, MB1))
c_secret1||K1=KDF(r_secret1, label1, info1, k_len+length1)
=HMAC(label1, counter||r_secret1||info1) (repeatable) (4)
r_secret2=PRF(c_secret1, k2, MA2, MB2)
=HMAC(c_secret1, cahb_f(k2, MA2, MB2))
c_secret2||K2=KDF(r_secret2, label2, info2, k_len+length2)
=HMAC(label2, counter||r_secret2||info2) (repeatable)
In the above formula, the following notations are used:
* psk is a PSK (preshared secret key), k1 and k2 are obtained by
running traditional and PQ KEMs.
* psk is used salt, which can be obtained from QKD (Quantum Key
Distribution).
* f(ki, MAi, MBi) is a context formatting function, and MAi, MBi are
the transcripts output by parties A and B, respectively, for
producing the input key ki (Section 7.2 in [ETSI25]).
Wang & Wang Expires 24 October 2026 [Page 6]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
* K1 is used as an itermediate key, and K2 is the final output key
combined from psk, k1 and k2.
The security of the above two key combiners is summarized in ETSI TS
103 744 (refer to Appendix B.1 in [ETSI25]). Namely, CatKDF is IND-
CPA secure in the standard model and IND-CCA secure in the Random
Oracle model [PC23]. CasKDF is IND-CPA secure in the Random Oracle
model [CP21].
4.2. The Key Combiner for Multiple Keys from NIST SP800-133
NIST Special Publication 800-133 "Recommendation for Cryptographic
Key Generation" [SP800-133]) specifies the following key combiner
that derives symmetric keys from multiple keys and other data.
K=T(HMAC-hash(salt, K1||K2||...||Kn||D1|D2|| ...||Dn), kLen) (5)
In the above formula, the following conditions are required (refer to
Section 6.3 in [SP800-133]):
* n and m are two integers satisfying n>=1 and m>=0.
* T is the truncation function.
* The length of the output block of the hash function used with HMAC
shall be at least kLen bits, the required bit length for K.
* Alternative orderings are permitted when forming the concatenation
of keys and data (including interleaving the keys and data).
* data (D1, …, Dm) can also be combined with the Ki to form K the
condition that data shall be generated or obtained using methods
that ensure their independence from the values of the component
keys K1, …, Kn.
* The component keys Ki's shall be generated and/or established
independently (and subsequently protected as necessary) using
approved by NIST (refer to Sections 6.1 and 6.2 in [SP800-133])
that support a security strength that is equal to or greater than
the targeted security strength of the algorithm or application
that will rely on the output key K.
* Each component key Ki shall be kept secret and shall not be used
for any purpose other than the computation of a specific symmetric
key K.
As the authors' best of knowledge, there is no formal proof of the
above NIST SP 800-133 key combiner for keys from multiple keys.
Wang & Wang Expires 24 October 2026 [Page 7]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
4.3. The Key Combiner for Multiple Keys from draft-ounsworth-cfrg-kem-
combiners
Combiner Function for Hybrid Key encapsulation Mechanisms (Hybrid
KEMs) [I-D.OWK24] proposes the following general key combiner for
multiple keys generated by KEMs.
ss = KDF(counter || k_1 || ... || k_n || fixedInfo, outputBits) (6)
where k_i=ct_i||ss_i or Ki=ct_i||rlen(ct_i)||ss_i||rlen(ss_i), each
ss_i is obtained from the encapsulated ciphertext ct_i via running
one KEM algorihtm, and rlen(s) denotes the length in bytes of a
string s.
Moreover, the Internet draft also gives several practical
constructions, by intiating KDF as KMAC128, KMAC256, SHA3-256 or
SHA3-512, that are in compliance with NIST SP-800 56Cr2 [SP800-56C].
About the security of the the proposed constructions, [I-D.OWK24]
concludes that they "preserve IND-CCA2 of any of its ingredient KEMs,
i.e. the newly formed combined KEM is IND-CCA2 secure as long as at
least one of the ingredient KEMs is". And this result is based on
the condition that Keccak (i.e. KDF) behaves like a split-key
pseudorandom function as defined in [GHP18] . Namely, this means that
Keccak perfoms as a random function if at least one of the input
shared secrets is picked uniformly at random.
5. HMAC based Key Combiners for Multiple Keys (HKC)
Two versions of HMAC based Key Combiners for Multiple Keys (HKC) are
specified in this section, called version 1 (HKCv1) and version 2
[WWW25]. They target on different scenarios, as explained below.
5.1. HKC version 1 (HKCv1)
HKCv1 is designed for common scenarios where all the input keys are
simultaneously available for combining. Its design closely resembles
HKDF [RFC5869] and [K10], wherein HMAC functions as the extractor
during the extraction phase and as the PRF during the expansion
phase. In detail, HKCv1(SKM,SALT,CTX,L) is speficied as the
following:
PRK=HMAC(SALT,SKM)
K′=HMAC(PRK, CTX) (7)
K=Truncate(K′, L)
For the above formula, the notations and requirements are given
below:
Wang & Wang Expires 24 October 2026 [Page 8]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
* SKM = K1||K2 ||…||Kn, n>=2 is an integer. Namely, SKM is the
concatenation of all input keys.
* L≤k≤ min{|K1|,··· ,|Kn|}, where L is the final output length of
HKCv1, and k is the output length of HMAC.
* SALT is a salt value, which does not need to be secret, but it
should ideally be unpredictable or at least unique for different
contexts where the same SKM might arise.
* CTX, denoting the context info, includes information like protocol
identifiers, algorithm IDs, user IDs, nonces, etc., relevant to
the specific use case.
* The length of each string is in bytes, but it can be in bits as
well.
* Truncate(K', L) is the truncation fuction to return an outpt of
length L from the input K' with length k by cutting some necessary
bits in the end of K', where L≤k.
The length requirement L≤k≤ min{|K1|,··· ,|Kn|} implies that the
length of each input key ki is equal or greater than k, the output
length of HMAC. The integer k is also the length of the first
argument of HMAC or the output length of the hash function in HMAC.
DESIGN RATIONALE. This design leverages the well-established
security principles of HKDF, including its ability to handle
potentially weak inputs, the use of a salt for randomization and
preventing related-key attacks, and the use of the context parameter
for context separation. Widely adopted and analyzed, HKDF provides a
robust KDF framework suitable for general-purpose key combination.
We use concatenation to handle multiple input keys rather than
bitwise XOR (i.e, SKM = K1 XOR ... XOR Kn) as it is a more robust
method. Concatenation accommodates keys of varying lengths without
modification and preserves the entirety of the input material for
processing by the extractor HMAC, ensuring all contributed entropy is
available. In contrast, the XOR approach requires identical key
lengths, potentially requiring insecure padding or truncation
schemes, and is inherently vulnerable to information loss or
weakening due to cancellation effects if keys are repeated or possess
known algebraic relationships, which could compromise the security of
the derived key. Utilizing concatenation thus aligns with
established cryptographic standards and provides a more secure and
flexible foundation for the key derivation process.
Wang & Wang Expires 24 October 2026 [Page 9]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
INSTANTIATIONS. According to the security analysis given Section 6,
under the random oracle model, in which the underlying hash function
of HMAC can be modelled as a random fucntion, the two appearances of
HMAC in HKCv1 can use the same hash function. A typical
instantiation in this case is HMAC-SHA2-256. Namely, using the same
underlying hash fuction SHA2-256 for both appearances of HMAC.
In another case, where the underlying hash function of HMAC is just
δ-AU (δ-Almost Universal), the two appearances of HMAC in HKCv1 shall
use different underlying hash functions, to guarantee the formal
security proof. In this case, a typical instantiation for HKCv1 can
use HMAC with SHA2-512 truncated to 256 bits for the extractor and
HMAC with SHA2-256 for the PRF.
5.2. HKC version 2 (HKCv2)
HKCv2 is designed for key combination in scenarios involving
incrementally generated keys, leveraging the wellestablished extract-
then-expand paradigm using HMAC. In detail, HKCv2(SKM,SALT,CTX,L) is
speficied as the following:
S1=HMAC(SALT,K1)
Si=HMAC(S(i−1), Ki), 1<i≤n (8)
K′=HMAC(Sn, CTX)
K=Truncate(K', L)
For the above formula, the notations and requirements are given
below:
* K1, ..., and Kn are the input keys, where n>=2 is an integer.
* L≤k≤ min{|K1|,··· ,|Kn|}, where L is the final output length of
HKCv1, and k is the output length of HMAC.
* SALT is a salt value, which does not need to be secret, but it
should ideally be unpredictable or at least unique for different
contexts where the same SKM might arise.
* CTX, denoting the context info, includes information like protocol
identifiers, algorithm IDs, user IDs, nonces, etc., relevant to
the specific use case.
* The length of each string is in bytes, but it can be in bits as
well.
* Truncate(K', L) is the truncation fuction to return an outpt of
length L from the input K' with length k by cutting some necessary
bits in the end of K', where L≤k.
Wang & Wang Expires 24 October 2026 [Page 10]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
In HKCv2, randomness from the input keys (K1, ..., Kn) is accumulated
iteratively. Starting with an initial state derived from SALT and 1,
subsequent keys Ki are processed sequentially via repeated HMAC
applications. These first n HMAC computations collectively act as a
cryptographic extractor, yielding a final intermediate value Sn that
encapsulates the combined inputs. This value Sn then serves as the
key for the final HMAC operation, which functions as a PRF
incorporating the context CTX. Finally, the output K' is truncated
to the desired length L (where L k) to produce the output key K.
DESIGN RATIONALE. The design of HKCv2 is fundamentally motivated by
the requirement to support incremental key derivation. Unlike
concatenation-based HKCv1, HKCv2 employs an iterative extraction
process, embodied by the relation Si=HMAC(S(i-1), Ki). This
structure fits sequential key availability, allowing secure
incorporation of each key Ki into the state as it arrives.
Therefore, HKCv2 is a specialized construction optimized for
environments demanding secure key combination from non-concurrent
inputs.
Similarly to the analysis of HKCv1, the security of the output key K
against brute-force attacks is also bounded by k. With respect to
efficiency, HKCv2 executes n+1 HMAC operations. Although each
processes shorter inputs, the cumulative cost of n+1 HMAC
computations could outweigh HKCv1’s cost, particularly for small n.
However, for larger n or extremely long individual keys, HKCv2 avoids
the potentially prohibitive cost or memory requirement of creating
and processing the single large IKM required by HKCv1. Therefore,
the relative efficiency is context-dependent, influenced by the
number of input keys, their lengths, and also the performance profile
of the underlying HMAC implementation.
INSTANTIATIONS. In HKCv2, the two appearances of HMAC can be based
on the same underlying hash function or two different ones. A
typical instantiation is to select both of them as HMAC-SHA2-256.
Concrete selections depend on the scenarions, inluding the required
security strength, approved hash fuctions, the length of each input
key etc.
5.3. Comparison to the Existing Key Combiners for Multiple Keys
From the above desription, HKCv1 and HKCv2 are similar to CatKDF and
CasKDF specified in [ETSI25], reviewed in Section 4.1, as two
versions of key combiners are proposed for respectively two typical
scenarios, where input keys are availabe in parallel or in
sequential. However, thre are several differences between them,
which means that HKCv1 and HKCv2 can be used in more general
environments.
Wang & Wang Expires 24 October 2026 [Page 11]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
* CatKDF and CasKDF are just specified for three inpout keys, while
HKCv1 and HKCv2 are specified for two or more input keys.
* In calulation, context formatting function f(info, MA, MB) is
involved in CatKDF and CasKDF. This not only introduces overhead
for performance, may also bind their security of key combiner to
the transcripts of KEMs. In contrast, the execution of HKCv1 and
HKCv2 is decoupled from the specific way how each input key is
obtained.
* In the last, as discussed in Section 6, HKCv1 and HKCv2 have been
proved in stronger security model, comopared to CatKDF and CasKDF.
To compare HKCv1 and HKCv2 with SP800-133 key combiner reviewed in
Section 4.2, there are the following differences.
* SP800-133 does not specify a key combiner for scenarios where the
input keys are availalbe in sequential.
* To the authors' best knowledge, no formal security proofs are
given for the SP800-133 key combiner.
* As reviewed in Section 4.2, there are a number contrains on the
inpout keys for SP800-133 key combiner.
* In contrast to the contex info CTX in HKCv1 and HKCv2, the purpose
and use of the data (D1, ..., Dn) may need to be specified more
clearly.
To compare HKCv1 and HKCv2 with the key combiner speficied in
[I-D.OWK24], reviewed in Section 4.3, there are the following
differences.
* [I-D.OWK24] does not specify a key combiner for scenarios where
the input keys are availalbe in sequential.
* The key combiner given in [I-D.OWK24] is just for input keys
obtained via running KEMs. However, the inpout keys for HKCv1 and
HKCv2 can be obtained in various ways.
* Simliar to CatKDF and CasKDF specified by [ETSI25], the key
combiner in [I-D.OWK24] also needs to process the transcripts of
KEMs, which are normally large for PQ KEMs. In contrast, the
execution of HKCv1 and HKCv2 is decoupled from the specific way
how each input key is obtained.
6. Security Considerations
Wang & Wang Expires 24 October 2026 [Page 12]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
6.1. Security of HKCv1
As analysed in [WWW25], the basis of HMAC is the NMAC (Nested Message
Authentcation Code). So, before analyzing the suitability of HMAC as
an extractor, it is good to first review the security of NMAC. In
[K10], NMAC is evaluated as a secure randomness extractor under three
different cases.
* Random oracle: This is an idealized assumption by modelling the
outer function of NMAC as a random oracle, which assumes that NMAC
behave as a random functions that attackers can only query for a
limited number of times. In this condition, NMAC can be
considered as a good randomness extractor. However, such an
assumption cannot be directly applied to practical scenarios.
* m-blockwise Source: m-blockwise source is defined as each k-bit
input block has min-entropy m when conditioned on other blocks.
NMAC, when applied to these m-blockwise sources, has been
demonstrated to effectively function as a randomness extractor
under security assumptions regarding the underlying compression
functions. However, this assumption with respect to m-blockwise
sources is not applicable to the scenario of key combiners. In
the HKCv1 scheme, the input to the extractor is formed by
concatenating all input keys. The min-entropy of this
concatenated input consequently depends on the security level of
the constituent keys. Crucially, the possibility that some keys
might be fully compromised by attackers, meaning those keys have
zero min-entropy, precludes modeling the overall input source as
an m-blockwise source.
* Truncated NMAC: Using a truncated version of NMAC is an efficient
approach to circumvent constraints imposed on the min-entropy of
each input block. Indeed, using NMAC with a truncated output as
an extractor not only enhances HKCv1’s resilience against strong
attacks but also make it possible to prove the security of HKCv1
under considerably weaker assumptions on the underlying hash
function.
Therefore, [WWW25] shows that HKCv1 is a provably secure randomness
extractor, under the condition that the underlying hash fuction of
HMAC is δ-AU (δ-Almost Universal), with together the above result
that truncated NMAC is a secure randomness extractor. Note that any
collision-resistant hash family must possess the δ-AU property (for
some value δ). So, this implies that HKCv1 is secure under much
weaker assumption, compared to the key combiner for multiple keys
specified by ETSI TS 103 744 (refer to Appendix B.1 in [ETSI25]).
Namely, CatKDF reviewed in Section 4.1 is IND-CPA secure in the
standard model and IND-CCA secure in the Random Oracle model [PC23].
Wang & Wang Expires 24 October 2026 [Page 13]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
6.2. Security of HKCv2
HKCv2 follows the same fundamental design strategy as HKCv1. The
only difference lies in the extraction phase: HKCv2 constructs its
extractor via iterative calls to HMAC. Consequently, the security
analysis only needs to address its specific extractor construction.
For the HKCv2 scheme, the extractor is constructed by n iterative
calls of HMAC, each can be regarded as a sub-extractor for a single
input block.
In the random oracle model, where the compression function is modeled
as a random oracle, a random oracle can output all the entropy of the
source. Therefore, HMAC serving as a computational extractor for a
single input block also holds under this idealized assumption. Under
the above assumptions, the extractor of HKCv2 is proved to be a IND-
CCA secure computational extractor as long as one of the input keys
has enough min-entropy. Details are refer to Section 6.4 in [WWW25].
Similar to HKCv2, CasKDF is also a scheme for scenarios where the
imputs keys may be available gradually. Compared to their security,
CasKDF is IND-CPA secure [CP21] and HKCv2 is IND-CCA secure, both in
the Random Oracle model.
7. IANA Considerations
There are no IANA Considerations for this specification.
8. Acknowledgments
TBD.
9. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
Wang & Wang Expires 24 October 2026 [Page 14]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/info/rfc9370>.
[NIST.IR.8547]
Moody, D., Perlner, R., Regenscheid, A., Robinson, A., and
D. Cooper, "Transition to Post-Quantum Cryptography
Standards", NIST Internal Report, NIST IR 8547 ipd,
November 2024, <https://csrc.nist.gov/pubs/ir/8547/ipd>.
[SP800-133]
Barker, E., Roginsky, A., and R. Davis, "Recommendation
for Cryptographic Key Generation", NIST Special
Publication 800-133 (Revision 2) , June 2020,
<https://csrc.nist.gov/pubs/sp/800/133/r2/final>.
[ETSI25] "Quantum-safe Hybrid Key Establishment", ETSI TS 103 744
v1.2.1 , March 2025, <https://www.etsi.org/deliver/
etsi_ts/103700_103799/103744/01.02.01_60/
ts_103744v010201p.pdf>.
Wang & Wang Expires 24 October 2026 [Page 15]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
[FIPS203] National Institute of Standards and Technology, "FIPS 203:
Module-Lattice-Based Key-Encapsulation Mechanism
Standard", Federal Information Processing Standards
Publication , August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.pdf>.
10. Informative References
[I-D.OWK24]
Ounsworth, M., Wussler, A., and S. Kousidis, "Combiner
Function for Hybrid Key Encapsulation Mechanisms (Hybrid
KEMs)", Work in Progress (v05), Internet-Draft, August
2024, <https://datatracker.ietf.org/doc/draft-ounsworth-
cfrg-kem-combiners/>.
[I-D.CBG24]
Connolly, D., Barnes, R., and P. Grubbs, "Hybrid PQ/T Key
Encapsulation Mechanisms", Internet Research Task Force
(IRTF), Work in Progress (v05), July 2024,
<https://datatracker.ietf.org/doc/draft-irtf-cfrg-hybrid-
kems/>.
[PM16] Perrin, T. and M. Marlinspike, "The Double Ratchet
Algorithm", Revision 1 , November 2016,
<https://signal.org/docs/specifications/doubleratchet/>.
[K10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proc. of Cypto 2010, LNCS
6223, Springer-Verlag, pp.631-648, August 2010,
<https://link.springer.com/
chapter/10.1007/978-3-642-14623-7_34>.
[BBGS23] Backendal, M., Bellare, M., Günther, F., and M. Scarlata,
"When Messages Are Keys: Is HMAC a Dual-PRF?", Proc. of
Cypto 2023 (Part III), LNCS 14083, Springer-
Verlag, pp.661-693, August 2023,
<https://link.springer.com/
chapter/10.1007/978-3-031-38548-3_22>.
[WWW25] Wang, H., Wang, T., and G. Wang, "New Key Combiner Schemes
for Multiple Keys", In the Proc. of Inscrypt 2025,
Springer (to appear) , October 2025.
Wang & Wang Expires 24 October 2026 [Page 16]
Internet-Draft Hybrid Key Combiners for Multiple Keys April 2026
[ADK22] Aviram, N., Dowling, B., Komargodski, I., Paterson, K.,
Ronen, E., and E. Yogev, "Practical (post-quantum) key
combiners from one-wayness and applications to tls",
Cryptology ePrint Archive, IACR 2022-065, February 2022,
<https://eprint.iacr.org/2022/065>.
[SP800-56C]
Barker, E., Chen, L., and R. Davis, "Recommendation for
Key-Derivation Methods in Key-Establishment Schemes", NIST
Special Publication 800-56C , August 2020,
<https://doi.org/10.6028/NIST.SP.800-56Cr2>.
[GHP18] Giacon, F., Heuer, F., and B. Poettering, "Cryptographic
Extraction and Key Derivation: The HKDF Scheme", Proc. of
Public-Key Cryptography (PKC 2018), LNCS 10769, Springer-
Verlag, pp.159-189, March 2018,
<https://doi.org/10.1007/978-3-319-76578-5_7>.
[CP21] Campagna, M. and A. Petcher, "Security of Hybrid Key
Encapsulation", Cryptology ePrint Archive, IACR 2020-1364,
January 2021, <https://eprint.iacr.org/2020/1364>.
[PC23] Petcher, A. and M. Campagna, "Security of Hybrid Key
Establishment using Concatenation", Cryptology ePrint
Archive, IACR 2023-972, June 2023,
<https://eprint.iacr.org/2023/972>.
Authors' Addresses
Guilin Wang (editor)
Huawei Int. Pte Ltd
9 North Buona Vista Drive, #13-01
The Metropolis Tower 1
SINGAPORE 138588
Singapore
Email: wang.guilin@huawei.com
Haoyang Wang
Shanghai Jiaotong University
800 Dongchuan Road
Minhang, Shanghai 200240
China
Email: haoyang.wang@sjtu.edu.cn
Wang & Wang Expires 24 October 2026 [Page 17]