]> SandboxAQ

durumcrustulum@gmail.com

Cisco

rlb@ipv.sx

University of Michigan

paulgrubbs12@gmail.com

Crypto Forum This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. Discussion Venues Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Post-quantum (PQ) cryptographic algorithms are based on problems that are conjectured to be resistant to attacks possible on a quantum computer. Key Encapsulation Mechanisms (KEMs) are a standardized class of cryptographic scheme that can be used to build protocols in lieu of traditional, quantum-vulnerable variants such as finite field or elliptic curve Diffie-Hellman (DH) based protocols. Given the novelty of PQ algorithms, however, there is some concern that PQ algorithms currently believed to be secure will be broken. Hybrid constructions that combine both PQ and traditional algorithms can help moderate this risk while still providing security against quantum attacks. If constructed properly, a hybrid KEM will retain certain security properties even if one of the two constituent KEMs is compromised, for whatever reason that compromise might occur. If the PQ KEM is broken, then the hybrid KEM should continue to provide security against non-quantum attackers by virtue of its traditional KEM component. If the traditional KEM is broken -- whether by a quantum computer running a polynomial-time attack or by some classical cryptanalytic advance -- then the hybrid KEM should continue to resist quantum attacks by virtue of its PQ KEM component. The advent of quantum computing lends particular urgency to the latter case, but the hybrid construction guards against the failure of either component regardless of the cause. In addition to guarding against algorithm weaknesses, this property also guards against flaws in implementations, such as timing attacks. Hybrid KEMs can also facilitate faster deployment of PQ security by allowing applications to incorporate PQ algorithms while still meeting compliance requirements based on traditional algorithms. In this document, we define generic frameworks for constructing hybrid KEMs from a PQ KEM and a traditional algorithm. The aim of this document is to provide a small set of techniques to achieve specific security properties given conforming component algorithms, which should make these techniques suitable for a broad variety of use cases. We define four generic frameworks as variants of a common overall scheme. The variations are based on (1) what type of cryptographic object is being used for the traditional component, and (2) whether the PQ KEM is assumed to have an additional property known as Ciphertext Second Preimage Resistance (C2PRI). Hybrid KEMs built using PQ KEMs that satisfy C2PRI can achieve the same security level with more efficient computations, trading off performance for an additional security assumption. The remainder of this document is structured as follows: first, in and , we define the abstractions on which the frameworks are built, and then the frameworks themselves. Then, in , we lay out the security analyses that support these frameworks, including the security requirements for constituent components and the security notions satisfied by hybrid KEMS constructed according to the frameworks in the document . Finally, we discuss some "path not taken", related topics that might be of interest to readers, but which are not treated in depth.

Requirements Notation 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 when, and only when, they appear in all capitals, as shown here.

Notation This document is consistent with terminology defined in . In particular, this document defines PQ/T Hybrid KEMs, where "PQ" refers to the post-quantum component and "T" to the traditional component. Hexadecimal values 0x... represent byte strings (not integers). We write x $← {0,1}ⁿ to denote drawing x uniformly at random from the set of n-bit strings, denoted {0,1}ⁿ. A function f that maps from one domain to another is denoted using a right arrow to separate inputs from outputs: f : inputs → outputs. Constants and algorithms belonging to a particular component are written using dot notation, e.g., KEM_PQ.Nseed for the seed length of the PQ KEM or Group_T.Exp for the exponentiation map of the traditional group. The same symbol (such as Nseed or Nout) may name the analogous quantity for different components; the component prefix disambiguates these uses. The following functions are used throughout this document:

• random(n): return a pseudorandom byte string of length n bytes produced by a cryptographically-secure random number generator.
• concat(x0, ..., xN): Concatenation of byte strings. For example, concat(0x01, 0x0203, 0x040506) = 0x010203040506.
• split(N1, N2, x): Split a byte string x of length N1 + N2 into its first N1 bytes and its last N2 bytes. This function is the inverse of concat(x1, x2) when x1 is N1 bytes long and x2 is N2 bytes long. It is an error to call this function with a byte string that does not have length N1 + N2. Since this function operates over secret data x, it MUST be constant-time with regard to the contents of the bytes in x, for given non-secret lengths N1 and N2.

Cryptographic Dependencies The generic hybrid PQ/T KEM frameworks we define depend on the following cryptographic primitives:

• Key Encapsulation Mechanisms ()
• Nominal Groups ()
• Pseudorandom Generators ()
• Key Derivation Functions ()

In the remainder of this section, we describe functional aspects of these mechanisms. The security properties we require in order for the resulting hybrid KEM to be secure are discussed in .

Key Encapsulation Mechanisms | Decaps | +--------+ +--------+ | | | | V V ss == ss ]]> A Key Encapsulation Mechanism (KEM) comprises the following algorithms:

• GenerateKeyPair() -> (dk, ek): A randomized algorithm that generates a secret decapsulation key dk and a public encapsulation key ek, each of which are byte strings.
• DeriveKeyPair(seed) -> (dk, ek): A deterministic algorithm that takes as input a seed seed and generates a secret decapsulation key dk and a public encapsulation key ek, each of which are byte strings.
• Encaps(ek) -> (ss, ct): A probabilistic encapsulation algorithm, which takes as input a public encapsulation key ek and outputs a shared secret ss and ciphertext ct.
• Decaps(dk, ct) -> ss: A deterministic decapsulation algorithm, which takes as input a secret decapsulation key dk and ciphertext ct and outputs a shared secret ss.

In the notation above, Decaps is written as if it always returns an output ss; this is an artifact of the Python-like pseudocode used in this document. In the event of a decapsulation failure, Decaps MAY instead return an error. This allows the KEM interface to represent both implicitly rejecting KEMs -- such as ML-KEM, which produce a deterministic pseudorandom output on invalid ciphertexts -- and explicitly rejecting KEMs, which return an error. The security analyses in take this variation into account. We assume that the values produced and consumed by the above functions are all byte strings, with fixed lengths:

