<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-cope-heh-01" ipr="trust200902">
  <front>
   <title abbrev="HEH">Hash-Encrypt-Hash, a block cipher mode of operation</title>
   <author fullname="Alex Cope" initials="A.C." surname="Cope">
    <organization>Google</organization>
    <address>
      <postal>
        <street>747 6th St S</street>
        <city>Kirkland</city>
        <region>WA</region>
        <code>98033</code>
        <country>USA</country>
      </postal>
      <email>alexcope@google.com</email>
    </address>
   </author>
   <date year="2016" />
   <area>General</area>
   <workgroup>Crypto Forum Research Group</workgroup>
   <keyword>HEH</keyword>
        <abstract>
          <t> This memo describes a block cipher mode of operation known as Hash-Encrypt-Hash (HEH).</t>
        </abstract>
      </front>
      <middle>
        <section title="Introduction">
          <t>This memo describes the implementation of the Hash Encrypt Hash (HEH) block cipher mode of operation as both an encryption algorithm and an AEAD. The primary benefit of HEH is that it extends the strong pseudorandom permutation property of block ciphers to arbitrary-length messages. This means that if any bit of the plaintext is flipped, each bit in the ciphertext will flip with 50% probability. No block cipher mode of operation that is currently in widespread use has this property. Additionally, HEH is more resistant to misuse than commonly-used block cipher modes of operation. For example, if nonces are reused, CTR fails catastrophically, and CBC will leak common prefixes of the underlying block size. HEH has neither of those problems.</t>

     <section title="Requirements Language">
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref
       target="RFC2119">RFC 2119</xref>.</t>
     </section>
   </section>

    <section title="Notation">
        <t><list counter="notation" hangIndent="4" style="empty">
         <t>ecb_key - key for the underlying ecb block cipher calls, generated by generate_keys.</t>
         <t>block - 16 bytes.</t>
         <t>buffer[i] - block i of buffer. Defined for 0 &lt;= i &lt; N.</t>
         <t>buffer[N+] - bytes 16 * N until the end of buffer. The unpadded partial block.</t>
         <t>EMPTY - buffer of length 0.</t>
         <t>GF(2^128) -  The Galois field of 2^128 elements, as defined in section 4.1.</t>
         <t>msg - shorthand for message, a buffer that is an input to a function.</t>
         <t>N - FLOOR(msg_length / 16), number of full blocks of msg.</t>
         <t>out_msg - buffer that is a transformation of msg. out_msg_length = msg_length unless otherwise explicitly specified.</t>
         <t>prf_key - pseudo-random function key. The key passed as input to HEH.</t>
         <t>tau_key - 16 byte key used to compute the hash, generated by generate_keys.</t>
         <t>XOR - bitwise exclusive-or.</t>
         <t>XXXX_length - length of XXXX in bytes.</t>
         <t>* - Multiplication in GF(2^128) as defined in section 4.2.</t>
         <t>+ - Addition in GF(2^128) as defined in section 4.3.</t>
         <t>0^i - buffer of i zero bytes.</t>
         <t>|| - concatenation.</t>
       </list></t>
      </section>

        <section title="Overview">
      <section title="Key size">
          <t>The HEH key is a single key of the same length as the underlying block cipher key. HEH uses CMAC to derive subkeys from the HEH key.</t>
      </section>
      <section title="Block cipher">
          <t>HEH MUST use a block cipher with a block size of 128-bits.</t>
      </section>
      <section title="Nonce and AAD">
         <t>HEH SHOULD support a 16-byte nonce. Support for other nonce lengths between 0 and 2^32-1 (inclusive) bytes is OPTIONAL. Support for additional authenticated data (AAD) and support for varying AAD lengths between 0 and 2^32-1 (inclusive) bytes is OPTIONAL. Security implications are discussed in section 7.1</t>
      </section>
   </section>

<section title="GF(2^128) math">
   <section title="GF(2^128)">
      <t>GF(2^128) is the Galois field of 2^128 elements defined by the irreducible polynomial x^128 + x^7 + x^2 + x + 1.</t>
      <t>Elements in the field are converted to and from 128-bit strings by taking the least-significant bit of the first byte to be the coefficient of x^0, the most-significant bit of the first byte to the the coefficient of x^7, and so on, until the most-significant bit of the last byte is the coefficient of x^127 [AES-GCM-SIV].</t>

   <t><figure><artwork>
      Examples:
         10000111 || 0^15 = x^7 + x^2 + x + 1
         0^15 || 00000001 = x^120.
         0^15 || 10000000 = x^127.
   </artwork></figure></t>
   </section>
