



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]
