<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 3.0.2) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5990 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5990.xml">
<!ENTITY RFC7748 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY RFC3447 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3447.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8411 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8411.xml">
<!ENTITY RFC8784 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml">
<!ENTITY RFC8696 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8696.xml">
<!ENTITY I-D.ietf-lamps-cmp-updates SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lamps-cmp-updates.xml">
<!ENTITY I-D.driscoll-pqt-hybrid-terminology SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.driscoll-pqt-hybrid-terminology.xml">
<!ENTITY I-D.ietf-tls-hybrid-design SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-hybrid-design.xml">
<!ENTITY I-D.ietf-ipsecme-ikev2-multiple-ke SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-ikev2-multiple-ke.xml">
<!ENTITY I-D.ounsworth-pq-composite-kem SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ounsworth-pq-composite-kem.xml">
<!ENTITY I-D.cfrg-schwabe-kyber SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.cfrg-schwabe-kyber.xml">
]>


<rfc ipr="trust200902" docName="draft-ounsworth-cfrg-kem-combiners-00" category="info" submissionType="IRTF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="KEM Combiner">Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs)</title>

    <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
      <organization abbrev="Entrust">Entrust Limited</organization>
      <address>
        <postal>
          <street>2500 Solandt Road – Suite 100</street>
          <city>Ottawa, Ontario</city>
          <code>K2K 3G5</code>
          <country>Canada</country>
        </postal>
        <email>mike.ounsworth@entrust.com</email>
      </address>
    </author>

    <date year="2022" month="November" day="25"/>

    <area>Security</area>
    <workgroup>CFRG</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The migration to post-quantum cryptography often calls for performing multiple key encapsulations in parallel and then combining their outputs to derive a single shared secret.</t>

<t>This document defines the KEM combiner <spanx style="verb">KDF( H(ss1) || H(ss2) )</spanx> which is considered to be a dual PRF in practice, even though not provably secure. This mechanism simplifies to <spanx style="verb">KDF( ss1 || ss2 )</spanx> when used with a KEM which internally uses a KDF to produce its shared secret. RSA-KEM, ECDH, Edwards curve DH, and CRYSTALS-Kyber are shown to meet this criteria and therefore be safe to use with the simplified KEM combiner.</t>