<section title="Multiplication in GF(2^128)">
<t><figure><artwork>
   Input
      Two 128-bit elements X, Y

   Output
      128-bit element X * Y
   </artwork></figure></t>

   <t>Multiplication is defined on 128-bit blocks by converting them to polynomials as described above, and then computing the resulting product modulo x^128 + x^7 + x^2 + x + 1.</t>
   </section>
<section title="Addition in GF(2^128)">
<t><figure><artwork>
      Input
         Two 128-bit elements X, Y

      Output
         128-bit element X + Y
   </artwork></figure></t>

      <t>For any two 128-bit elements X, Y in the Galois field, X + Y is defined as X XOR Y. </t>
      <t>The operations + and XOR are interchangeable within this document. For consistency we use + on 128-bit strings and XOR if the arguments are not 128-bits long.</t>
   </section>
</section>
<section title="Algorithm">
  <t>When appropriate, we will explain the output as both a mathematical formula and in pseudo-code. This information is redundant, and it exists to provide additional clarity. Implementations need not implement the exact algorithm specified by the pseudocode, so long as the output matches what the pseudocode would produce.</t>
  <section title="generate_keys">
   <t>ecb_key and tau_key are generated from prf_key by taking the CMAC as defined in [CMAC] of fixed one-block messages. The input to the CMAC used to generate ecb and tau key will never collide with the input used to generate any beta_key, because when generating a beta_key, the last 4 bytes of the input are always zero. </t>
    <t><figure><artwork>
   Input
      msg, prf_key

   Output
      tau_key = CMAC(key = prf_key, message = 0x00...01)
      ecb_key = CMAC(key = prf_key, message = 0x00...02) ||
                CMAC(key = prf_key, message = 0x00...03)
                truncated to perf_key_length bytes
    </artwork></figure></t>

  </section>

  <section title="generate_betas">
   <t>To generate the beta_keys needed by HEH_hash, we take the CMAC as defined in [CMAC] of the nonce, AAD, nonce_length, AAD_length and plaintext_length. We use CMAC because it is a pseudorandom function on variable length inputs.</t>
   <t><figure><artwork>
   Input
      prf_key, nonce, AAD, plaintext_length

   Output
      beta1_key = CMAC(key = prf_key, message = pad_16(nonce) ||
                       pad_16(AAD) || pad_16(nonce_length |
  |                     AAD_length || plaintext_length))
      beta2_key = x * beta1_key
      return beta1_key, beta2_key
    </artwork></figure></t>
      <t>Where pad_16(X) = X right-padded with 0s up to a multiple of 16 bytes. If X is already a multiple of 16 bytes (including if X is 0 bytes), this is a no-op.</t>

      <t>The following MUST be true in order to generate conformant ciphertext:
      <list counter="reqs" hangIndent="4" style="symbols">
        <t>nonce_length, AAD_length, and plaintext_length MUST be 4 bytes long.</t>
        <t>nonce_length, AAD_length, and plaintext_length MUST be stored in little-endian format.</t>
        <t>The input to CMAC MUST be right-padded with 0x00 bytes up to a multiple of 16 bytes.</t>
        <t>CMAC MUST use the same block cipher that is used in CTS_2ECB_encrypt.</t>
        <t>CMAC MUST be implemented as described in [CMAC]. In particular, if CMAC is being reimplemented for HEH, be advised that there is a multiply-by-x substep of CMAC that uses a different finite field representation than the one described in section 4.</t>
      </list></t>

  </section>
  <section title="poly_hash">
    <t>Poly_hash treats each block of msg as a coefficient to a polynomial in GF(2^128), and evaluates that polynomial at tau_key to create a hash. Poly_hash is called as a subroutine of HEH_hash so that any minor change to msg will result in every block being changed in HEH_hash with high probability.  Note that the coefficients of m_{N-1} and m_N are flipped if there is a partial block. This is done to simplify the implementation of HEH_hash_inv.</t>
    <t><figure><artwork>
   Input
      msg, tau_key
   Output
      if (no partial block)
        k^{N-1} * m_0 + ... + k * m_{N-2} + m_{N-1}
      else if (partial block)
        k^N * m_0 + ... + k^2 * m_{N-2} + k * m_N + m_{N-1}
      Where k = tau_key,
      m_i = msg[i], for i = 0 to N-1,
      m_N = msg[N+] right padded up to 16 bytes with a 0x00 bytes.
            Undefined when msg_length is a multiple of 16

   pseudo-code:
      p = 0^16
      For i = 0 to N - 2
         p *= tau_key
         p += msg[i]
      if msg_length % 16 != 0
        p *= tau_key
        p += m_N // as defined above
      p *= tau_key
      p += msg[N-1]
      return p
    </artwork></figure></t>
  </section>
  <section title="HEH_hash">
   <t>HEH_hash is the hash step in Hash-Encrypt-Hash. It is an invertible hash function used to ensure any change to msg will result in every full block being modified with high probability.</t>
    <t><figure><artwork>
   Input
      msg, beta_key, tau_key

   Output
      out_msg = (m_0 + R, ..., m_{N-2} + R, R, m_N) +
                  (xb, x^2b, ..., x^{N-1}b, b, 0)
         where m_i = msg[i] for i = 0 to N-1,
         m_N = msg[N+],
         R = out_msg of poly_hash,
         b = beta_key,
         x is the element x in GF(2^128).

   pseudo-code:
      R = poly_hash(msg, tau_key)
      e = beta_key * x
      For i = 0 to N-2
         out_msg[i] = msg[i] + R + e
         e = e * x
      out_msg[N-1] = R + beta_key
      out_msg[N+] = msg[N+]
      return out_msg
    </artwork></figure></t>
  </section>
  <section title="HEH_hash_inv">
    <t>Inverse of HEH_hash</t>
    <t><figure><artwork>
   Input
      msg, beta_key, tau_key
   Output
      out_msg

   pseudo-code
      R = msg[N-1] + beta_key
      e = beta_key * x
      For i = 0 to N-2
         out_msg[i] = msg[i] + R + e
         e = e * x
      out_msg[N+] = msg[N+]
      out_msg[N-1] = 0^16
      // now all blocks in out_msg are correct except for
      // out_msg[N-1], which is all zeroes
      R_without_constant_term = poly_hash(out_msg, tau_key)
      out_msg[N-1] = R + R_without_constant_term
      return out_msg
    </artwork></figure></t>
  </section>
  <section title="CTS_2ECB_encrypt">
    <t>The encryption step of Hash-Encrypt-Hash. CTS_2ECB_encrypt uses a modification of CTS-ECB. Because HEH_hash is the identity function on partial blocks, we encrypt the partial block by xoring it with a pad created by encrypting the last full block of plaintext XOR the last full block ciphertext</t>
    <t><figure><artwork>
   Input
      msg, ecb_key
   Output
      out_msg

   pseudo-code
   For i = 0 to N-1
      out_msg[i] = block_cipher_encrypt(ecb_key, msg[i])
   if msg_length % 16 != 0
      partial_block_pad =
          block_cipher_encrypt(ecb_key, out_msg[N-1] XOR msg[N-1])
      // XOR the partial block with the first k bytes of
      // partial_block_pad, where k is the number of bytes
      // in the partial block
      out_msg[N+] = msg[N+] XOR partial_block_pad
   return out_msg
    </artwork></figure></t>
  </section>
  <section title="CTS_2ECB_decrypt">
       <t>Inverse of CTS_2ECB_encrypt. CTS_2ECB_decrypt is identical to CTS_2ECB_encrypt except the initial block_cipher_encrypt calls are now block_cipher_decrypt calls</t>
    <t><figure><artwork>
   Input
      msg, ecb_key
   Output
      out_msg

   pseudo-code
   For i = 0 to N-1
      out_msg[i] = block_cipher_decrypt(ecb_key, msg[i])
   if msg_length % 16 != 0
      partial_block_pad =
          block_cipher_encrypt(ecb_key, out_msg[N-1] XOR msg[N-1])
      // XOR the partial block with the first k bytes of
      // partial_block_pad, where k is the number of bytes
      // in the partial block
      out_msg[N+] = msg[N+] XOR partial_block_pad
   return out_msg
    </artwork></figure></t>
  </section>
  <section title="HEH_encrypt">
   <t>Core encryption function of HEH.</t>
    <t><figure><artwork>
   Input
      prf_key, ecb_key, tau_key, nonce, AAD, msg
   Output
      out_msg

   pseudo-code
      beta1_key, beta2_key = generate_betas(prf_key, nonce, AAD,
                                            msg_length)
      out_msg = HEH_hash(msg, beta1_key, tau_key)
      out_msg = CTS_2ECB_encrypt(out_msg, ecb_key)
      out_msg = HEH_hash_inv(out_msg, beta2_key, tau_key)
      return out_msg
    </artwork></figure></t>
  </section>
  <section title="HEH_decrypt">
   <t>Core decryption function of HEH.</t>
    <t><figure><artwork>
   Input
      prf_key, ecb_key, tau_key, nonce, AAD, msg
   Output
      out_msg

   pseudo-code
      beta1_key, beta2_key = generate_betas(prf_key, nonce, AAD,
                                            msg_length)
      out_msg = HEH_hash(msg, beta2_key, tau_key)
      out_msg = CTS_2ECB_decrypt(out_msg, ecb_key)
      out_msg = HEH_hash_inv(out_msg, beta1_key, tau_key)
      return out_msg
    </artwork></figure></t>
  </section>