• Nseed: The length in bytes of a key seed
• Nek: The length in bytes of a public encapsulation key
• Ndk: The length in bytes of a secret decapsulation key
• Nct: The length in bytes of a ciphertext produced by Encaps
• Nss: The length in bytes of a shared secret produced by Encaps or Decaps

Nominal Groups | Exp | | Exp |<-+ | +-----+ +-----+ | | | | | | | | | | V V | | pkA pkB | | | | | skA --+ +-------------. .-------------+ +-- skB | \/ | | /\ | | +-------------' '-------------+ | | | | | | V V | | +-----+ +-----+ | +->| Exp | | Exp |<-+ +-----+ +-----+ | | | | V V pkAB ========================= pkBA ]]> Nominal groups are an abstract model of the groups over which we instantiate Diffie-Hellman key agreement . In practice they are instantiated with elliptic curve groups, but the model applies to other groups as well. A nominal group comprises a set G together with a distinguished basis element g, an "exponentiation" map, and some auxiliary functions:

• Exp(p, x) -> q: An algorithm that produces an element q of G from an element p and an integer x.
  • The integers x are called "scalars" to distinguish them from group elements. The nominal group G is assumed to comprise a finite number of elements r; scalars are integers modulo r, and all operations on scalars are implicitly performed modulo r.
  • Exp must respect multiplication in its scalar argument x, so that Exp(Exp(p, x), y) = Exp(p, x * y).
• RandomScalar(seed) -> k: Produce a uniform pseudorandom scalar from the uniformly pseudorandom byte string seed.
• ElementToSharedSecret(P) -> ss: Extract a shared secret from an element of the group (e.g., by taking the X coordinate of an elliptic curve point).

A scalar value of zero MUST NOT be used as a private key: it does not correspond to a meaningful Diffie-Hellman exchange and, for some curves such as P-256, is explicitly forbidden by the relevant standards and would yield a point-at-infinity encoding that departs from the fixed-size model used here. RandomScalar MUST NOT return a zero scalar; for the groups of interest this occurs only with negligible probability. For some groups (for example P-256 and ristretto255), there exist byte strings of the correct length that do not decode to a valid group element. When Exp is given such an invalid element, it returns an error rather than a shared secret. A hybrid KEM whose nominal group can fail in this way is an instance of an explicitly rejecting KEM (see ): when Group_T.Exp returns an error during decapsulation, the hybrid KEM_H.Decaps returns an error. This operates only on public data (the ciphertext), so failing explicitly rather than substituting a pseudorandom shared secret is safe. We assume that scalars and group elements are represented by byte strings with fixed lengths:

• Nseed: The length in bytes of a seed (input to RandomScalar)
• Nscalar: The length in bytes of a scalar
• Nelem: The length in bytes of a serialized group element
• Nss: The length in bytes of a shared secret produced by ElementToSharedSecret

Groups used with the hybrid KEM framework in this document should be secure with respect to the strong Diffie-Hellman problem (see ).

Pseudorandom Generators A pseudorandom generator (PRG) is a deterministic function whose outputs are longer than its inputs. When the input is chosen uniformly at random, this induces a certain distribution over the possible outputs. The output distribution is pseudorandom if it is indistinguishable from the uniform distribution. The PRGs used in this document have a simpler form, with fixed output lengths:

• Nout: The length in bytes of an output from this PRG. Where it is necessary to distinguish it from the output length of other components (such as the KDF), it is written PRG.Nout.
• PRG(seed) -> output: Produce a byte string of length Nout from an input byte string seed.

The fixed sizes are for both security and simplicity. A PRG used with the frameworks in this document MUST be a secure pseudorandom generator (as defined in ) at the security level required by the component algorithms it feeds. It expands a single seed into a longer output, of which a subset is passed to each component's key-generation algorithm. The security requirements for PRGs used with the frameworks in this document are laid out in .

Key Derivation Functions A Key Derivation Function (KDF) is a function that produces keying material based on an input secret and other information. While KDFs in the literature can typically consume and produce byte strings of arbitrary length, the KDFs used in this document have a simpler form, with fixed output lengths:

• Nout: The length in bytes of an output from this KDF. Where it is necessary to distinguish it from the output length of other components (such as the PRG), it is written KDF.Nout.
• KDF(input) -> output: Produce a byte string of length Nout from an input byte string.

The fixed sizes are for both security and simplicity. Any KDF that utilizes HKDF MUST fully specify HKDF's salt, IKM, info, and L arguments. The security requirements for KDFs used with the frameworks in this document are laid out in .

Hybrid KEM Frameworks In this section, we define four frameworks for building hybrid KEMs. These frameworks are based on a common set of subroutines for things like key generation and computing a final shared secret. The four frameworks vary along two axes:

1. Whether traditional component is a nominal group or a KEM
2. Whether to rely on the C2PRI property for the post-quantum component

The choice of which framework to use when building a hybrid KEM will depend on the application's needs along these two axes. Hybrid KEM frameworks

Name	PQ C2PRI?	T component
UG	No	Nominal group
UK	No	KEM
CG	Yes	Nominal group
CK	Yes	KEM

Instantiating one of these frameworks creates a hybrid KEM KEM_H based on the following constituent components:

• A traditional component that is either a nominal group Group_T or a KEM KEM_T (referred to as Comp_T when the distinction doesn't matter).
• KEM_PQ: A post-quantum KEM
• PRG: A PRG producing byte strings of length KEM_PQ.Nseed + Comp_T.Nseed (PRG.Nout == KEM_PQ.Nseed + Comp_T.Nseed)
• KDF: A KDF producing byte strings of length KEM_H.Nss (KDF.Nout == KEM_H.Nss)
• Label - A byte string used to label the specific combination of the above components being used, as well as which framework is being instantiated. This value should be registered in the Hybrid KEM Labels IANA registry to avoid conflict with other instantiations (see ).

KEM_PQ, Group_T, PRG, and KDF MUST meet the interfaces described in and MUST meet the security requirements described in . The constants for public values are derived from the concatenation of encapsulation keys and ciphertexts: The Nseed and Nss constants should reflect the overall security level of the combined KEM, with the following recommended values: Since we use the seed as the decapsulation key, Ndk = Nseed. For legacy cases where it is not possible to derive per-component decapsulation keys from a common seed, see .

Subroutines The four hybrid KEM frameworks share a substantial amount of structure, which we capture in a set of subroutines.

Using a Nominal Group Hybrid KEM frameworks that use a nominal group for the traditional component invoke the DeriveKeyPair, Encaps, and Decaps functions of PQ KEMs, alongside analogous functions of the nominal group. The "encapsulation key" is the receiver's public key group element; the "ciphertext" is an ephemeral group element; and the shared secret is the secret value resulting from an ephemeral-static Diffie-Hellman exchange.

Using a Traditional KEM Hybrid KEM frameworks that use a KEM for the traditional component invoke the DeriveKeyPair, Encaps, and Decaps functions of the traditional and PQ KEMs in parallel.

Combiners A combiner function uses the KDF used in the hybrid KEM to combine the shared secrets output by the component algorithms with contextual information. The two combiner functions defined in this document are as follows: Note that while the names of the inputs are suggestive of the shared secret, ciphertext, and encapsulation key outputs of a KEM, the inputs to this function in the hybrid KEM framework are not necessarily the output of a secure KEM. In particular, when the framework is instantiated with a nominal group, the "ciphertext" component is an ephemeral group element, and the "encapsulation key" is the group element that functions as the recipient's public key. The choice of combiner brings with it certain assumptions under which the resulting hybrid KEM is secure. The UniversalCombiner combiner explicitly computes over shared secrets, ciphertexts, and encapsulation keys from both components. This allows the resulting hybrid KEM to be secure as long as either component is secure, with no further assumptions on the components. The C2PRICombiner combiner does not compute over the ciphertext or encapsulation key from the PQ component. The resulting hybrid KEM will be secure if the PQ component is IND-CCA secure, or, the traditional component is secure and the PQ component also satisfies the C2PRI property.

Key Generation All four frameworks share a common key generation function, and a function to compute the encapsulation key that corresponds to a decapsulation key: In some deployment environments, it is not possible to instantiate this process. Some implementations of component schemes do not support the DeriveKeyPair function, only GenerateKeyPair. Likewise in the nominal group case, a (scalar, group element) pair will only be generated when the scalar is generated internally to the implementation. An implementation of a hybrid KEM in such environments MAY deviate from the above description in the following ways:

• DeriveKeyPair is not implemented.
• GenerateKeyPair returns a decapsulation key that carries both the decapsulation and encapsulation keys of each component, rather than a shared seed: Each element can be a key or a pointer/handle to a key. Carrying the component encapsulation keys explicitly avoids relying on the ability to recompute an encapsulation key from a decapsulation key, which is not supported by all KEM algorithms or implementations (for example, some hardware modules do not expose such a function).
• The expandDecapsKeyG and expandDecapsKeyK functions are replaced by the following, which simply extracts the stored components:

These deviations have both interoperability and security impacts. From an interoperability point of view, the use of a second format for the hybrid KEM decapsulation key (other than the shared seed) introduces the risk of incompatibilities in cases where a private key needs to be moved from one system to another. Separate key generation / handling also reduces binding properties from MAL-BIND-P-Q to LEAK-BIND-P-Q. As discussed below, binding properties can address a variety of attack scenarios, including LEAK scenarios in which an attacker has passive access to the decapsulation key and MAL scenarios in which an attacker can cause the victim to use a crafted decapsulation key. The above hybrid KEM framework assures binding properties in the face of a LEAK attacker, irrespective of how key generation is done. The additional protection provided by the default "shared seed" key generation upgrades this to protection against a MAL attacker. Allowing for separate private key generation and handling also introduces a risk of inappropriate key reuse and cross-protocol attacks. A given key pair MUST NOT be used in both a hybrid KEM and a non-hybrid algorithm. A pair of key pairs generated for a hybrid algorithm MUST only be used with that hybrid algorithm, not separately with their component algorithms. Likewise, key pairs generated outside of the context of a hybrid KEM MUST NOT be used with a hybrid KEM. The "shared seed" style of key generation prevents such reuse, because the per-component private keys are derived internally to the hybrid KEM. As a result, this alternative style of key generation should only be used in environments where implementations of component algorithms do not allow decapsulation keys to be imported or exported. In scenarios where separate key generation is used and decapsulation keys can be imported/exported, additional measures should be put in place to mitigate the key reuse risks noted above.

UG Framework: Universal Combiner with a Nominal Group This framework combines a PQ KEM with a nominal group, using the universal combiner function. It should be used in cases where the application wants to use a nominal group for the traditional component, and does not want to rely on the C2PRI assumption for the PQ KEM.

UK Framework: Universal Combiner with a KEM This framework combines a PQ KEM with a traditional KEM, using the universal combiner function. It should be used in cases where the application wants to use a KEM for the traditional component, and does not want to rely on the C2PRI assumption for the PQ KEM.

CG Framework: C2PRI Combiner with a Nominal Group This framework combines a PQ KEM with a nominal group, using the C2PRI combiner function. It should be used in cases where the application wants to use a nominal group for the traditional component, and is comfortable relying on the C2PRI assumption for the PQ KEM.

CK Framework: C2PRI Combiner with a KEM This framework combines a PQ KEM with a traditional KEM, using the C2PRI combiner function. It should be used in cases where the application wants to use a KEM for the traditional component, and is comfortable relying on the C2PRI assumption for the PQ KEM.

Security Considerations Hybrid KEMs provide security by combining two or more schemes so that security is preserved if all but one scheme is broken. Informally, these hybrid KEMs are secure if the KDF is secure, and either the traditional component is secure, or the post-quantum KEM is secure: this is the 'hybrid' property. In this section, we review the important security properties for hybrid KEMs, and discuss how these security properties are provided by hybrid KEMs constructed according to the framework in this document.

Security Properties for Component Algorithms In order to precisely define our security objectives for a hybrid KEM, we need to describe some properties that we will require from the component algorithms.

Indistinguishability under Chosen Ciphertext Attack (IND-CCA) The first goal we have for our hybrid KEM constructions is indistinguishability under adaptive chosen ciphertext attack, or IND-CCA . This is most common security goal for KEMs and public-key encryption. For KEMs, IND-CCA requires that no efficient adversary, given a ciphertext obtained by running Encaps() with an honestly-generated public key, can distinguish whether it is given the "real" secret output from Encaps(), or a random string unrelated to the Encaps() call that created that ciphertext. (Readers should note that this definition is slightly different than the corresponding definitions for public-key encryption .) Whether a given KEM provides IND-CCA depends on whether the attacker is assumed to have access to quantum computing capabilities or not (assuming the scheme is without bugs and the implementation is correct). Post-quantum KEMs are intended to provide IND-CCA security against such an attacker. Traditional KEMs are not. IND-CCA is the standard security notion for KEMs; most PQ KEMs were explicitly designed to achieve this type of security against both a quantum attacker and a traditional one. For traditional algorithms, things are less clear. The DHKEM construction in is an IND-CCA KEM based on Diffie-Hellman , but "raw" ephemeral-static Diffie-Hellman, interpreting the ephemeral public key as the ciphertext, is not IND-CCA secure. RSA-KEM is IND-CCA secure , and RSA-OAEP public-key encryption can be used to construct an IND-CCA KEM, but "classical" RSA encryption (RSAES-PKCS1-v1_5 as defined in ) is not even IND-CCA secure as a public-key encryption algorithm.

Ciphertext Second-Preimage Resistance (C2PRI) Ciphertext Second-Preimage Resistance (C2PRI) is the property that given an honestly generated ciphertext, it is difficult for an attacker to generate a different ciphertext that decapsulates to the same shared secret. In other words, if an honest party computes (ss, ct) = Encaps(ek), then it is infeasible for an attacker to find another ciphertext ct' such that Decaps(dk, ct') == ss (where dk is the decapsulation key corresponding to the encapsulation key ek). A related notion in the literature is chosen-ciphertext resistance (CCR) . C2PRI targets preimage-resistance, whereas CCR targets collision-resistance, much like the analogous properties for hash functions. In the language of the binding properties discussed in , CCR is equivalent to the property LEAK-BIND-K,PK-CT. C2PRI is a weaker property than CCR / LEAK-BIND-K,PK-CT because it requires the attacker to match a specific, honestly generated ciphertext, as opposed to finding an arbitrary pair. Several PQ KEMs have been shown to have C2PRI. ML-KEM was shown to have this property in , and proves C2PRI for several other algorithms, including FrodoKEM, HQC, Classic McEliece, and sntrup.

