[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          N. Madden
Internet-Draft                                                 ForgeRock
Intended status: Informational                         November 22, 2018
Expires: May 26, 2019


            Synthetic IV (SIV) for non-AES ciphers and MACs
                    draft-madden-generalised-siv-00

Abstract

   This document specifies how the Synthetic Initialization Vector (SIV)
   block cipher mode of operation can be adapted to non-AES ciphers and
   message authentication codes (MACs), with block sizes and MAC tag
   sizes other than 128 bits.  Concrete instantiations are defined using
   the XChaCha20 nonce-extended stream cipher combined with HMAC-SHA256.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 26, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Madden                    Expires May 26, 2019                  [Page 1]


Internet-Draft               Generalised SIV               November 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   2
     1.2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Generic SIV Construction  . . . . . . . . . . . . . . . .   3
     2.1.  Encryption  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Decryption  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Generalised S2V . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  AES-SIV . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  XChaCha20-HMAC-SHA256-SIV . . . . . . . . . . . . . . . . . .   8
   4.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  AEAD_XCHACHA20_SIV_HMAC_SHA256  . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  12
     A.1.  Nonce-Based Authenticated Encryption Example  . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The Synthetic Initialization Vector (SIV) block cipher mode of
   operation [RFC5297] provides either deterministic authenticated
   encryption (DAE) or nonce-reuse misuse-resistant authenticated
   encryption (MRAE) [DAE].  It was originally specified for the
   combination of AES-CMAC for authenticity and AES-CTR for
   confidentiality.  The 128-bit AES-CMAC tag is used as the 128-bit
   (synthetic) IV for AES-CTR.  This document show how to apply SIV mode
   to ciphers and MACs with IV and tag lengths other than 128 bits,
   including where the IV and tag length may differ.

1.1.  Requirements Terminology

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

1.2.  Motivation

   Common IV-based authenticated encryption modes of operation require a
   unique IV (or nonce) to be provided on each call to the encryption
   function with the same key.  If an IV is reused, either by accident
   or through malicious action, then some combination of the
   confidentiality and/or authenticity properties is usually lost.  For



Madden                    Expires May 26, 2019                  [Page 2]


Internet-Draft               Generalised SIV               November 2018


   the popular Galois Counter Mode (GCM) [SP800-38D], NIST states that
   "a breach of the requirement [...] for the uniqueness of the
   initialization strings may compromise the security assurance almost
   entirely" (section 3 and Appendix A).  The SIV mode of operation
   [RFC5297][SIV], when used with a unique nonce as part of the
   associated data, provides a measure of protection against nonce
   reuse.  If a nonce is reused with SIV mode then there is no loss of
   authenticity, and a minimal loss of confidentiality: an attacker is
   able to determine only whether the exact same message has been
   encrypted with the same associated data and nonce using the same key.

   While the SIV mode is specified as a generic composition of an IV-
   based encryption scheme and a pseudorandom function (PRF), most uses
   of the mode have concentrated on the one concrete instantiation of
   the mode given at the time: AES-SIV.  AES-SIV is built entirely from
   the AES block cipher, using AES-CMAC [RFC4493] as the PRF and AES in
   CTR mode for confidentiality.  This combination is attractive as it
   requires only an AES encryption operation to implement all aspects of
   the mode.  It also has the convenient property that AES-CMAC produces
   a 128-bit tag, and AES-CTR requires a 128-bit IV, which allows the
   tag to be used directly as the (synthetic) IV.

   While AES-SIV has many attractive properties, there are good reasons
   for extending SIV to other ciphers and PRFs.  As stated in the
   rationale for adopting ChaCha20 and Poly1305 for IETF protocols
   [RFC8439], overreliance on a single cipher design, however good, may
   cause difficulties if a weakness is ever discovered in AES.
   Secondly, AES can be difficult to implement efficiently in software
   while avoiding timing side-channels.  Finally, there is the simple
   fact that non-AES ciphers and PRFs exist and will continue to be
   used, and SIV mode is of independent interest to users of those
   alternative primitives.

2.  The Generic SIV Construction

   The generic SIV construction is defined in terms two primitive
   functions:

   1.  A PRF, F*, that takes a vector of strings as input.

   2.  A length-preserving IV-based encryption scheme, E.

   The S2V function can be used to build F* from a PRF, F, that takes a
   single string input.  The generalised version of this function is
   described in the next section.

   The following constants MUST be defined for any concrete
   instantiation of E and F*:



Madden                    Expires May 26, 2019                  [Page 3]


Internet-Draft               Generalised SIV               November 2018


      IV_LEN - the length of IV/nonce expected by E, in bits.

      TAG_LEN - the length of the output tag produced by F*, in bits.

      PRF_KEY_LEN - the length of key required for F*, in bits.

      CIPHER_KEY_LEN - the length of key required for E, in bits.

   For any choice of E and F*, TAG_LEN MUST be greater than or equal to
   IV_LEN.

   We denote the encryption operation of E as E.encrypt(key, iv,
   plaintext), and the decryption operation as E.decrypt(key, iv,
   ciphertext).

2.1.  Encryption

   Encryption takes as input a key, K, a plaintext P, and zero or more
   associated data headers to be authenticated but not encrypted.  The
   key K MUST be as long as the sum of the key length of F* and the key
   length of E.  For example, if F* requires a 256-bit key and E
   requires a 128-bit key, then K must be 384 bits long.

   Encryption proceeds as follows.  Firstly, keys K1 and K2 are derived
   from K by taking the leftmost PRF_KEY_LEN bits of K as K1, and the
   rightmost CIPHER_KEY_LEN bits of K as K2.  Secondly, the PRF F* is
   applied to K1, the plaintext P, and all of the n associated data
   strings AD1, ..., ADn.  This results in an authentication tag, T.
   The SIV is defined as the leftmost IV_LEN bits of T.  If TAG_LEN =
   IV_LEN, then T is used in its entirety.  The plaintext P is then
   encrypted using E, with K2 as the key and SIV as the IV, producing
   ciphertext C.  The concatenation of T with C is returned as the
   output of the function.

   In pseudocode, generalised SIV encryption is as follows:

   SIV-ENCRYPT[F*,E](K, P, AD1, ..., ADn) {
       K1 = leftmost(K, PRF_KEY_LEN)
       K2 = rightmost(K, CIPHER_KEY_LEN)
       T = F*(K1, AD1, ..., ADn, P)
       SIV = leftmost(T, IV_LEN)
       C = E.encrypt(K2, SIV, P)

       return T || C
   }






Madden                    Expires May 26, 2019                  [Page 4]


Internet-Draft               Generalised SIV               November 2018


2.2.  Decryption

   Decryption takes as input a key, K, an authenticated ciphertext Z,
   and zero or more associated data blocks to be authenticated but not
   decrypted.

   Keys K1 and K2 are derived as for encryption.  The leftmost TAG_LEN
   bits of Z are taken as the tag T, while the remaining bits are the
   ciphertext C.  As for encryption, the SIV is taken as the leftmost
   IV_LEN bits of T.  The ciphertext C is then decrypted using E with
   the key K2 and SIV as the IV, producing plaintext P.  The expected
   authentication tag T' is then computed using F* over the key K1, the
   associated data AD1, ..., ADn, and the plaintext P.  If T' exactly
   matches T then the plaintext P is returned.  If T' does not match T
   then the implementation MUST NOT return P and MUST destroy P and T'
   and return a failure.  Authentication tag comparisons SHOULD be
   performed in constant time to avoid leaking the true value of T'
   through timing differences.

   SIV-DECRYPT[F*,E](K, Z, AD1, ..., ADn) {
       T = leftmost(Z, TAG_LEN)
       C = rightmost(Z, len(Z) - TAG_LEN)
       K1 = leftmost(K, PRF_KEY_LEN)
       K2 = rightmost(K, CIPHER_KEY_LEN)
       SIV = leftmost(T, IV_LEN)

       P = E.decrypt(K2, SIV, C)
       T' = F*(K1, AD1, ..., ADn, P)

       if T = T' then
           return P
       else
           destroy P and T'
           return FAIL
       fi
   }

2.3.  Generalised S2V

   SIV requires a PRF that takes a vector of strings as input, while
   most PRFs in current use are designed to only take a single string.
   In principle, any unambiguous encoding can be used to convert a
   vector of inputs into a single string, but SIV defines a particularly
   efficient encoding provided by the function S2V (for "string to
   vector") that converts a single-string PRF to a vector input PRF.
   S2V is defined using bitwise exclusive OR (XOR) and a doubling
   operation in the finite field GF(2^n) where n is the bit length of
   the output of the PRF.  For AES-SIV, which uses AES-CMAC as the PRF,



Madden                    Expires May 26, 2019                  [Page 5]


Internet-Draft               Generalised SIV               November 2018


   this is GF(2^128).  In this section we show how to define S2V for
   PRFs with different tag lengths.

   Points in the finite field GF(2^n) are represented as n-bit strings
   a_(n-1) ... a_1 a_0, which can also be seen as binary coefficients
   for a polynomial f(x) = a_(n-1) * x^(n-1) + ... + a_1 * x + a_0.
   Multiplication is then defined as the product of two polynomials,
   with the remainder taken after division by a fixed polynomial.  In
   S2V, the fixed polynomial is the lexicographically first minimum-
   weight primitive polynomial [SIV] (section 2).  For GF(2^128), such a
   primitive polynomial is:

   f(x) = x^128 + x^7 + x^2 + x + 1

   Primitive polynomials for other fields can be found in published
   tables, such as [HPL-98-135].  The following polynomials are
   indicated for common PRF output sizes:

            +-----------+-------------------------------------+
            | Field     | Primitive Polynomial                |
            +-----------+-------------------------------------+
            | GF(2^64)  | f(x) = x^64 + x^4 + x^3 + x + 1     |
            | GF(2^96)  | f(x) = x^96 + x^10 + x^9 + x^6 + 1  |
            | GF(2^128) | f(x) = x^128 + x^7 + x^2 + x + 1    |
            | GF(2^160) | f(x) = x^160 + x^5 + x^3 + x^2 + 1  |
            | GF(2^192) | f(x) = x^192 + x^7 + x^2 + x + 1    |
            | GF(2^224) | f(x) = x^224 + x^9 + x^8 + x^3 + 1  |
            | GF(2^256) | f(x) = x^256 + x^10 + x^5 + x^2 + 1 |
            | GF(2^384) | f(x) = x^384 + x^12 + x^3 + x^2 + 1 |
            | GF(2^512) | f(x) = x^512 + x^8 + x^5 + x^2 + 1  |
            +-----------+-------------------------------------+

   Doubling for S2V is defined as multiplication with the binary value
   0^(n-2)10 (i.e., the number 2 represented as an n-bit binary string).
   The doubling operation can be efficiently implemented as a left-shift
   operation followed by a conditional XOR with an n-bit constant
   derived from the binary coefficients of the primitive polynomial.
   The condition being whether the most significant bit of the value
   being shifted off is 1.  For GF(2^128), the constant is
   0^(120)10000111, with one bits corresponding to x^7, x^2, x and 1
   respectively.  The following table lists the constants for common PRF
   output sizes in binary and hexadecimal form.  Leading zero octets are
   omitted from the hexadecimal format.








Madden                    Expires May 26, 2019                  [Page 6]


Internet-Draft               Generalised SIV               November 2018


   +-----------+----------------------------+-------------------------+
   | Field     | Doubling Constant - Binary | Doubling Constant - Hex |
   +-----------+----------------------------+-------------------------+
   | GF(2^64)  |                0^(59)11011 |                    0x1b |
   | GF(2^92)  |          0^(150)1100100001 |                  0x0321 |
   | GF(2^128) |            0^(120)10000111 |                    0x87 |
   | GF(2^160) |              0^(154)101101 |                    0x2d |
   | GF(2^192) |            0^(184)10000111 |                    0x87 |
   | GF(2^224) |          0^(214)1100001001 |                  0x0309 |
   | GF(2^256) |         0^(245)10000100101 |                  0x0425 |
   | GF(2^384) |       0^(371)1000000001101 |                  0x100d |
   | GF(2^256) |           0^(503)100100101 |                  0x0125 |
   +-----------+----------------------------+-------------------------+

   It is recommended that the conditional XOR be performed in constant
   time.  A constant time bit-sliced implementation is provided in
   Appendix A.

   The S2V algorithm parameterised over a particular PRF, F, written
   S2V[F] is as follows, where TAG_LEN is the output size of the PRF in
   bits, dbl(x) is the appropriate doubling operation for TAG_LEN, and
   xorend is defined as in [RFC5297].  The constant <zero> is the
   TAG_LEN sequence of all zero bits, and <one> is TAG_LEN-1 zero bits
   followed by a single 1 bit.  The function pad(X) pads the input to
   TAG_LEN bits by appending a single 1 bit followed by as many 0 bits
   as necessary.

   S2V[F](K, S1, ..., Sn) {
       if n = 0 then
           return F(K, <one>)
       fi
       D = F(K, <zero>)
       for i = 1 to n-1 do
           D = dbl(D) xor F(K, Si)
       done
       if len(Sn) >= TAG_LEN then
           T = Sn xorend D
       else
           T = dbl(D) xor pad(Sn)
       fi
       return F(K, T)
   }

2.4.  AES-SIV

   This section is non-normative.





Madden                    Expires May 26, 2019                  [Page 7]


Internet-Draft               Generalised SIV               November 2018


   The original AES-SIV mode of [RFC5297] can be seen as an
   instantiation of the generic SIV construction in this document, with
   the following parameters:

      F* = S2V[AES-CMAC]

      E = AES-CTR where the 31st and 63rd bits of the IV are zeroed
      prior to use as described in [RFC5297] section 2.5.

      PRF_KEY_LEN = 128, 192 or 256 bits

      CIPHER_KEY_LEN = 128, 192 or 256 bits (to match PRF_KEY_LEN).

      IV_LEN = TAG_LEN = 128 bits.

3.  XChaCha20-HMAC-SHA256-SIV

   ChaCha20 is a stream cipher that has been adopted for use in IETF
   protocols by [RFC8439].  It has several attractive properties, most
   notably that it can be implemented efficiently in software and is
   relatively easy to make resistant to cache-timing side-channel
   attacks.  As originally specified, ChaCha20 takes a 256-bit key and a
   64-bit nonce, which was extended to 96-bits when adopted by the IETF.
   A 96-bit nonce is too small to be safely generated randomly (or
   pseudorandomly as in SIV) without artificially limiting the number of
   messages that can be encrypted with a single key.  To address this
   problem, an extended nonce variant known as XChaCha20
   [I-D.arciszewski-xchacha] has been proposed, which increase the nonce
   to 192-bits.  This makes it an excellent choice for an SIV
   instantiation, providing a MRAE cipher mode alternative to AES.

   In principle, any PRF that produces at least a 192-bit output could
   be used with XChaCha20.  For concreteness, we specify the use of HMAC
   [RFC2104] with the SHA-256 secure hash function [RFC6234] as HMAC-
   SHA256 is widely implemented.  The S2V function of section 2.3 is
   used to allow HMAC-SHA256 to take a vector of strings as input, with
   the primitive polynomial for GF(2^256) used for point doubling and
   the leftmost 192 bits of the S2V[HMAC-SHA256] tag used as the
   synthetic IV for XChaCha20.

   The encryption and decryption procedures are as described in sections
   2.1 and 2.2 above, with the following constant values:

      PRF_KEY_LEN = 256 bits.

      CIPHER_KEY_LEN = 256 bits.

      IV_LEN = 192 bits.



Madden                    Expires May 26, 2019                  [Page 8]


Internet-Draft               Generalised SIV               November 2018


      TAG_LEN = 256 bits.

   Test vectors for XChaCha20-HMAC-SHA256-SIV are provided in
   Appendix A.

4.  IANA considerations

   This section registers AEAD algorithms as per the registry
   established in [RFC5116].  As specified in [RFC5297] section 6, the
   interface of RFC 5116 only allows a single associated data (AD)
   component.  When SIV is accessed via this interface, multiple AD
   components must be marshalled into a single string prior to calling
   the SIV procedures.

4.1.  AEAD_XCHACHA20_SIV_HMAC_SHA256

   The AEAD_XCHACHA20_SIV_HMAC_SHA256 algorithm is an instantiation of
   the generalised SIV mode described in Sections 2.1 and 2.2 with the
   XChaCha20 extended-nonce stream cipher [I-D.arciszewski-xchacha] and
   HMAC-SHA256 as the PRF, as described in Section 3.  XChaCha20 uses a
   32-bit block counter and a 512-bit block size, therefore the maximum
   size of plaintext that can be encrypted in a single invocation is
   2^38 octets, around 256 GB.  The ciphertext length is equal to the
   length of the plaintext plus 32 octets for the HMAC-SHA256
   authentication tag (of which the leftmost 24 octets comprise the
   SIV).

   The input and output lengths for AEAD_XCHACHA20_SIV_HMAC_SHA256 as
   defined by [RFC5116] are:

      K_LEN is 64 octets.
      P_MAX is 2^38 octets.
      A_MAX is unlimited.
      N_MIN is 1 octet.
      N_MAX is unlimited.
      C_MAX is 2^38 + 32 octets.

5.  Security Considerations

   The security considerations of [RFC5297] apply here.

   The security proofs for SIV [DAE] require that F* (and F if
   constructing F* using S2V) behaves as a pseudorandom function (PRF).
   E must be a length-preserving semantically-secure encryption scheme.

   It is RECOMMENDED that SIV mode is always used with a unique random
   component included as the last element of the header (associated
   data) to ensure semantic security.  While SIV mode loses a minimal



Madden                    Expires May 26, 2019                  [Page 9]


Internet-Draft               Generalised SIV               November 2018


   amount of security if this component is omitted (or accidentally
   reused), an attacker in this case is able to determine if the same
   plaintext has been encrypted under the same key and with the same
   associated data.  Depending on the application this may still be a
   significant loss of confidentiality.  For example, a service that
   produces yes/no answers to questions would lose all confidentiality
   of its responses in this case.  The misuse resistance of SIV should
   be considered a failsafe and not as a way to do without a nonce.

   The requirement that E be length-preserving means that the ciphertext
   produced by SIV mode will be equal in length to the input plaintext,
   plus the authentication tag (which is of fixed size for any concrete
   instantiation of this mode).  If the length of the plaintext on its
   own may reveal information then care should be taken to obscure this
   prior to encryption -- by padding to a known maximum length, for
   example.  In the case of the yes/no answer service the English words
   "yes" and "no" can be distinguished purely by length, to give a
   simple example.

   In [tightness], Chatterjee, Menezes and Sarkar show an attack on SIV
   within the multi-user setting.  It is RECOMMENDED that concrete
   instantiations intended for such use define a MAC_KEY_LENGTH of at
   least 256 bits or describe other countermeasures.

   The number of components passed to any invocation of S2V (including
   the plaintext) must not exceed TAG_LEN - 1.  For example, a 128-bit
   PRF such as AES-CMAC should allow no more than 127 components.  For
   XChaCha20-HMAC-SHA256-SIV no more than 255 components should be
   allowed.

6.  References

6.1.  Normative References

   [I-D.arciszewski-xchacha]
              Arciszewski, S., "XChaCha: eXtended-nonce ChaCha and
              AEAD_XChaCha20_Poly1305", draft-arciszewski-xchacha-02
              (work in progress), October 2018.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC5297]  Harkins, D., "Synthetic Initialization Vector (SIV)
              Authenticated Encryption Using the Advanced Encryption
              Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October
              2008, <https://www.rfc-editor.org/info/rfc5297>.




Madden                    Expires May 26, 2019                 [Page 10]


Internet-Draft               Generalised SIV               November 2018


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2.  Informative References

   [DAE]      Rogaway, P. and T. Shrimpton, "Deterministic
              Authenticated-Encryption. A Provable-Security Treatment of
              the Key-Wrap Problem.", IACR ePrint 2006/221, August 2007.

   [HPL-98-135]
              Seroussi, G., "Table of Low-Weight Binary Irreducible
              Polynomials", HPL HPL-98-135, August 1998.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
              2006, <https://www.rfc-editor.org/info/rfc4493>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
              <https://www.rfc-editor.org/info/rfc8439>.

   [SIV]      Rogaway, P. and T. Shrimpton, "The SIV Mode of Operation
              for Deterministic Authenticated-Encryption (Key Wrap) and
              Misuse-Resistant Nonce-Based Authenticated-Encryption.",
              August 2007.

   [SP800-38D]
              Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC.", NIST
              Special Publication 800-38D, November 2007.

   [tightness]
              Chatterjee, S., Menezes, A., and P. Sarkar, "Another Look
              at Tightness", Proceedings of SAC 2011, Lecture Notes in
              Computer Science 7118, August 2011.





Madden                    Expires May 26, 2019                 [Page 11]


Internet-Draft               Generalised SIV               November 2018


Appendix A.  Test Vectors

A.1.  Nonce-Based Authenticated Encryption Example

  Input
  -----
  Key:
  000  80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f  ................
  016  90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f  ................
  032  a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af  ................
  048  b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf  ................

  Plaintext:
  000  4c 61 64 69 65 73 20 61 6e 64 20 47 65 6e 74 6c  Ladies and Gentl
  016  65 6d 65 6e 20 6f 66 20 74 68 65 20 63 6c 61 73  emen of the clas
  032  73 20 6f 66 20 27 39 39 3a 20 49 66 20 49 20 63  s of '99: If I c
  048  6f 75 6c 64 20 6f 66 66 65 72 20 79 6f 75 20 6f  ould offer you o
  064  6e 6c 79 20 6f 6e 65 20 74 69 70 20 66 6f 72 20  nly one tip for
  080  74 68 65 20 66 75 74 75 72 65 2c 20 73 75 6e 73  the future, suns
  096  63 72 65 65 6e 20 77 6f 75 6c 64 20 62 65 20 69  creen would be i
  112  74 2e                                            t.

  Nonce:
  000  50 51 52 53 c0 c1 c2 c3 c4 c5 c6 c7              PQRS........

  IV:
  000  40 41 42 43 44 45 46 47                          @ABCDEFG

  S2V[HMAC-SHA256]
  ----------------
  HMAC-SHA256(<zero>):
      318dcd14 73a3c69c 643eb853 e66eb357
      c5bcb67b cd96ea83 4af2a3c6 f462136f

  dbl():
      631b9a28 e7478d38 c87d70a7 ccdd66af
      8b796cf7 9b2dd506 95e5478d e8c426de

  HMAC-SHA256(AD1):
      8b80c006 47844e6b 54617036 b1c09145
      0ab8ad63 1e7ca653 326a8d4f e135dafb

  xor:
      e89b5a2e a0c3c353 9c1c0091 7d1df7ea
      81c1c194 85517355 a78fcac2 09f1fc25

  dbl():
      d136b45d 418786a7 38380122 fa3befd5



Madden                    Expires May 26, 2019                 [Page 12]


Internet-Draft               Generalised SIV               November 2018


      03838329 0aa2e6ab 4f1f9584 13e3fc6f

  HMAC-SHA256(Nonce):
      7c07875c 75e0021c 6f58cbd2 052675e3
      2690107a 1f618e40 34b79efc d23d3a57

  xor:
      ad313301 346784bb 5760caf0 ff1d9a36
      25139353 15c368eb 7ba80b78 c1dec638

  xorend:
      4c616469 65732061 6e642047 656e746c
      656d656e 206f6620 74686520 636c6173
      73206f66 20273939 3a204966 20492063
      6f756c64 206f6666 65722079 6f75206f
      6e6c7920 6f6e6520 74697020 666f7220
      7468c811 55744012 f6de7b40 b985916e
      f9444076 fd7362ac 1d871f88 691de1b7
      b216

  HMAC-SHA256(final):
      28fdb5d4 d89e4860 11774606 5456a5df
      924e8f4b 0f42bc77 a7415bd0 e0430628

  XChaCha20
  ---------
  SIV:
      28fdb5d4 d89e4860 11774606 5456a5df
      924e8f4b 0f42bc77

  Block Counter:
      00000000

  XChaCha20 Subkey:
      70c5831f 36e439c1 b90e375e 2b98c3da
      ef42de2e c120e1d1 2706af76 45381de1

  XChaCha20 Nonce:
      00000000 924e8f4b 0f42bc77

  Output
  ------
  T || C:
  000  28 fd b5 d4 d8 9e 48 60 11 77 46 06 54 56 a5 df  (.....H`.wF.TV..
  016  92 4e 8f 4b 0f 42 bc 77 a7 41 5b d0 e0 43 06 28  .N.K.B.w.A[..C.(
  032  26 53 ea bf c6 ae cc 14 d0 46 aa 7e 3c 0b a2 8e  &S.......F.~<...
  048  fd 68 f3 d5 91 fc ac 6d b1 2e a2 3c f4 28 69 01  .h.....m...<.(i.
  064  3b 2b e4 83 ce 08 8a f8 2d e4 29 3a 07 e2 40 07  ;+......-.):..@.



Madden                    Expires May 26, 2019                 [Page 13]


Internet-Draft               Generalised SIV               November 2018


  080  f3 7b d1 e3 78 81 a0 4b 11 5b 11 09 94 78 ae 34  .{..x..K.[...x.4
  096  75 05 43 26 8e 57 0d 1f 27 f4 da fc 5a d8 71 97  u.C&.W..'...Z.q.
  112  7f 08 b3 0b af df b5 3b 19 ef 34 2c d9 5c e7 91  .......;..4,.\..
  128  5c b4 f6 79 db 64 0d 8e c4 8a 06 b6 f3 ef 50 8c  \..y.d........P.
  144  53 30                                            S0

Author's Address

   Neil Madden
   ForgeRock
   Broad Quay House
   Prince Street
   Bristol  BS1 4DJ
   United Kingdom

   Email: neil.madden@forgerock.com



































Madden                    Expires May 26, 2019                 [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/