</section>
  <section anchor="AEAD" title="HEH as an AEAD">
   <t>Because HEH is a strong pseudorandom permutation, it can also provide authentication with minimal modification. Support for authentication is OPTIONAL. To provide authentication, append 16 zero bytes to the end of the plaintext, then encrypt. When decrypting, we can determine authenticity of the message by verifying that the final 16 bytes of the plaintext are the expected zero bytes.</t>

  <section title="HEH_AEAD_encrypt">
   <t>The authenticated encryption function of HEH. HEH_AEAD_encrypt returns ciphertext which is 16 bytes longer than plaintext msg.</t>
    <t><figure><artwork>
   Input
      prf_key, ecb_key, tau_key, nonce, AAD, msg
   Output
      padded_out_msg

   pseudo-code
      // append a full block of zeroes
      padded_msg = msg || 0^16
      return HEH_encrypt(prf_key, ecb_key, tau_key, nonce, AAD,
                         padded_msg)
    </artwork></figure></t>
  </section>

     <section title="HEH_AEAD_decrypt">
   <t>The authenticated decryption function of HEH. HEH_AEAD_decrypt returns either plaintext which is 16 bytes shorter than msg or indication of inauthenticity FAIL.</t>
    <t><figure><artwork>
   Input
      prf_key, ecb_key, tau_key, nonce, AAD, msg,
   Output
      unpadded_out_msg or FAIL

   pseudo-code
      out_msg = HEH_DECRYPT(prf_key, ecb_key, tau_key, nonce, AAD,
                            msg)

      // If final block is not all zeros, FAIL
      if out_msg[(out_msg_length - 16):out_msg_length] != 0^16
         return FAIL

      // Drop the zero-block that was added in HEH_AEAD_encrypt
      unpadded_out_msg = out_msg[0:(out_msg_length - 16)]
      return unpadded_out_msg
    </artwork></figure></t>
  </section>
  </section>


  <section anchor="Security" title="Security considerations">
      <t>The minimum length of the plaintext  for HEH is 16 bytes. The maximum length is 2^32 - 1 bytes. When using HEH as an AEAD, this minimum and maximum apply to padded_msg.</t>
      <section anchor="nonce_security" title="Security implementations of nonce use">
         <t> If no nonce is used (or, equivalently, if a 'nonce' is re-used for multiple messages) then HEH is a strong pseudorandom permutation. Of course, if the same plaintext, nonce, and key are used together more than once, the ciphertext will collide.</t>
         <t> If a unique nonce is used for each plaintext and key combination, then HEH is semantically secure. We make no claim that using randomly-generated nonces or using longer nonces generates additional security.</t>
      </section>
      <section anchor="AEAD_Security" title="Authentication">
         <t> As HEH is a strong pseudorandom permutation, [AUTH] shows that authentication can be provided by appending a known authentication code to the plaintext and then encrypting.</t>
      </section>
   </section>
  </middle>
   <!--  *****BACK MATTER ***** -->
   <back>
    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      <reference anchor="CMAC">
         <front>
           <title>NIST Special Publication 800-38B</title>
           <author>
             <organization>National Institute of Standards and Technology</organization>
           </author>
           <date year="2005"/>
         </front>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="HEH">
        <front>
          <title>Efficient Tweakable Enciphering Schemes from (Block-Wise) Universal Hash Functions</title>
          <author initials="P" surname="Sarkar" fullname="Palash Sarkar"/>
          <date year="2008" />
        </front>
      </reference>