Strong Diffie-Hellman Problem (SDH) The strong Diffie-Hellman problem is whether an attacker can compute g^xy given access to g^x and g^y and an oracle DH(Y, Z) that answers whether Y^x = Z. (This is the notion specified in , not the notion of the same name used in the context of bilinear pairings .) When we say that the strong Diffie-Hellman problem is hard in a group, we always mean this in the context of classical attackers, without access to quantum computers. An attacker with access to a quantum computer that can execute Shor's algorithm for a group can efficiently solve the discrete log problem in that group, which implies the ability to solve the strong Diffie-Hellman problem. As shown in , this problem is hard in prime-order groups such as the NIST elliptic curve groups P-256, P-384, and P-521, as well as in the Montgomery curves Curve25519 and Curve448.

Binding Properties It is often useful for a KEM to have certain "binding" properties, by which certain parameters determine certain others. Recent work gave a useful framework of definitions for these binding properties. Binding for KEMs is related to other properties for KEMs and public-key encryption, such as robustness , and collision-freeness . The framework given by refers to these properties with labels of the form X-BIND-P-Q. The first element X is the model for how the attacker can access the decapsulation key: HON for the case where the attacker never accesses the decapsulation key, LEAK for the case where the attacker has access to the honestly-generated decapsulation key, or MAL for the case where the attacker can choose or manipulate the keys used by the victim. P-Q means that given the value P, it is hard to produce another Q that causes Decaps to succeed. For example, LEAK-BIND-K-PK means that for a given shared secret (K) obtained using an encapsulation key (PK), it is computationally infeasible to find a distinct encapsulation key (PK') that could have produced the same shared secret, even if all of the secrets involved are given to the adversary after the encapsulation operation is completed (LEAK). There is quite a bit of diversity in the binding properties provided by KEMs. Table 5 of shows the binding properties of a few KEMs. For example: DHKEM provides MAL-level binding for several properties. ML-KEM provides only LEAK-level binding . Classic McEliece provides MAL-BIND-K-CT, but no assurance at all of X-BIND-K-PK.

Indifferentiability from a Random Oracle The KDF used with a hybrid KEM MUST be indifferentiable from a random oracle (RO) , even to a quantum attacker . This is a conservative choice given a review of the existing security analyses for our hybrid KEM constructions: most IND-CCA analyses for the four frameworks require only that the KDF is some kind of pseudorandom function, but the SDH-based IND-CCA analysis of CG in , and the corresponding analysis for UG relies on the KDF being a RO. Proofs of our target binding properties for our hybrid KEMs require the KDF is a collision-resistant function. If the KDF is a RO, the key derivation step in the hybrid KEMs can be viewed as applying a (RO-based) pseudorandom function - keyed with the shared secrets output by the constituent KEMs - to the other inputs. Thus, analyses which require the KDF to be a PRF, such as the one given in for UK, or the standard-model analysis of CG in , apply. Sponge-based constructions such as SHA-3 have been shown to be indifferentiable against classical as well as quantum adversaries . HKDF has been shown to be indifferentiable from a random oracle under specific constraints :

• that HMAC is indifferentiable from a random oracle, which for HMAC-SHA-256 has been shown in when the compression function underlying SHA-256 is a random oracle, which is a regular assumption in the literature.
• the input domains used by HKDF's internal HMAC calls are disjoint. Following Lemma 6 of , it suffices that the domains for IKM, for info || 0x01, and for m || info || i (for i >= 2, where m is an HMAC output) are pairwise disjoint. In general this is easily achieved by considerations of length alone: it suffices that len(IKM) differs from len(info) + 1 and from len(info) + 1 + len(HMAC output). This MUST be enforced by the concrete instantiations that use HKDF as a KDF.

Using HKDF as a KDF in the sense defined in this document requires mapping the single input defined here to the IKM, salt, and info inputs required by HKDF. Concrete instantiations MUST define this mapping in such a way that no input value will ever map to colliding IKM and info values. The choice of the KDF security level SHOULD be made based on the security level provided by the constituent KEMs. The KDF SHOULD at least have the security level of the strongest constituent KEM.

Security Requirements for PRGs The functions used to expand a key seed to multiple key seeds is closer to a pseudorandom generator (PRG) in its security requirements . A secure PRG is an algorithm PRG : {0, 1}ⁿ → {0, 1}^m, such that no polynomial-time adversary can distinguish between PRG(r) (for r $← {0, 1}ⁿ) and a random z $← {0, 1}^m . The uniform string r ∈ {0, 1}ⁿ is called the seed of the PRG. A PRG is not to be confused with a random (or pseudorandom) number generator (RNG): a PRG requires the seed randomness to be chosen uniformly and extend it; an RNG takes sources of noisy data and transforms them into uniform outputs. PRGs are related to extendable output functions (XOFs) which can be built from random oracles. Examples include SHAKE256.

Security Goals for Hybrid KEMs The security notions for hybrid KEMs are largely the same as for other algorithms, but they are contingent on the security properties of the component algorithms. In this section we discuss the intended security properties for hybrid KEMs and the requirements that the component algorithms must meet in order for those properties to hold.

IND-CCA Security The idea of a hybrid KEM is that it should maintain its security if only one of the two component KEMs is secure. For a PQ/T hybrid KEM, this means that the hybrid KEM should be secure against a quantum attacker if the T component is broken, and secure against at least a classical attacker if the PQ component is broken. More precisely, the hybrid KEM should meet two different notions of IND-CCA security, under different assumptions about the component algorithms:

• IND-CCA against a classical attacker if all of the following are true:
  • KDF is indifferentiable from a random oracle
  • If using Group_T: The strong Diffie-Hellman problem is hard in Group_T
  • If using KEM_T: KEM_T is IND-CCA against a classical attacker
  • If using C2PRICombiner: KEM_PQ is C2PRI
• IND-CCA against a quantum attacker if all of the following are true:
  • KDF is indifferentiable from a random oracle
  • KEM_PQ is IND-CCA against a quantum attacker

Some IND-CCA analyses do not strictly require the KDF to be indifferentiable from a random oracle; they instead only require a kind of PRF assumption on the KDF. For simplicity we ignore this here; the security analyses described below for our constructions will elaborate on this point when appropriate.

Binding Properties The most salient binding properties for a hybrid KEM to be used in Internet protocols are LEAK-BIND-K-PK and LEAK-BIND-K-CT. The LEAK attack model is most appropriate for Internet protocols. There have been attacks in the LEAK model , so a hybrid KEM needs to be resilient at least to LEAK attacks (i.e., HON is too weak). Internet applications generally assume that private keys are honestly generated, so MAL is too strong an attack model to address. The LEAK-BIND-K-PK and LEAK-BIND-K-CT properties are naturally aligned with the needs of protocol design. Protocols based on traditional algorithms frequently need to incorporate transcript hashing in order to protect against key confusion attacks or KEM re-encapsulation attacks . The LEAK-BIND-K-PK and LEAK-BIND-K-CT properties prevent these attacks at the level of the hybrid KEM. Protocol designers may still need or want to include the ciphertext or encapsulation key into their protocol or key schedule for other reasons, but that can be independent of the specific properties of the KEM and its resulting shared secret. Implementors should not interpret the paragraph above as absolving them of their responsibility to carefully think through whether MAL-BIND attacks apply in their settings.

Security Non-goals for Hybrid KEMs Security properties not targeted by these designs are listed in .

Security Analysis In this section, we describe how the hybrid KEM framework in this document provides the security properties described above.

IND-CCA analyses The UG construction has two complementary IND-CCA analyses: one for when the SDH problem holds but the PQ KEM is broken, and one for the reverse. Both are technically novel but are substantially similar to the existing peer-reviewed analyses of the CG and UK constructions. by the editorial team describes the analysis of UG in detail. The first IND-CCA analysis, based on SDH, is similar to the corresponding analysis of CG given in : it gives a straightforward reduction to the SDH hardness in the underlying group. Notably, since the PQ KEM key and ciphertext are hashed, the C2PRI security of the PQ KEM does not appear in the bound. The second IND-CCA analysis is a straightforward reduction to the IND-CCA security of the PQ KEM, and the PRF security of the RO when keyed with the PQ KEM's shared secret. This document's UK construction does not have a dedicated IND-CCA analysis; the paper on which the construction is based gives a slightly different version, namely they do not include the public encapsulation keys in the KDF. However, we argue that the proof goes through with trivial modifications if the public encapsulation keys are included in the KDF. The relevant step is claim 3 of Theorem 1, which reduces to the split-key pseudorandomness of the KDF. ( call the KDF a "core" function, and denote it as W.) We observe that adding the public encapsulation keys to the inputs only changes the concrete contents of the reduction's queries to its oracle. Since the reduction chooses the public encapsulation keys itself, they can be added to the oracle inputs, and the remainder of the proof goes through unmodified. We reiterate that modulo some low-level technical details, our requirement that the KDF is indifferentiable from an RO implies that, in the ROM, the KDF used in meets the split-key pseudorandomness property used in 's analysis: this is shown in , Lemma 6, where a pseudorandom skPRF is constructed from any almost-uniform keymixing function in the random oracle model by H(g(k1,...,kn), x) , where H is modeled as a random oracle and g is ϵ-almost uniform. Example 3 from qualifies g(k_1,...,k_n) = k_1 || ... || k_n as ϵ-almost uniform with ϵ = 1/len(k_1 || ... || k_n). Like UG, the CG construction has two complementary IND-CCA analyses. Both were given in . We summarize them but elide some details. One analysis (Theorem 1) shows that if the KDF is modelled as a RO, IND-CCA holds if the PQ KEM is broken, as long as the SDH problem holds in the nominal group and the PQ KEM satisfies C2PRI. The other (Theorem 2) shows that if the PQ-KEM is IND-CCA and the KDF is a PRF keyed on the PQ-KEM's shared secret, IND-CCA holds. As long as the aforementioned security requirements of the component parts are met, these analyses imply that this document's CG construction satisfies IND-CCA security. The CK construction has two complementary IND-CCA analyses: one for when the IND-CCA security of the traditional PKE-based KEM holds but the PQ KEM is broken, except for the PQ KEM's C2PRI security, and one for when the IND-CCA security of the PQ KEM holds. Both are technically novel but are substantially similar to the existing peer-reviewed analyses of the CG and UK constructions. by the editorial team and collaborators describes the analysis of CK in detail. Therefore all four hybrid KEMs in this document are IND-CCA when instantiated with cryptographic components that meet the security requirements described above. Any changes to the algorithms, including key generation/derivation, are not guaranteed to produce secure results. The IND-CCA analyses of UG in , CG in , and CK in all model component key generation as sampling the two component key pairs independently, whereas the default key generation in this document derives both component key pairs from a single seed via the PRG (). This apparent mismatch is resolved by a standard hybrid argument: by the PRG security required in , the joint distribution of component key pairs derived from a single seed is computationally indistinguishable from the joint distribution of independently generated component key pairs. Thus, any IND-CCA adversary against the shared-seed scheme implies an IND-CCA adversary against the independent-keys scheme with at most an additive PRG-distinguishing term in the bound. The same observation underlies the binding sketches in Section .

Binding analyses There are four hybrid KEM frameworks, and two target binding properties, so we need eight total analyses. The CG and CK binding analyses additionally require the corresponding LEAK-BIND property of KEM_PQ. None of these exact results were known; thus the following are results by the editorial team. We include informal justifications here and defer rigorous proofs to a forthcoming paper. We note that these sketches implicitly ignore the fact that in our hybrid KEMs, both key pairs are derived from a common random seed; we instead implicitly think of them as two runs of DeriveKeyPair with independent random seeds. We justify this simplification by noting that in the LEAK model - in which the adversary is given the key pairs resulting from an honest run of KeyGen - the pseudorandomness of the seed expansion implies the adversary's input distributions in the two cases are computationally indistinguishable. The derivation of component scheme key pairs from the common random seed provides further protection against manipulation or corruption of keys such that it can contribute to stronger binding properties against a MAL adversary, as well as operational benefits in practice, but we do not prove that here. The paper that establishes the IND-CCA security of the UG construction () does not also include a proof of its binding properties. Instead, Section 4.3 observes that the binding arguments for UK transfer to UG essentially unmodified, since both constructions include the relevant ciphertexts and encapsulation keys in the KDF input; we make that argument concrete in the sketches below. The sketches rely on collision resistance of the KDF (), and for CG and CK, additionally on the corresponding LEAK-BIND property of the PQ KEM. Two points of notation apply throughout the sketches below. First, we describe the LEAK-BIND games in terms of two honestly-generated key pairs, following the formalization of (Figure 5). In that game the adversary may set the second key pair equal to the first, so the analyses also cover the case of a single key pair (two distinct ciphertexts that decapsulate to the same key under one decapsulation key); the KDF-collision arguments cover both cases. Second, we write reject for the abstract decapsulation-failure symbol used in . As noted in , a Decaps in this document may return reject (for an explicitly rejecting KEM) or, for an implicitly rejecting KEM, return a deterministic pseudorandom output in place of reject. The LEAK-BIND games are won only by a collision on non-reject keys -- that is, both decapsulations must succeed -- so the collision arguments below, which rely on distinct ciphertexts or public keys producing distinct KDF inputs, are unaffected by how rejection is signaled.

UG Binding

LEAK-BIND-K-CT of UG Claim: If KDF is collision-resistant, then UG is LEAK-BIND-K-CT. Justification: To win LEAK-BIND-K-CT, given knowledge of two honestly-generated UG secret keys, the adversary must construct two distinct UG ciphertexts that decapsulate to the same (non-reject) key. Since UG includes the ciphertexts in the key derivation, the condition that the ciphertexts are distinct directly implies that a LEAK-BIND-K-CT win gives a collision in the KDF. This argument also covers the case where both ciphertexts are decapsulated under a single decapsulation key: in the game of (Figure 5) the adversary may set the two key pairs equal, and distinct ciphertexts still produce distinct KDF inputs.

LEAK-BIND-K-PK of UG Claim: If KDF is collision-resistant, then UG is LEAK-BIND-K-PK. Justification: As described above, in the LEAK-BIND-K-PK game, to win the adversary must construct two ciphertexts that decapsulate to the same non-reject key, for distinct UG public keys. Again, since UG includes the public keys in the KDF, the distinctness condition implies a LEAK-BIND-K-PK win must collide the KDF.

UK Binding

LEAK-BIND-K-CT of UK Claim: If KDF is collision-resistant, then UK is LEAK-BIND-K-CT. Justification: To win LEAK-BIND-K-CT, given knowledge of two honestly-generated UK secret keys, the adversary must construct two distinct UK ciphertexts that decapsulate to the same (non-reject) key. Since UK includes the ciphertexts in the key derivation, the condition that the ciphertexts are distinct directly implies that a LEAK-BIND-K-CT win gives a collision in the KDF. This argument also covers the case where both ciphertexts are decapsulated under a single decapsulation key: in the game of (Figure 5) the adversary may set the two key pairs equal, and distinct ciphertexts still produce distinct KDF inputs.

LEAK-BIND-K-PK of UK Claim: If KDF is collision-resistant, then UK is LEAK-BIND-K-PK. Justification: As described above, in the LEAK-BIND-K-PK game, to win the adversary must construct two ciphertexts that decapsulate to the same non-reject key, for distinct UK public keys. Again, since UK includes the public keys in the KDF, the distinctness condition implies a LEAK-BIND-K-PK win must collide the KDF.

CG Binding The LEAK-BIND proofs for CG are a bit more subtle than for UK; the main reason for this is CG's omission of the PQ KEM key and ciphertext from the KDF. We will show that CG still has our target LEAK-BIND properties as long as the underlying PQ-KEM also has the corresponding LEAK-BIND property. We note that our preliminary results suggest that a different proof strategy, which instead directly uses properties of the nominal group, may work here; we present the PQ-KEM route for concreteness.

LEAK-BIND-K-CT of CG Claim: If KDF is collision-resistant and the PQ KEM is LEAK-BIND-K-CT, then CG is LEAK-BIND-K-CT. Justification: To win the adversary must construct two distinct CG ciphertexts that decapsulate to the same non-reject key. Call the CG ciphertexts output by the adversary (ct_PQ^0, ct_T^0) and (ct_PQ^1, ct_T^1). Distinctness implies (ct_PQ^0, ct_T^0) != (ct_PQ^1, ct_T^1). Since ct_T is included in the KDF, if ct_T^0 != ct_T^1, a win must collide the KDF. Thus we can restrict attention to the case where ct_PQ^0 != ct_PQ^1 but ct_T^0 = ct_T^1. In this case, there are two relevant sub-cases: either ss_PQ^0 (:= KEM_PQ.Decaps(dk_PQ^0, ct_PQ^0)) is not equal to ss_PQ^1 (:= KEM_PQ.Decaps(dk_PQ^1, ct_PQ^1)), or they are equal. If they are not equal, the KDF inputs are again distinct, so a LEAK-BIND-K-CT win must collide the KDF. If ss_PQ^0 = ss_PQ^1, we can show a reduction to the LEAK-BIND-K-CT security of the PQ KEM. The reduction is given two PQ KEM key pairs as input and must output two distinct PQ KEM ciphertexts that decapsulate to the same key. Per the LEAK-BIND-K-CT game of (Figure 5), these two ciphertexts may be decapsulated under either the same key pair or the two distinct key pairs, at the adversary's choice; the reduction covers both cases. The reduction does this by generating two nominal-group key pairs and running the CG LEAK-BIND-K-CT adversary on all keys. Then the reduction outputs the PQ KEM ciphertexts output by the adversary. The probability that the adversary wins and ss_PQ^0 = ss_PQ^1 and ct_PQ^0 != ct_PQ^1 and ct_T^0 = ct_T^1 is a lower bound on the probability of the reduction winning the LEAK-BIND-K-CT game against the PQ KEM. We conclude by noting these cases are exhaustive.

LEAK-BIND-K-PK of CG Claim: If KDF is collision-resistant and the PQ KEM is LEAK-BIND-K-PK, then CG is LEAK-BIND-K-PK. Justification: Similar to the above, we proceed by a case analysis on the win condition of the LEAK-BIND-K-PK game. The condition is (ek_PQ^0, ek_T^0) != (ek_PQ^1, ek_T^1) and ss_H^0 = ss_H^1. Again, as above we argue that the only nontrivial case is the one where ek_PQ^0 != ek_PQ^1 but ek_T^0 = ek_T^1: in the other case we can directly get a KDF collision from a winning output. In this case the result of KEM_PQ.Decaps for the two PQ KEM keys can either be the same or different. IF they are different, we again get a KDF collision from a win. If they are the same, in a similar way as above, we can build a reduction to the LEAK-BIND-K-PK of PQ KEM. Again, we conclude by noting that these cases are exhaustive.

CK Binding

LEAK-BIND-K-CT of CK Claim: If KDF is collision-resistant and the PQ KEM is LEAK-BIND-K-CT, then CK is LEAK-BIND-K-CT. Justification: To win the adversary must construct two distinct CK ciphertexts that decapsulate to the same non-reject key. Call the CK ciphertexts output by the adversary (ct_PQ^0, ct_T^0) and (ct_PQ^1, ct_T^1). Distinctness implies (ct_PQ^0, ct_T^0) != (ct_PQ^1, ct_T^1). Since ct_T is included in the KDF, if ct_T^0 != ct_T^1, a win must collide the KDF. Thus we can restrict attention to the case where ct_PQ^0 != ct_PQ^1 but ct_T^0 = ct_T^1. In this case, there are two relevant sub-cases: either ss_PQ^0 (:= KEM_PQ.Decaps(dk_PQ^0, ct_PQ^0)) is not equal to ss_PQ^1 (:= KEM_PQ.Decaps(dk_PQ^1, ct_PQ^1)), or they are equal. If they are not equal, the KDF inputs are again distinct, so a LEAK-BIND-K-CT win must collide the KDF. If ss_PQ^0 = ss_PQ^1, we can show a reduction to the LEAK-BIND-K-CT security of the PQ KEM. The reduction is given two PQ KEM key pairs as input and must output two distinct PQ KEM ciphertexts that decapsulate to the same key. Per the LEAK-BIND-K-CT game of (Figure 5), these two ciphertexts may be decapsulated under either the same key pair or the two distinct key pairs, at the adversary's choice; the reduction covers both cases. The reduction does this by generating two traditional KEM key pairs and running the CK LEAK-BIND-K-CT adversary on all keys. Then the reduction outputs the PQ KEM ciphertexts output by the adversary. The probability that the adversary wins and ss_PQ^0 = ss_PQ^1 and ct_PQ^0 != ct_PQ^1 and ct_T^0 = ct_T^1 is a lower bound on the probability of the reduction winning the LEAK-BIND-K-CT game against the PQ KEM. We conclude by noting these cases are exhaustive.

LEAK-BIND-K-PK of CK Claim: If KDF is collision-resistant and the PQ KEM is LEAK-BIND-K-PK, then CK is LEAK-BIND-K-PK. Justification: Similar to the above, we proceed by a case analysis on the win condition of the LEAK-BIND-K-PK game. The condition is (ek_PQ^0, ek_T^0) != (ek_PQ^1, ek_T^1) and ss_H^0 = ss_H^1. Again, as above we argue that the only nontrivial case is the one where ek_PQ^0 != ek_PQ^1 but ek_T^0 = ek_T^1: in the other case we can directly get a KDF collision from a winning output. In this case the result of KEM_PQ.Decaps for the two PQ KEM keys can either be the same or different. IF they are different, we again get a KDF collision from a win. If they are the same, in a similar way as above, we can build a reduction to the LEAK-BIND-K-PK of PQ KEM. Again, we conclude by noting that these cases are exhaustive.

Other Considerations

Domain Separation ASCII-encoded bytes provide oracle cloning in the security game via domain separation. The IND-CCA security of hybrid KEMs often relies on the KDF function KDF to behave as an independent random oracle, which the inclusion of the label achieves via domain separation . By design, the calls to KDF in these frameworks and usage anywhere else in higher level protocol use separate input domains unless intentionally duplicating the 'label' per concrete instance with fixed parameters. This justifies modeling them as independent functions even if instantiated by the same KDF. This domain separation is achieved by using suffix-free sets of label values. Recall that a set is suffix-free if no element is a suffix of another within the set. Length differentiation is sometimes used to achieve domain separation but as a technique it is brittle and prone to misuse in practice so we favor the use of an explicit post-fix label.

Fixed-length Variable-length secrets are generally dangerous. In particular, using key material of variable length and processing it using hash functions may result in a timing side channel. In broad terms, when the secret is longer, the hash function may need to process more blocks internally. In some unfortunate circumstances, this has led to timing attacks, e.g. the Lucky Thirteen and Raccoon attacks. Furthermore, identified a risk of using variable-length secrets when the hash function used in the key derivation function is no longer collision-resistant. If concatenation were to be used with values that are not fixed-length, a length prefix or other unambiguous encoding would need to be used to ensure that the composition of the two values is injective and requires a mechanism different from that specified in this document. Therefore, this specification MUST only be used with algorithms which have fixed-length shared secrets.

IANA Considerations This document requests that IANA create a registry "Hybrid KEM Labels", which lists labels that uniquely identify instantiations of the frameworks in this document. The registry should be administered under the First Come First Served policy . Template:

• Label: The name of the wire format
• Framework: The framework used in the hybrid KEM. This value MUST be one of the following values: "UG", "UK", "CG", or "CK".
• PQ component: The name of the post-quantum KEM used in the hybrid KEM.
• Traditional component: The name of the traditional KEM or nominal group used in the hybrid KEM.
• KDF: The name of the Key Derivation Function used in the hybrid KEM.
• PRG: The name of the Pseudorandom Generator used in the hybrid KEM.
• Nseed: An integer representing the size of a seed for this hybrid KEM.
• Nss: An integer representing the size of a shared secret for this hybrid KEM.
• Reference (optional): The document where this hybrid KEM is defined

To preserve the domain separation described in , the set of registered Label values MUST be suffix-free: no registered Label may be a suffix of another. A registration request whose Label is a suffix of an already-registered Label, or of which an already-registered Label is a suffix, MUST be rejected. The registry should initially be empty.

Out of Scope Security properties and design considerations that were considered and not included in these designs:

• Anonymity , deniability, obfuscation, other forms of key-robustness or binding ,
• More than two components: this document restricts the scope to two components: one post-quantum component and one traditional component
• Parameterized output length: not analyzed as part of any security proofs in the literature, and a complication deemed unnecessary

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) University of California San Diego CWI Amsterdam CWI Amsterdam Seoul National University CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security Oracle; Selkie Cryptography University of Michigan International Association for Cryptologic Research n.d. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447.

