| Internet-Draft | Hybrid Key Combiners for Multiple Keys | October 2025 |
| Wang & Wang | Expires 23 April 2026 | [Page] |
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 proveably secure constructions of key combiners for multiple keys [WWW25], which is particularly useful in post-quantum migration where multiple input keys are 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: .... ]¶
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 23 April 2026.¶
Copyright (c) 2025 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.¶
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 coming communications via symmetric-key cryptography. However, the original input keys may not always be uniformly random or may be even partially known to an 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, the multiple key exchange framework [RFC9370] is specified 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 direved from them, and CTXinfo means some context info specific to the protocol and the a particular execution. For example, the key schedule of TLS 1.3 (refer to Section 7.1 in [RFC7296]) is essentially to obtain a Master Key by running HAMC as the above 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 is actually requiring 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 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 derives keys from a single high-entropy source, which can be the ouput 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 comibers 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 are decoupled with the transcripts of how each input key is obtained. 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 dicussed in Section 6.¶
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.¶
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)
¶
In the above, the following notations are used:¶
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:¶
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:¶
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:¶
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].¶
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]):¶
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.¶
Combiner Function for Hybrid Key encapsulation Mechanisms (Hybrid KEMs) [I-D.OWK24] proposes the following general key combier 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 Internt 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.¶
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.¶
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:¶
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.¶
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 HCKv1 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 HCKv1 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.¶
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:¶
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.¶
From the above desription, HCKv1 and HCKv2 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 HCKv1 and HCKv2 can be used in more general environments.¶
To compare HCKv1 and HCKv2 with SP800-133 key combiner reviewed in Section 4.2, there are the following differences.¶
To compare HCKv1 and HCKv2 with the key combiner speficied in [I-D.OWK24], reviewed in Section 4.3, there are the following differences.¶
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.¶
Therefore, [WWW25] shows that HCKv1 is a proveably 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 HCKv1 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].¶
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 HCKv2, 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 HCKv2 is IND-CCA secure, both in the Random Oracle model.¶
There are no IANA Considerations for this specification.¶
TBD.¶