<!--       <reference anchor="TET">
        <front>
          <title>Invertible Universal Hashing and the TET Encryption Mode</title>
          <author initials="S" surname="Halevi" fullname="Shai Halevi"/>
          <date year="2007" />
        </front>
      </reference> -->
      <reference  anchor="AES-GCM-SIV">
        <front>
          <title>AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption. draft-gueron-gcmsiv-03</title>
          <author initials="S" surname="Gueron"></author>
          <author initials="A" surname="Langley"></author>
          <author initials="Y" surname="Lindell"></author>
          <date year="2016" />
        </front>
      </reference>
      <reference  anchor="AUTH">
         <front>
            <title>Encode-then-encipher encryption: How to exploit nonces or redundancy in plaintexts for efficient cryptography</title>
            <author initials="M" surname="Bellare"></author>
            <author initials="P" surname="Rogaway"></author>
            <date year="2000" />
         </front>
      </reference>
      <reference anchor="NIST.500-20.1977">
         <front>
            <title>
               Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard
            </title>
            <author>
               <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="November" year="1977"/>
         </front>
         <seriesInfo name="NIST" value="500-20"/>
      </reference>
    </references>
    <section anchor="Test_vectors" title="Test Vectors">
      <t>AES-128 was used as the block cipher for all of the test vectors.</t>