Deterministic Encapsulation When verifying the behavior of a KEM implementation (e.g., by generating or verifying test vectors), it is useful for the implementation to expose a "derandomized" version of the Encaps algorithm:

• EncapsDerand(ek, randomness) -> (shared_secret, ct): A deterministic encapsulation algorithm, which takes as input a public encapsulation key ek and randomness randomness, and outputs a shared secret shared_secret and ciphertext ct.

An implementation that exposes EncapsDerand must also define a required amount of randomness:

• Nrandom: The length in bytes of the randomness provided to EncapsDerand

The corresponding change for a nominal group is to replace randomly-generated inputs to RandomScalar with deterministic ones. In other words, for a nominal group, Nrandom = Nseed. When a hybrid KEM is instantiated with constituents that support derandomized encapsulation (either KEMs or groups), the hybrid KEM can also support EncapsDerand(), with Nrandom = PQ.Nrandom + T.Nrandom. The structure of the hybrid KEM's EncapsDerand algorithm is the same as its Encaps method, with the following differences:

• The EncapsDerand algorithm also takes a randomness parameter, which is a byte string of length Nrandom.
• Invocations of Encaps or RandomScalar (with a random input) in the constituent algorithms are replaced with calls to EncapsDerand or RandomScalar with a deterministic input.
• The randomness used by the PQ constituent is the first PQ.Nrandom bytes of the input randomness.
• The randomness used by the traditional constituent is the final T.Nrandom bytes of the input randomness.

Acknowledgments TODO acknowledge.