<!-- End of Abstract -->



    </abstract>

    <note title="About This Document" removeInRFC="true">
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ounsworth-cfrg-kem-combiners/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (<eref target="mailto:spasm@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/spasm/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/spasm/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/EntrustCorporation/draft-ounsworth-cfrg-kem-combiners"/>.</t>
    </note>


  </front>

  <middle>


<section anchor="sec-terminology"><name>Terminology</name>
<t>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 <xref target="RFC2119"/>  <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

<t>This document is consistent with all terminology defined in <xref target="I-D.driscoll-pqt-hybrid-terminology"/>.</t>

<section anchor="sec-kem-defn"><name>Key Encapsulation Mechanisms</name>

<t>For the purposes of this document, we consider a Key Encapsulation Mechanism (KEM) to be any asymmetric cryptographic scheme comprised of algorithms satisfying the following interfaces <xref target="PQCAPI"></xref>.</t>

<figure><artwork><![CDATA[
def kemKeyGen() -> (pk, sk)
def kemEncaps(pk) -> (ct, ss)
def kemDecaps(ct, sk) -> ss
]]></artwork></figure>

<t>where <spanx style="verb">pk</spanx> is public key, <spanx style="verb">sk</spanx> is secret key, <spanx style="verb">ct</spanx> is ciphertext, and <spanx style="verb">ss</spanx> is shared secret.</t>

<t>KEMs are typically used in cases where two parties, hereby refereed to as the "encapsulater" and the "decapsulater", wish to establish a shared secret via public key cryptography, where the decapsulater has an asymmetric key pair and has previously shared the public key with the encapsulater.</t>

</section>
</section>
<section anchor="sec-intro"><name>Introduction</name>

<t>The need for a KEM combiner function arises in three different contexts within IETF security protocols:</t>

<t><list style="numbers">
  <t>KEM / PSK hybrids where the output of a KEM is combined with a static pre-shared key.</t>
  <t>Post-quantum / tradtional hybrid KEMs.</t>
  <t>KEM-based authenticated key exchanges (AKEs).</t>
</list></t>

<t>This document normalizes a mechanisms for combining the output of two KEMs.</t>

<section anchor="kempsk-hybrids"><name>KEM/PSK hybrids</name>

<t>As a post-quantum stop-gap, several IETF protocols have added extensions to allow for mixing a pre-shared key (PSK) into an (EC)DH based key exchange. Examples include CMS <xref target="RFC8696"></xref> and IKEv2 <xref target="RFC8784"></xref>.</t>

</section>
<section anchor="pqtraditional-hybrid-kems"><name>PQ/Traditional hybrid KEMs</name>

<t>A post-quantum / traditional hybrid key encapsulation mechanism (hybrid KEM) as defined in <xref target="I-D.driscoll-pqt-hybrid-terminology"/> as</t>

<dl>
  <dt>PQ/T Hybrid Key Encapsulation Mechanism:</dt>
  <dd>
    <t>A Key Encapsulation Mechanism (KEM) made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t>
  </dd>
</dl>

<t>Building a PQ/T hybrid KEM requires a secure function which combines the output of both component KEMs to form a single output. Several IETF protocols are adding PQ/T hybrid KEM mechanisms as part of their overall post-quantum migration strategies, examples include TLS 1.3 <xref target="I-D.ietf-tls-hybrid-design"></xref>, IKEv2 <xref target="I-D.ietf-ipsecme-ikev2-multiple-ke"></xref>, X.509; PKIX; CMS <xref target="I-D.ounsworth-pq-composite-kem"></xref>, OpenPGP (CITE once Aron's draft is up), JOSE / COSE (CITE once Orie's drafts are up).</t>

</section>
<section anchor="kem-based-ake"><name>KEM-based AKE</name>

<t>The need for a KEM-based authenticated key establishment arises, for example, when two communicating parties each have long-term KEM keys (for example in X.509 certificates), and wish to involve both KEM keys in deriving a mutually-authenticated shared secret. In particular this will arise for any protocol that needs to provide post-quantum replacements for static-static (elliptic curve) Diffie-Hellman mechanisms. Examples include a KEM replacement for CMP's DHBasedMac <xref target="I-D.ietf-lamps-cmp-updates"/>, .. TODO: cite others.</t>

</section>
</section>
<section anchor="sec-kemcombiner"><name>KEM Combiner</name>

<t>A KEM combiner is a function that takes in two shared secrets and returns a combined shared secret, where all values are byte arrays.</t>

<figure><artwork><![CDATA[
ss = kemCombiner(ss1, ss2)
]]></artwork></figure>

<t>This document assumes that shared secrets are the output of a KEM, but without loss of generality they may also be any other source of cryptographic key material, such as pre-shared keys (PSKs), with PQ/PSK being a quantum-safe migration strategy being made available by some protocols, see for example IKEv2 in <xref target="RFC8784"></xref>.</t>

<t>In general it is desirable to use a dual PRF, a dual-input PRF which is keyed off either input, as a KEM combiner (see <xref target="sec-dualprf"/> for a discussion of dual PRFs). We take the following construction as a dual PRF in practice, and therefore suitable for use in all IETF protocols that need to combine the output of two KEMs:</t>

<figure title="general KEM combiner construction"><artwork><![CDATA[
ss = kemCombiner(ss1, ss2) = KDF( H(ss1) || H(ss2) )
]]></artwork></figure>

<t>where <spanx style="verb">KDF</spanx> represents a suitable choice of cryptographic key derivation function, <spanx style="verb">H</spanx> represents a cryptographic hash function, <spanx style="verb">ss1</spanx> and <spanx style="verb">ss2</spanx> represent the outputs of the first and second KEMs, and <spanx style="verb">||</spanx> represents concatenation. <spanx style="verb">KDF</spanx> and <spanx style="verb">H</spanx> are assumed to behave as random oracles.</t>

<t>See <xref target="sec-kemprimitives"/> for security analysis on the safety of using this combiner with RSA-KEM <xref target="RFC5990"></xref>, elliptic curve Diffie-Hellman <xref target="SEC1"></xref>, Edwards curve Diffie-Hellman <xref target="RFC7748"></xref>, and CRYSTALS-Kyber <xref target="I-D.cfrg-schwabe-kyber"></xref>. All of these cryptographic algorithms are found to have a KDF or cryptographic hash as the last step before output of the shared secret, and therefore the KEM combiner construction may be simplified to the following when used with combinations of the analyzed cryptographic algorithms.</t>

<figure title="simplified KEM combiner construction when both KEMs are known to provide strong output" anchor="tab-simplifiedCombiner"><artwork><![CDATA[
ss = kemCombiner(ss1, ss2) = KDF( ss1 || ss2 )
]]></artwork></figure>

<t>This simplified combiner proposed as a KEM combiner, for example in <xref target="I-D.ietf-tls-hybrid-design"/>.</t>

<t>In the case that more than two shared secrets need to be combined, the above construction can be extended in the obvious way:</t>

<figure title="KEM combiner construction for combining more than two shared secrets"><artwork><![CDATA[
ss = kemCombiner(ss1, ss2, ss3, ... ) 
      = KDF( H(ss1) || H(ss2) || H(ss3) ... )
]]></artwork></figure>

<!-- End of Introduction section -->

</section>
<section anchor="sec-iana"><name>IANA Considerations</name>

<t>None.</t>

<!-- End of IANA Considerations section -->

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>This work assumes that the KEM combiner defined in <xref target="sec-kemcombiner"/> is a dual PRF in practice, despite the lack of security proof. As the academic literature progresses towards provably secure dual PRFs, this document may need to be obsoleted in favour of a more robust primitive.</t>

<t>It is important to note that the analysis herein pertains to the specific cryptographic algorithms analyzed and do not necessarily generalize to other constructions, even if they are based on the same underlying primitive. Specifically it depends on whether the shared secret produced by the KEM is the output of a fixed and secure key derivation function which makes the length and value of the shared secret beyond the direct control of the initiator of the KEM.</t>

<!-- End of Security Considerations section -->

<!-- Start of Appendices -->

</section>


  </middle>

  <back>


    <references title='Normative References'>

&RFC2119;
&RFC5990;
&RFC7748;
<reference anchor="SEC1" target="&lt;https://www.secg.org/sec1-v2.pdf&gt;">
  <front>
    <title>Standards for Efficient Cryptography Group, SEC1: Elliptic Curve Cryptography</title>
    <author >
      <organization></organization>
    </author>
    <date year="2009" month="May"/>
  </front>
</reference>


    </references>

    <references title='Informative References'>

&RFC3447;
&RFC8174;
&RFC8411;
&RFC8784;
&RFC8696;
&I-D.ietf-lamps-cmp-updates;
&I-D.driscoll-pqt-hybrid-terminology;
&I-D.ietf-tls-hybrid-design;
&I-D.ietf-ipsecme-ikev2-multiple-ke;
&I-D.ounsworth-pq-composite-kem;
&I-D.cfrg-schwabe-kyber;
<reference anchor="Aviram2022" target="https://eprint.iacr.org/2022/065">
  <front>
    <title>Practical (Post-Quantum) Key Combiners from One-Wayness and Applications to TLS.</title>
    <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
      <organization></organization>
    </author>
    <author initials="B." surname="Dowling" fullname="Benjamin Dowling">
      <organization></organization>
    </author>
    <author initials="I." surname="Komargodski" fullname="Ilan Komargodski">
      <organization></organization>
    </author>
    <author initials="K. G." surname="Paterson" fullname="Kenneth G. Paterson">
      <organization></organization>
    </author>
    <author initials="E." surname="Ronen" fullname="Eyal Ronen">
      <organization></organization>
    </author>
    <author initials="E." surname="Yogev" fullname="Eylon Yogev">
      <organization></organization>
    </author>
    <date year="2022"/>
  </front>
</reference>
<reference anchor="PQCAPI" target="https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf">
  <front>
    <title>PQC - API notes</title>
    <author initials="N. P.-Q. C." surname="Project" fullname="NIST Post-Quantum Cryptography Project">
      <organization></organization>
    </author>
    <date year="2022" month="November"/>
  </front>
</reference>
<reference anchor="Bellare2015" target="https://eprint.iacr.org/2015/1198">
  <front>
    <title>Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.</title>
    <author initials="M." surname="Bellare" fullname="Mihir Bellare">
      <organization></organization>
    </author>
    <author initials="A." surname="Lysyanskaya" fullname="Anna Lysyanskaya">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>


    </references>


<section anchor="sec-secanalysis"><name>Security Analysis</name>

<section anchor="sec-dualprf"><name>Dual PRF</name>

<t>Dual PRFs are a active area of research. A dual PRF is a function which is a PRF when keyed by either of its two inputs – guaranteeing pseudo-randomness if one of the keys is compromised or even maliciously chosen by an adversary <xref target="Aviram2022"></xref>. As of publication of this document, no dual PRFs have been standardized for use. In practice we often use HMACs or HKDFs to serve the role of a dual PRF even though they have never been proved to be dual PRFs <xref target="Bellare2015"></xref>, <xref target="Aviram2022"></xref>.</t>

<t>In essence, this document assumes that <spanx style="verb">KDF( H(input1) || H(input2))</spanx> is a dual PRF in practice, for suitable choices of key derivation function <spanx style="verb">KDF</spanx> and hash function <spanx style="verb">H</spanx>, despite not having formal security proofs. It has been proposed as a KEM combiner, for example in <xref target="I-D.ietf-tls-hybrid-design"/>. As the academic literature evolves, it may become appropriate to obsolete this document with a KEM combiner based on a provably secure dual PRF.</t>

</section>
<section anchor="sec-kemprimitives"><name>KEM primitives</name>

<t>In modern cryptographic design, KEM algorithms seek to have indistinguishability under adaptive chosen ciphertext attack (IND-CCA2). FFor hybrid KEMs we desire the additional property that even if one input is controlled by an attacker, then combiner leaks no information about the other input.</t>

<t>There are two ways to achieve such a hybrid KEM combiner; either by designing a combiner that is robust to one of the inputs being maliciously-chosen, called a dual PRF. See <xref target="sec-dualprf"/> for a discussion about the current state of dual PRF research. Or alternatively by only allowing the hybridization of KEMs where a malicious kemEncaps() algorithm cannot control the shared secret derived by the victim's kemDecaps() algorithm and then combining the shared secrets in a trivial way.</t>

<t>The following sections analyze commonly-used KEM algorithms to show that they have the following two properties, and are therefore suitable for use with the simplified KEM combiner presented in <xref target="sec-kemcombiner"/>, <xref target="tab-simplifiedCombiner"/>.</t>

<t><list style="numbers">
  <t>A malicious encapsulater cannot control the length of the KEM output (shared secret) that will be derived by the decapsulater.</t>
  <t>A malicious encapsulater cannot control the value of the KEM output (shared secret) that will be derived by the decapsulater. We define a KEM output to be "controlled by an attacker" if a maliciously-written kemEncaps() function can cause the victim's kemDecaps() algorithm to produce a shared secret either of a length chosen by the attacker, or to take on a given value with higher probability than can be obtained via rejection sampling on the shared secret output of kemEncaps().</t>
</list></t>

</section>
<section anchor="rsa-kem"><name>RSA-KEM</name>

<t>RSA encryption <xref target="RFC3447"></xref> can be promoted into a KEM as per <xref target="RFC5990"></xref> which defines a key transport based on RSA-KEM.</t>

<figure><artwork><![CDATA[
1. Generate a random integer z between 0 and n-1 (see note), and
  convert z to a byte string Z of length nLen, most significant byte
  first:

      z = RandomInteger (0, n-1)

      Z = IntegerToString (z, nLen)

2. Encrypt the random integer z using the recipient's public key
  (n,e), and convert the resulting integer c to a ciphertext C, a
  byte string of length nLen:

      c = z^e mod n

      C = IntegerToString (c, nLen)

3. Derive a key-encrypting key KEK of length kekLen bytes from the
  byte string Z using the underlying key derivation function:

      KEK = KDF (Z, kekLen)

4. Wrap the keying data K with the key-encrypting key KEK using the
  underlying key-wrapping scheme to obtain wrapped keying data WK:

      WK = Wrap (KEK, K)

5. Concatenate the ciphertext C and the wrapped keying data WK to
  obtain the encrypted keying data EK:

      EK = C || WK

6. Output the encrypted keying data EK.
]]></artwork></figure>

<t>where Steps 1 - 3 define "RSA-KEM", which is considered here. Steps 4 - 6 define "Key Transport based on RSA-KEM" and is out of scope for this analysis as we assume that any RSA-KEM construction intended for use in a hybrid KEM would use the <spanx style="verb">KEK</spanx> output from Step 3 as the final shared secret.</t>

<t>Here the transported symmetric key, <spanx style="verb">KEK</spanx>, is the KEM output (shared secret) <spanx style="verb">ss</spanx> as defined in <xref target="sec-kem-defn"/>. The encapsulater must choose a key derivation function <spanx style="verb">KDF</spanx> and declare it in the RSA-KEM parameters. The decapsulater may refuse to perform the the decapsulation if it does not like the encapsulater's choice of <spanx style="verb">KDF</spanx>, therefore it can be modeled as a random oracle producing an output of fixed length. The attacker is free to choose <spanx style="verb">z</spanx>, but assuming a strong choice of <spanx style="verb">KDF</spanx>, they cannot control either the length or the value <spanx style="verb">KEK</spanx> beyond what can be obtained by rejection sampling, thus satisfying properties 1 and 2 and defined in {.sec-kemprimitives}}.</t>

<t>Therefore RSA-KEM is considered to be suitable for use with the simplified KEM combiner defined in <xref target="sec-kemcombiner"/>, <xref target="tab-simplifiedCombiner"/>.</t>

<t>Security note: This analysis applies to the specific RSA-KEM construction defined above. This result is not intended to generalize to all RSA-based key transport mechanisms, as they may not have the same cryptographic properties.</t>

</section>
<section anchor="elliptic-curve-diffie-hellman-ecdh"><name>Elliptic Curve Diffie-Hellman (ECDH)</name>

<t>The elliptic curve Diffie-Hellman key exchange <xref target="SEC1"></xref> can be promoted into a KEM in a straightforward way by assuming an ephemeral-static (ES) mode where <spanx style="verb">def kemEncaps(pk) -&gt; (ct, ss)</spanx> includes generation of an ephemeral key pair, the public key being included as part of the ciphertext <spanx style="verb">ct</spanx> and the private key being discarded upon completion of the encapsulation.</t>

<t>According to <xref target="SEC1"></xref> section 6.1.3:</t>

<figure><artwork><![CDATA[
1. Use one of the Diffie-Hellman primitives specified in Section 3.3 to
   derive a shared secret field element z ∈ Fq from U's secret key d_U 
   established during the key deployment procedure and V's public key 
   Q_V obtained during the key deployment procedure. If the Diffie-
   Hellman primitive outputs “invalid”, output “invalid” and stop. 
   Decide whether to use the “standard” elliptic curve Diffie-Hellman 
   primitive or the elliptic curve cofactor Diffie-Hellman primitive
   according to the convention established during the setup procedure.

2. Convert z ∈ Fq to an octet string Z using the conversion routine 
   specified in Section 2.3.5.

3. Use the key derivation function KDF established during the setup 
   procedure to generate keying data K of length keydatalen octets 
   from Z and [SharedInfo]. If the key derivation function outputs 
   “invalid”, output “invalid” and stop.

4. Output K.
]]></artwork></figure>

<t>Other key exchange methods defined in <xref target="SEC1"></xref> follow a similar construction.</t>

<t>The attacker is free to choose a private key <spanx style="verb">d_U</spanx> which yields a shared secret <spanx style="verb">Z</spanx>, but cannot force <spanx style="verb">Z</spanx> to take on a chosen value without solving the elliptic curve discrete logarithm problem or performing rejection sampling. Assuming a strong choice of <spanx style="verb">KDF</spanx>, the attacker cannot control either the length or the value of <spanx style="verb">KEK</spanx> beyond what can be obtained by rejection sampling, thus satisfying properties 1 and 2 and defined in <xref target="sec-kemprimitives"/>.</t>

<t>Therefore elliptic curve Diffie-Hellman is considered to be suitable for use with the simplified KEM combiner defined in <xref target="sec-kemcombiner"/>, <xref target="tab-simplifiedCombiner"/>.</t>

</section>
<section anchor="edwards-curve-diffie-hellman-x25519-x448"><name>Edwards Curve Diffie-Hellman (X25519 / X448)</name>

<t>The elliptic curve Diffie-Hellman key exchange <xref target="SEC1"></xref> can be promoted into a KEM in a straightforward way by assuming an ephemeral-static (ES) mode where <spanx style="verb">def kemEncaps(pk) -&gt; (ct, ss)</spanx> includes generation of an ephemeral key pair, the public key being included as part of the ciphertext <spanx style="verb">ct</spanx> and the private key being discarded upon completion of the encapsulation.</t>

<t>According to <xref target="RFC7748"></xref> section 6.1, the X25519 key exchange is defined as:</t>

<figure><artwork><![CDATA[
Alice generates 32 random bytes in a[0] to a[31] and transmits K_A =
X25519(a, 9) to Bob, where 9 is the u-coordinate of the base point
and is encoded as a byte with value 9, followed by 31 zero bytes.

Bob similarly generates 32 random bytes in b[0] to b[31], computes
K_B = X25519(b, 9), and transmits it to Alice.

Using their generated values and the received input, Alice computes
X25519(a, K_B) and Bob computes X25519(b, K_A).

Both now share K = X25519(a, X25519(b, 9)) = X25519(b, X25519(a, 9))
as a shared secret.  Both MAY check, without leaking extra
information about the value of K, whether K is the all-zero value and
abort if so (see below).  Alice and Bob can then use a key-derivation
function that includes K, K_A, and K_B to derive a symmetric key.
]]></artwork></figure>

<t>The X448 key exchange follows a similar construction.</t>

<t>The attacker is free to choose a private key <spanx style="verb">b</spanx> which yields a shared secret <spanx style="verb">K</spanx>, but cannot force <spanx style="verb">K</spanx> to take on a chosen value without solving the elliptic curve discrete logarithm problem or performing rejection sampling. Assuming a strong choice of <spanx style="verb">KDF</spanx>, the attacker cannot control either the length or the value of the derived symmetric key beyond what can be obtained by rejection sampling, thus satisfying properties 1 and 2 and defined in <xref target="sec-kemprimitives"/>.</t>

<t>Therefore Edwards curve Diffie-Hellman, X25519 and X448, are considered to be suitable for use with the simplified KEM combiner defined in <xref target="sec-kemcombiner"/>, <xref target="tab-simplifiedCombiner"/>.</t>

</section>
<section anchor="crystals-kyber"><name>CRYSTALS-Kyber</name>

<t>The CRYSTALS-Kyber kemEncaps() is defined as follows <xref target="I-D.cfrg-schwabe-kyber"></xref>:</t>

<figure><artwork><![CDATA[
1.Compute
  1. m = H(seed)
  2. (Kbar, cpaSeed) = G(m || H(pk))
  3. cpaCipherText = InnerEnc(m, publicKey, cpaSeed)
2.Return
  1. cipherText = cpaCipherText
  2. sharedSecret = KDF(KBar || H(cpaCipherText))
]]></artwork></figure>

<t>with definitions as per <xref target="I-D.cfrg-schwabe-kyber"></xref>.</t>

<t>Here the hash functions <spanx style="verb">G</spanx>, <spanx style="verb">H</spanx> and the key derivation function <spanx style="verb">KDF</spanx> are in theory chosen by the encapsulater, but in practice are fixed by the Kyber specification to be <spanx style="verb">H: SHA3-256</spanx>, <spanx style="verb">G: SHA3-512</spanx>, and <spanx style="verb">KDF: SHAKE-256</spanx>, which can be modeled as random oracles. The attacker is free to choose <spanx style="verb">m</spanx>, but not the decapsulater's public key <spanx style="verb">pk</spanx>, nor do they have control of <spanx style="verb">cpaCipherText</spanx> so long as <spanx style="verb">InnerEnc</spanx> remains IND-CPA secure. Therefore the attacker cannot control the value or length of <spanx style="verb">K</spanx> beyond what can be obtained by rejection sampling.</t>

<t>Therefore CRYSTALS-Kyber is considered to be suitable for use with the simplified KEM combiner defined in <xref target="sec-kemcombiner"/>, <xref target="tab-simplifiedCombiner"/>.</t>

</section>
</section>
<section anchor="intellectual-property-considerations"><name>Intellectual Property Considerations</name>

<t>None.</t>

</section>
<section anchor="contributors-and-acknowledgements"><name>Contributors and Acknowledgements</name>

<t>This document incorporates contributions and comments from a large group of experts. The Editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past years in pursuit of this document:</t>

<t>Douglas Stebila, Nimrod Aviram.</t>

<t>We are grateful to all, including any contributors who may have
been inadvertently omitted from this list.</t>

<t>This document borrows text from similar documents, including those referenced below. Thanks go to the authors of those
   documents.  "Copying always makes things easier and less error prone" - <xref target="RFC8411"></xref>.</t>

<section anchor="making-contributions"><name>Making contributions</name>

<t>To be removed before publication.</t>

<t>Additional contributions to this draft are welcome. Please see the working copy of this draft at, as well as open issues at:</t>

<t>https://github.com/EntrustCorporation/draft-ounsworth-cfrg-kem-combiners</t>

<!-- End of Contributors section -->

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+1c23IbR5J9x1fUUg8mIgDwJsoWZzyxFEiJXIoiLVDji0Jr
FhoFsId9c1c3KUjWxDzO+77u/py/ZE9mVvWNBGVPTOw6NtYRFoHu6qqsvJ7M
ysZwOOwVYRGZPTVO42mYmFzNyyQowjRR8zRXV8tpHs7UtVkqkwQ6s2Wk+WZs
giudhDa2av1IBp0cntp+T0+nubnZo2/VnL1H6o//Mhyqw4NXZxeHe+pwFhZW
FVdGzXI9L1SiY6OGwz/1ZmlAn/fk+jAtE3ub5sXVMJjni+G1iYeBm9IONzd7
fl5b6GT2o47SBI8WeSmThVnO32yxvbn5dHO7p3Oj99TEBGUeFsueLfA93lPH
ry+e924XYMHz1y9617e4khQmT0wxPCAyeoEu9lSYzNPejUlKs9dTapGnZban
1l6GcViYmdqfYUvgi47Uac0Z4uD5yfF3CuSpyenx6aFaj3Sc2f4a5iiWGchd
+zbNr8NkoV7QlHQ91mGE6zbTNv7X0BTzUZov6IbOgyvcuCqKzO5tbNA4uhTe
mJEftkEXNqZ5emvNBs+wQU8uwuKqnOLZw4QZMk7zLM1ZkhufZ/VarxekM9C4
p8piPvyql4V7Cv89UoFOVGkNKMv1Uq2Hc6WjSC2N7StSHm2v1JXJDW02Dfbo
Bj5aLJObud3jKWZmrsuI1CH195ex3KavPV0WV2lOPFdqyP8qyAJ3T0fqzBPt
rovunIbX5s4t8AZ6J7tXTmrultdYd9ddJe0wkPv27uammqQRRFio16meqV/+
9h9qUmICtQUdlNEBFGpPnRWFvtUDdZYUOg9Tfw+8LXLcHutEz3R1dQZaT7ZP
1M6LXXfNiOhjbGBUCeRfjdA1gjx6vV6S5jEEd8Nq+Pr5eHtr66n7uPv06ab7
+OWXj7+ij5PD8Zbwzpn52oRsRecz0c7D+TwMQqygxvkyK9JFrrOrpejiQJ5W
h1EUZkUYqHGZ35jWwDWeeqYLmvkUKkCWJhfBgQXx749eXW9vb0fWBAtWU3zY
Gt5sj7LZ/E+9Xtc/zEtokV2Ci++ZyuIqtKQo0MYZK9Se8rOKZhNvNgI9TTeu
cx3P0ttkmM+D7SfbT9kT9Mh422zbefz4S/fxq60vH/uPj7e2/Mcvv6quPnn6
pHP1eHjANjdkcx4GcTYsM+KD9XdneWiDNIqG2U/FUNzoEF4lDpM0ShfL1iRF
ZP2QmbHhImndDTNwKzZDaMXN9jCGsYRZZGCiflRtu9lPZLVZaqGdZMN+BNu0
Da5u9RTXl1PDBrV/E4Jb25vb220VOc81IkAAX7Z+ntpi+E2pk6KM++oEYcD7
dOhPnsZQdTP8Vi8TYy17uf0si/AoeRY26YuXk1FbISr/ZbI8TIpRqIOcdYII
2dh8sivDm3YPy3e2/SqM83TmKO/ce2aSv2jwVx2ktxG8Vef2MUxYnaQxyEhn
9jrs3D4xCTz+lXoxUueQY27TpDPicAmOvEaMuXsDkUd9ny7MTcMeaDv4ev7N
eP/8uMPgb8Z4GJdVkkJl2vzx7AlsHowQR4rRIr3ZGE9ejzdiMwv1xnme/sUE
hd1oCmfYNMsNxNEyhlXbDfMeCgptmYeRsRs6C4e8JBneQ2w+nlyo5vRt9+Ao
aGz2VXpjYqiV3/UzEyE2me3Nrd2O+1nGsSlyeBPSloMSLD1//dwpk/dNat/a
Ms5YifbUvnphoHB45M86CmeCP1KEmkQdne6PG4N/vaZt7W7Ab371kKqdhldh
7jfSubefJFq9XNqlTuy1XmrVkvvWbo//G8Kl6SkCCcyp17sA3InDhURdMo2M
+PuT42/Q5G86L0yC4BpF4qUzk5P/IpTgzf8uJLMIiyrTOZ4yEXMXAAuzsL3S
o/iKDaVlkZUSbmdgKhy6Vha3MaW9wk5nCt4mN8VIEcnkd50uOQcsuI3QnccH
6vLk4Pm6Olq3dquvfv6ZP233Vf9S3V6FwZXCJAHoC7EepsfCU1p05mTPZIvH
MQNlALGwQloursg4cCe90dNoSVSVuRkppqlCnyAd6h3OQ8M7EkpAB5EBIoQG
wyBlpm4RK7Aw0e4IY5wHhi1pgKV7B89ZNHAyZWAUwdQOV15P9oeYYaAOxwdH
+Hd2y8E04NhIV4jz49ffTy72X06GJ+RrAY+IuYhKNHcMWCERLQAMhQi0FxZQ
T4qR4I7Vc0NjCVsx1cTzaquzFvtH0DSJnpgFZrHvNE4iH+lgHM5mkeEwe1FH
IPXxEfbUjEmfWEdJsRBNsKe10zeTi7WB/FUIzfT59eE3b45fHx7Q58nR/suX
1Qc/YnJ09ublQf2pfnJ8dnp6+OpAHsZV1bl0uv/9mjBw7ez84vjs1f7LNVKP
oqWHxE1RIpZfBrGAJZoQggVLp/iCZ56Nz9XWY/Xxo8NInz4p+ULhHl9ILWSt
NIH85SvYvFQ6y4zOaQ4Cs7CwsNCRHdAKIkSS1KhrHV7JbUHfRNXweIO9FYLB
zB8//gqM8OkTybb36BEH3sNW/tXIMkSOhNixQPKp13vOkMmorATKJ72GVrRY
OFC3pjJJ0vrV06t16FrfG20C7tjKgzd8Fr4BXpiYpo3hbcncyEVHixRKfgUq
LSa286VzRHBrUZTe0jcW4lwHoPOtBMt32PZf//rXHrYDbYxBHQLAel8N/6TW
s+uBstd9f0+oxlW5G2Br1lZ3Dwzf5asywlqeuXdLMlSX2fUlCS4rpwAtpPkD
dWnlmti7uxYUfC0IMzxXmPeFaM6ltTK25SJ6PcqERU2XGeEo8S8s+ECTQGT5
4jYlh13AeQ1YqaZLBR+AD+ImtfjatdrNm3zNOwu1NjONyxBpiGwLTxlkw9iO
JVfXIkzdwNXUW22FnIEniXLyxryUw1GgbUidHs00IgkRQrdhgDdhWlpy0rKe
KF+1UOXBmhth1YZHQq7NzpbVTlQ5pEufJGImxAuKgbodc6oqhSZls+IlwDg1
C+fEQdggFJxEZXl93D8+vHguYQTJGrl45KRpBMDe2xrx5BvqfHLiSh62wRAJ
mazPPI5NnemoYgp4ThkSWDF0PMDGRzTxeTPKbyi45pkrFFzVZZORI2E41aQn
BEiwA8LRxhVf3pM9LrDR9f2TQ9u/4344LYzCDxzF4nYJogUBGrsh/ZPV2ccc
nm409t/r7dNULZBiizQbLjQyQ4s4DaQhPK1YCXUgPDGbgWpw3sDBuDRAk7Uz
MXH4nijRHV4h1Zic9MkZpKRv64fj/sGREnY0GTBSh4JoSeRBVM6QkJ5O1FuX
pr1jrTw+ObzZlmvI18id0AbPv9m4APfDu+zHXtsbFTl1Rj5QBFPr9Wx9CUW/
1dXjqV6PaVS+nrbaK0NnCRd/3m/HGgwqMy9t4j9BDE4SE9Ib0ueGlxal14WK
jLZQksSQtnfUoBrPzL47uMm7aiwJ4VkZRjORPm+0Zhr83k9lmLP2CtKrLVyw
mrM429HhaVpctbfD+kZwuQa2MnykJvdrLXlqKC0R1iWrYUnk6eCsJZgykubJ
ojZvaoRPKKwwC3bupquzSIvV1mhHvV1dA3g38Hr8+UoAxn432t18+gcuN/5B
TOLh0gAeOctMcv7iXK2Pjy8OIT4A3v08Tb6wriwLYZZZf6D+7WxyCJMY05/G
2LM8NH6sMBGjna3Vvgzu6j5PvtrT+fDlsB559wE/55g4EERP6owNxWXC5QbI
zoVSZTTUhT0R0vIFWxnLErPDfTZmIutktqkAUR3ImqiwfYntPpyGyU0aYS5W
tGoaPMnZkyhzXBYlRflhezudzOE4ERIDGKurad2G0B/eo3AmqeMSBsCyiGnW
ZSQ3QGttZctNFgE4cabPE0gYGrpotG585Y6zk746QGwMzfAI12PdrOHf41W1
M8tqBV5gfHoOkR8cPSPpnerAebf7S2GfPg3UCBnb2cHZHlVIYYiU5VhBta0T
ghrE+gj/iZxyK+Szb6m8ArOn0Ncu9kMbWuyWahQ+lHlCz1UBuzXKwx4y4xsd
lUb0eLosXE3bOihqrfqaEKWnl3JdgprbfcGT7WCsqSLBrgo0dsm6H1QM1LSU
tAE3oLiWUfuCCh8I68ArnJrEGgA8shUYZ34qm5Y57BHj24j8mp/gFDMCsSXM
QuBaI+5aDryk9Ixk4P8IA0yNKLZTtCHno3dc29KN4yCjb+g4YhoR90ARMoHK
wRJcME0Tdo4NcmvGaNiH2y/ybsUVXxvmPKVLheuiwcB9BlYkLlIZoao1YFec
fcyVCZk/PIbztw6IXCe6Pn4kzaPJsnyOOCwuaoZwXVrrSk1+WQAv9a1htetk
MZRNFbmDsbzS/fWNdqpvy7DgDdKitEOXdHYCVOUKiBGO+hVYbu9z+orrK8o1
/ODHPSnVfb3mZdHiWHObawo26jMpzHlJ3gIhnL2RrvcWXKXhKvVkJypK5S0b
6dZRZ6r2c3ys1BiNfVz6dGy78WSDQy4FBp/DHEiFBkPoaSLwzyVzP//cWha3
yY0nTN3I7ZAHgjyGDGzlrqAlyNeqHCPSGEBLB/Cm5OkmlY5BHkiN45COIazT
tCof0UBLSwv1Zd8mJaCCSoHQC4HuddqRi7G6UhQbEZ39IKS3PX7X4b+lA513
d4pWnUHu+OjdvaWst/cfJ7wbqX3orXAZetyWWANgEuPmQCXMNmEaF90oTbkr
ZZcBRwQvbWEyMJrtpqH3V6br0tsmdqda2bJUcqjTVmkNZLUtu1M/lHlcxdUR
wLL7gBGrtv3ZKOKtslm69Pb4CGY0rCmsQqaz0xVlwfY+eRMewogUrhNXkPTQ
AqOBlxxv2bg5qjXmr+bGI1RZmt31qS2oVqc/90NcLnAdi75TYUQcXSxi0/dG
de8Fp6YK6QORwRR4vL1pOp3GOM5EZ5KMsUuYcrlC3erl57wl/bNDIGak+sqd
Aazyn+7TTl+Gd7zpatG0M/SHNi8Ot1XsbVVPMIz/cuFXiiv7r/aBsaTQ53TW
1Vigs5jtFdKmUWfKe55pz/yo6qHojOs5lUHGcd0GQXessJUgd6HfJ8F690dQ
qE5GWFIcQ3BNNDerOukcvkj8hg6ATGJYYkSFdl1QWokRC7h4ywcG4gY7Zwx1
tB90Ks/kLRoKmE5tGnHxGQTO9Q1gmOA5FmKeTqnXoPL4pOoMa2BPyMg0BaiU
DwBrFlVBgNwX7Rp5iQ6lhMKeLjMB5SkP+FfvisgLznh+kBxgw0gzsEWPKD8w
qBL82FRH645gwrkrhhMc5lStikuAdvDfJo+4mFvvT00cdVzwDOnACAnmjCMa
/A8vdcdd+6OWGcFGryVhN8sH7g/fu005Ia1ADw4GxpwYsIqYZEElOjzJCP/e
oAFpLlNXV52FObSdq4d56kMaJIxN6iLN/QXQOepa4wqzaJsPPzApXClhPyMe
hVT9prt0XDOFUreMbN9rhZgu/vd68omTbX+K6u57KNvr1cerjFcUmRBF3Nxo
WpuQDvULwV4attbKsipQrR3GhmoIvoa4HLzGTNzOdZsK0rbcIbMoNbBQYThD
yKwpZ+lQwBH3CkC/qF7kmCk5tZXDgzSW44NcNJHKmoGrLwNKWgpkS65Jz26Q
TOp8qd7WnQzv2PgxrdSfq8PizvlHktZWLjBkakwijWTwCeEHV6tA3JfE3bkf
OjiR01lC63T8bInQI4QENlJrCFHRlqA7RlS3Ym3zbJONixdOqCgly5MjqrxL
Td/bxmk6UFlrtz0OoOTPEnKOxeo81J/Ssox85OIv2/3+5UMel3FqG80zi1eZ
YA2VW1CdgHPtvskxYf+kHdybE3WcuAXfCz5f8Kz5JyGOh4KD4VoPfGBYOGgY
UCarM1oeaXQhXtP5/Q63G8fLVZirXKdeGWXooN3XzGpv2jjWa+QMLOw4BdOT
TgiQ7Q269VwkuNcV0g7haCyVysoQ3m8acl2BXTlsSWfsG5yF1SddShcFRdn1
41cHw/F4fxsp8PPndWso48lbI8m6qL6umyGJb5hnKSroIwtXijlxl1NTcrSR
+BSya16QBNtoYACNkdHXliy36uYivk6pXsLRos71RwxEuLDjjtmA9eQcIrgK
QYUrhjQrvX6ZP3i3Nl06pkoppCKDdwK6XXwnfagdmXOAvi5Sea6h8HXATR2k
xQ3xT35NEaLeJ5SHj7eoyGeaxYmGPz/D0xH3NpBQoXPYDB9za5/V0Eyy+/BD
5SRFlsK4mvrGOWu/UftHECIb9nHybkyV9pIqsN+E8ALxF7ZxMNvvHCXcbVjp
wn+qj6iCCq/YM4TKIfiila+5YFtBIa4S0+aHnMR1DIR89lV6W0Ew55TbKSAf
1Iomczmfjz1E2VcVcj7XtaFcnWElBB7g4v2JH2dNWxS0axE1T1bvk4xDQTV2
8eBqvcXgvvCBy9IUgtoSbB4Mg4Tt30ZCC339MyigSpykEc7rugklfK6t9Ctr
5IJ0yzpvoQ0FQ5ta06uwRWlkoEtrfo0aN5qHusfvNVzSXh41nmG/WTk+auBI
pczIsWMRkucUDrJmXYWLK8nDp96Rc9LoUt50SmkDlqYj/9z8xeFPSzGSFNpj
+RZ9NdxusMEd0z/yxaZeDx9I1hR9aM63rpn2nV+bAFwqek0OVwzOUipTF6oc
rvQdZZqhRAF4aCk1qqOmW9SVT6Dz3AlIfk/7Shu1jyww9wesXdwSVNhk+0yG
W1LfpQxLznR61HWdAG0VGM20caEfuQ/x5AfauZNL8pJ8dZxS2YkiACU1cLk0
HJNwEXGv5+oBH9TX6jXTcuxIWd8c0PJ9P+IHjHD3LtKJrLb+YcCr9NmODoWf
Ahy7+/L1P9xCfpVRt/YXzZ4VrLKeDNweqx3KeEtnhK7JhmYLZN+N8D7GY5ih
yYk2H6qNBtjGh383hD9U4i+O79tbUO1tZ6QOfJchSB16xcEoEvnJ4UljtWtz
/ZKtoTCuIRSb6ND2Q4MdjSx0BRStaKeFuHCj1n8YuIVA3mM4EQAon4PQTDNd
QGdr/72C6ooKLNCmA84EeJEjkXREMWIke1R8R85dqqW+PamI/JZoZHrWsQSw
HCjcHVEy6QrR4oGawqu6ge6fGmtjbre668ChnXQGHtY0MJ/GlBx8e9LrPaF3
LMSpPvDwqNlTNSlMZtWWGqod753XnBlTk9I9DaHcTueee4znnlTPUX/DxUqv
IK1QVDEXr2UDROj6fYGqlqIZn0ouJNGFjs588bxViyMz4VJh8zymiRJv0zKa
KR8LLiGmS+83XQezybBxV7fGLiiv6XSHHfm+osrh0d1mf9VAZh74QsgD0ZJb
0LoNJ61+wE/UM9vuvVIxIVcEn9Q6w/xMHoe4Swkon8uJInn2UcMxCKdTXV6m
1TxGKRQAErMr9V3MsvXWUGb9nEtGqbGcGkahO2Jr0g23Vx8mMXWDBgbD4y4E
UYYU+VyxdSLjgjND+qQR8aS8JH5INuKDMclgTo1ldPQmHLv8cCnHtaxTkh64
4vl95C27aMgBgSYuyxsQSbTKVaRuSV+7UZ37BLtBndYqW32WNWSFPZIYt50w
a1UZ3XMuNXLJEzPVy/m+Hu7fDnofrvp+BvJW9TCK6HvSCF4bOb13Yu4WSu81
c08Gnxm4lnKJlbRPElXlCDBfu2RKx7M0ad2aVuOWuqFi4FyAHNm7WoepC6jt
5L0WlGuf6bxy1TmhW6fW877kPQ8f+DU759zp30Mwjb0dHe4DXRYQKpXHKcti
AF3peqJMRoENPKk6TQ4nfbY6lz1ePtiee+mbTKzjbeONjmrqqs900G0nleTa
TTHr9GU1oyO37foAmbF/M40ZKLvGBjFFmaWcd2aRqeuFpt3sB8nsB0Gac5sY
OOa46Uu7T0Zbo529Cqe+saZZFuiIpVHlcYoqNjFxk+2MdiRyN17RaEF1PIAw
BB/HhacP6pe//109/0lC0Jsvms3LavbjGz65qvqqMMuszD2GEt+fRemSp4JW
BGZG5Sni259bOJOn+ebHP9d+6FfMM1LHLRbQHHfYUJ3S//K3/wyTG3rL55e/
/dfA++fWVTkDKNJsxPQgBQtF7cSnplVwxlO+nEuPPWwoNFWDHHHHnUeCdK4D
OgFYJU2aRDd1hPWR8HjCYl0hAmuKMmtwjDOCcZWoONlKX2waFKa4DwsL7OdS
UQ62EXwicu5Vr+3Rzmh3xOD8jWPWKghAiPlBsoVxXmkqb1l08XQT5S/pGr7J
bizPwar7Awv37YR1/TiZp+8q9VlFoNccmuM3aQ+DfwduPYI9Yx1qOU1gm6t0
1sJXzvKlPMRNpjG9iN0KMRJDHwIRuuWRLmGm/nWpJRm3vWPzlz841OHQBPwz
kAautksFrqRQ1woIHds0uvFy62g1eUF6g0ZF6UJLDYOqCnAtqv3m2V3EMZJX
7z4LgGo2/DYgxJP8z2Gh+3p0WljoYRfyO0BIDB1cb8/9yOG77d3dradqQ333
+PFX/w8h/pchhO+0aqIIodXJqcX8xjvw2vf57Udkbd7nWrWz7fMdqaKQON5u
vuPo8XZnS16PYMAa05ntyY/76uueLLauB+opv+n1LJ36xtinPgUth0HKlLtD
B7pGEFhlKaTfc5k4tpvOfOLFZRtWeDHnpwPnM8Vqd7bUB5OnQihYg1W9K636
FFZsaeq2NKUtDZjtJW71Tn58pr52vFuf0nYGnQ2HXB5mrmHJNz58hnm14Kxq
BHZSz01guAbt2kiF5dWaNfOwep+fop34+w1qwOw+75MKa4gc7N7VSU0x5mjS
3m/tpSmkfk/fiQ8jpXjm0/3v4YRNcD2ou4mN5l8YgULnunf/6VnlcU8GFZg6
8cJHzjNkWckoKqXiSRgMknabSpl1aiDZPqgQ/lR80Ikc65S+1DCsw3iv3c1d
mfQJM0tkRzJtvavcLJSMfPe1YYfWthdRNvvPitDTz8Xnk3vj88n/6fgsdRw5
o2m/Ivg7idkPtbp6o+JZSX8GfKr3e4ji7a5bUdVOJ27zrKoVGirFX9WrW6Wp
Y3FSwM5IWWO4myMy5VkfF5CCrJ9MNUJnkOkJXcTtF+uxtI0gGtMgJBC4O+Zw
eUHhks4CsA3QtR4PXMA9oXqmnwSpzWt+J0PWDJqPtqYSEsTCJmJg0nh58gyG
zES0xvfdixgsGuZF6E6B3dHTqr7lXqMg22pXseryxaU0o/tQ8JlCaW5cdTTN
l52jvWYVU7xEo8NGmqK5Aumb4FjCvohV/WIEdPHyaE9NjvZ3htu7T4i6F+7r
7tb2petjBzF88eTQDXIv0N2pjXZ61T9b9oydgyMX0T2NbVcK6MVqarLKqQWx
PlVv9NRdtqR3SWGE3tYisi69DlE7fsztj9x7cr7f+BGIZnv3KvfV8FR54wT8
8h/JKFpOpWOJvwfkL29Sw6+Bbu4H8Y033Q5d1/GL8WNiUwiBprn77Z6AesKh
HAt5pezOTxwA3cnvhhnXtkNPu14L7g53b6JRLq9VRD/DIr+URmw374kgp2b0
C3C0rJynGNZ0bhuVuj816lS0iAHx0/SiHBtjmEOJLXm9WavJr9m1kZnUvS6Y
kopIPTemsx/WNPodDgwT2mv0B6QQ+d5+AZxEO7EV8RPqTT/RJcWxs+NzQpb0
C1r8LqjkCPSqwtLoXH6OpcxJEe40IMIDH6TlIoK2TwozBTgZtH/aiJrCvhXH
QC9dmXkZueLzwMEkyaOWtRyYndgqFZzJ2nrcNwfATm2S9KMU4G4aU5/DzB+u
gqKIfmCoK2hgO/oFOcUpEI/1CKr6YaEmGQW5OvfLBQm38hIWJEHr5BoJWupr
YfJDO+61CTzDFU4/I6Dj2jjNOPLriBu2fBcvi8loGxr51QEWvQGN3AGRmDU1
lDfJHm9tvZO32U8F8ra0FNtk24RX4T5L9zJJo1OUMrS6ea2t4ryH0L8bS5K5
NRG1B47UOb0AbfgtNz6Ldb/oF2A3tejlMXkPDU9G9Bc2SoUDy/kGacU9P2v2
D/1kX6cxuWXqzW7k/wby7FHeAVIAAA==

-->

</rfc>