<figure><artwork>
key =        00000000000000000000000000000000
nonce =      EMPTY
AAD =        EMPTY
plaintext =  00000000000000000000000000000000
ciphertext = a1726260d1450ae4aba906e79e584e07
</artwork></figure>
<figure><artwork>
key =        000102030405060708090A0B0C0D0E0F
nonce =      EMPTY
AAD =        EMPTY
plaintext =  00000000000000000000000000000000
             00000000000000000000000000000000
             00000000000000000000000000000000
             000000000000000000000000000000
ciphertext = f5eec4375cefa15fc3eff7a271779231
             ce03afa9eeacf9ad060a62602e6dc202
             3598944729eb848d13f9b7d362e6d5f6
             4e648e38553415f44ff37752954da7
</artwork></figure>
<figure><artwork>
key =        000102030405060708090A0B0C0D0E0F
nonce =      EMPTY
AAD =        EMPTY
plaintext =  00000000000000000000000000000000
             00000000000000000000000000000000
             00000000000000000000000000000001
             000000000000000000000000000000
ciphertext = 4efc731cacbbaa2713a051e663ddaeb0
             4c1b25a3ee7aa4c125c9547154c74923
             90b5f7fac503f527b8cdffe21bb96201
             b0dc409fed9e9123379e5a6f101bd2
</artwork></figure>
<figure><artwork>
key =        000102030405060708090A0B0C0D0E0F
nonce =      00000000000000000000000000000000
AAD =        EMPTY
plaintext =  000102030405060708090A0B0C0D0E0F
ciphertext = d8bd40bfcae5ee810f3d1f1fae890755
</artwork></figure>
<figure><artwork>
key =        a8da249b5efa13c2c194bf32ba38a377
nonce =      4d4761372b4786f0d647b5c2e8cf8527
AAD =        EMPTY
plaintext =  b8ee29e4a5d1e755d0fde722637636e2
             f80cf8fe6576e7cac142f5ca5aa8ac2a
ciphertext = 59f2784e1094f95c2223782a30481197
             b1fe70c4efdf04ef163904cfc0959a98
</artwork></figure>
<figure><artwork>
key =        000102030405060708090A0B0C0D0E0F
nonce =      00000000000000000000000000000000
AAD =        EMPTY
plaintext =  00000000000000000000000000000000
             00000000000000000000000000000000
             00000000000000000000000000000000
             000000000000000000000000000000
ciphertext = e040ebe952be6560e46868a37375b852
             ef386a872525f604e58ebe148b02141f
             a973b7ad15be9ca0d28a2cdcd4e30555
             0af5f851eee562a571a77c155d7a9e
</artwork></figure>
<figure><artwork>
key =        000102030405060708090A0B0C0D0E0F
nonce =      00000000000000000000000000000000
AAD =        EMPTY
plaintext =  00000000000000000000000000000000
             00000000000000000000000000000000
             00000000000000000000000000000001
             000000000000000000000000000000
ciphertext = 4b1a15a0af086d70f0a797b5314b8cc3
             4df27a9dddd4159957adc6b13569f56a
             2d70e49749b29f71de22b5708c6924d3
             ad80584890e4edba763d717c572587
</artwork></figure>
<figure><artwork>
key =        000102030405060708090A0B0C0D0E0F
nonce =      000102030405060708090A0B0C0D0E0F
AAD =        000102030405060708090A0B0C0D0E0F
plaintext =  00000000000000000000000000000000
             00000000000000000000000000000000
ciphertext = 16c3f198c970dd0db9b25beedbacb615
             b2ee9c51ece5d2426b9f5420be8b1b19
</artwork></figure>
<figure><artwork>
key =        000102030405060708090A0B0C0D0E0F
nonce =      000102030405060708090A0B0C0D0E0F
             000102030405
AAD =        0102030405060708090A0B0C0D0E0F00
             010203
plaintext =  00000000000000000000000000000000
             00000000000000000000000000000000
ciphertext = 2aa635491098bc45b711a5d950cc4988
             1d110f20056c9d220d125fabfd7ab941
</artwork></figure>
<figure><artwork>
key =        36DAF975AAE45061AF88079422E5E6A9
nonce =      4164A1FFAEEF4B23324C47279AFB02E8
AAD =        948F6D03EA0BDE71A0233AC87753F10E
plaintext =  6A2EDA8E07C10918507F0B5E4F32053C
             335D179A8F476ED1D08A458C00726F63
             6365BF26A7003F43C0270BBB44EC780E
             6119FA19AA99F0265850BD29C49E2436
             A9
ciphertext = d3312031380deb46e7f56220c934a759
             55a95fc750f3e535ada7d371ad60b3a7
             c6406389a62b1e66be371baa8adba267
             225d522936c3829c035ab109526d296f
             12
</artwork></figure>
<figure><artwork>
key =        880D8B115BA55842FF4505C5E45F78F6
nonce =      131D6E569B5CCB6E563D2CED8616E6AC
AAD =        01BD52F7065A35A07EE70D9A881EDDB4
plaintext =  00000000000000000000000000000000
             B1E0CC8A07264432823C68B2EF59E592
             D271271029F6364CEEE577D9FDA8E5C4
             131D6E569B5CCB6E563D2CED8616E6AC
             C6
ciphertext = 395f5d80788231bd0cc055ef1fd83941
             7501a2b4d9c42952ffcbd98be6393305
             41968ef42d589e5eb807054af2557905
             12bb5dda5be418335ae9b7e9d18c8ce8
             f7
</artwork></figure>
<figure><artwork>
key =        880D8B115BA55842FF4505C5E45F78F6
nonce =      131D6E569B5CCB6E563D2CED8616E6AC
AAD =        01BD52F7065A35A07EE70D9A881EDDB4
plaintext =  01000000000000000000000000000000
             B1E0CC8A07264432823C68B2EF59E592
             D271271029F6364CEEE577D9FDA8E5C4
             131D6E569B5CCB6E563D2CED8616E6AC
             C6
ciphertext = e6807e6ba3f4fba237c996f91bf6beba
             bf243915da3e8ab4c73c5ed9c0a8136b
             00dc6d7b4994b7c8551b5bf1a042c2f2
             2da1129fcbe45e310f880552a27b3f5b
             84
</artwork></figure>
</section>
</back>
</rfc>