idnits 2.17.1 draft-madden-generalised-siv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 22, 2018) is 1979 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'F' is mentioned on line 304, but not defined == Missing Reference: 'AES-CMAC' is mentioned on line 336, but not defined == Missing Reference: 'HMAC-SHA256' is mentioned on line 552, but not defined == Outdated reference: A later version (-03) exists of draft-arciszewski-xchacha-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Madden 3 Internet-Draft ForgeRock 4 Intended status: Informational November 22, 2018 5 Expires: May 26, 2019 7 Synthetic IV (SIV) for non-AES ciphers and MACs 8 draft-madden-generalised-siv-00 10 Abstract 12 This document specifies how the Synthetic Initialization Vector (SIV) 13 block cipher mode of operation can be adapted to non-AES ciphers and 14 message authentication codes (MACs), with block sizes and MAC tag 15 sizes other than 128 bits. Concrete instantiations are defined using 16 the XChaCha20 nonce-extended stream cipher combined with HMAC-SHA256. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 26, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 2 54 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. The Generic SIV Construction . . . . . . . . . . . . . . . . 3 56 2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Generalised S2V . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. AES-SIV . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. XChaCha20-HMAC-SHA256-SIV . . . . . . . . . . . . . . . . . . 8 61 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. AEAD_XCHACHA20_SIV_HMAC_SHA256 . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 6.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 12 68 A.1. Nonce-Based Authenticated Encryption Example . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 The Synthetic Initialization Vector (SIV) block cipher mode of 74 operation [RFC5297] provides either deterministic authenticated 75 encryption (DAE) or nonce-reuse misuse-resistant authenticated 76 encryption (MRAE) [DAE]. It was originally specified for the 77 combination of AES-CMAC for authenticity and AES-CTR for 78 confidentiality. The 128-bit AES-CMAC tag is used as the 128-bit 79 (synthetic) IV for AES-CTR. This document show how to apply SIV mode 80 to ciphers and MACs with IV and tag lengths other than 128 bits, 81 including where the IV and tag length may differ. 83 1.1. Requirements Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC8174] when, and only when, they appear in all capitals, as 89 shown here. 91 1.2. Motivation 93 Common IV-based authenticated encryption modes of operation require a 94 unique IV (or nonce) to be provided on each call to the encryption 95 function with the same key. If an IV is reused, either by accident 96 or through malicious action, then some combination of the 97 confidentiality and/or authenticity properties is usually lost. For 98 the popular Galois Counter Mode (GCM) [SP800-38D], NIST states that 99 "a breach of the requirement [...] for the uniqueness of the 100 initialization strings may compromise the security assurance almost 101 entirely" (section 3 and Appendix A). The SIV mode of operation 102 [RFC5297][SIV], when used with a unique nonce as part of the 103 associated data, provides a measure of protection against nonce 104 reuse. If a nonce is reused with SIV mode then there is no loss of 105 authenticity, and a minimal loss of confidentiality: an attacker is 106 able to determine only whether the exact same message has been 107 encrypted with the same associated data and nonce using the same key. 109 While the SIV mode is specified as a generic composition of an IV- 110 based encryption scheme and a pseudorandom function (PRF), most uses 111 of the mode have concentrated on the one concrete instantiation of 112 the mode given at the time: AES-SIV. AES-SIV is built entirely from 113 the AES block cipher, using AES-CMAC [RFC4493] as the PRF and AES in 114 CTR mode for confidentiality. This combination is attractive as it 115 requires only an AES encryption operation to implement all aspects of 116 the mode. It also has the convenient property that AES-CMAC produces 117 a 128-bit tag, and AES-CTR requires a 128-bit IV, which allows the 118 tag to be used directly as the (synthetic) IV. 120 While AES-SIV has many attractive properties, there are good reasons 121 for extending SIV to other ciphers and PRFs. As stated in the 122 rationale for adopting ChaCha20 and Poly1305 for IETF protocols 123 [RFC8439], overreliance on a single cipher design, however good, may 124 cause difficulties if a weakness is ever discovered in AES. 125 Secondly, AES can be difficult to implement efficiently in software 126 while avoiding timing side-channels. Finally, there is the simple 127 fact that non-AES ciphers and PRFs exist and will continue to be 128 used, and SIV mode is of independent interest to users of those 129 alternative primitives. 131 2. The Generic SIV Construction 133 The generic SIV construction is defined in terms two primitive 134 functions: 136 1. A PRF, F*, that takes a vector of strings as input. 138 2. A length-preserving IV-based encryption scheme, E. 140 The S2V function can be used to build F* from a PRF, F, that takes a 141 single string input. The generalised version of this function is 142 described in the next section. 144 The following constants MUST be defined for any concrete 145 instantiation of E and F*: 147 IV_LEN - the length of IV/nonce expected by E, in bits. 149 TAG_LEN - the length of the output tag produced by F*, in bits. 151 PRF_KEY_LEN - the length of key required for F*, in bits. 153 CIPHER_KEY_LEN - the length of key required for E, in bits. 155 For any choice of E and F*, TAG_LEN MUST be greater than or equal to 156 IV_LEN. 158 We denote the encryption operation of E as E.encrypt(key, iv, 159 plaintext), and the decryption operation as E.decrypt(key, iv, 160 ciphertext). 162 2.1. Encryption 164 Encryption takes as input a key, K, a plaintext P, and zero or more 165 associated data headers to be authenticated but not encrypted. The 166 key K MUST be as long as the sum of the key length of F* and the key 167 length of E. For example, if F* requires a 256-bit key and E 168 requires a 128-bit key, then K must be 384 bits long. 170 Encryption proceeds as follows. Firstly, keys K1 and K2 are derived 171 from K by taking the leftmost PRF_KEY_LEN bits of K as K1, and the 172 rightmost CIPHER_KEY_LEN bits of K as K2. Secondly, the PRF F* is 173 applied to K1, the plaintext P, and all of the n associated data 174 strings AD1, ..., ADn. This results in an authentication tag, T. 175 The SIV is defined as the leftmost IV_LEN bits of T. If TAG_LEN = 176 IV_LEN, then T is used in its entirety. The plaintext P is then 177 encrypted using E, with K2 as the key and SIV as the IV, producing 178 ciphertext C. The concatenation of T with C is returned as the 179 output of the function. 181 In pseudocode, generalised SIV encryption is as follows: 183 SIV-ENCRYPT[F*,E](K, P, AD1, ..., ADn) { 184 K1 = leftmost(K, PRF_KEY_LEN) 185 K2 = rightmost(K, CIPHER_KEY_LEN) 186 T = F*(K1, AD1, ..., ADn, P) 187 SIV = leftmost(T, IV_LEN) 188 C = E.encrypt(K2, SIV, P) 190 return T || C 191 } 193 2.2. Decryption 195 Decryption takes as input a key, K, an authenticated ciphertext Z, 196 and zero or more associated data blocks to be authenticated but not 197 decrypted. 199 Keys K1 and K2 are derived as for encryption. The leftmost TAG_LEN 200 bits of Z are taken as the tag T, while the remaining bits are the 201 ciphertext C. As for encryption, the SIV is taken as the leftmost 202 IV_LEN bits of T. The ciphertext C is then decrypted using E with 203 the key K2 and SIV as the IV, producing plaintext P. The expected 204 authentication tag T' is then computed using F* over the key K1, the 205 associated data AD1, ..., ADn, and the plaintext P. If T' exactly 206 matches T then the plaintext P is returned. If T' does not match T 207 then the implementation MUST NOT return P and MUST destroy P and T' 208 and return a failure. Authentication tag comparisons SHOULD be 209 performed in constant time to avoid leaking the true value of T' 210 through timing differences. 212 SIV-DECRYPT[F*,E](K, Z, AD1, ..., ADn) { 213 T = leftmost(Z, TAG_LEN) 214 C = rightmost(Z, len(Z) - TAG_LEN) 215 K1 = leftmost(K, PRF_KEY_LEN) 216 K2 = rightmost(K, CIPHER_KEY_LEN) 217 SIV = leftmost(T, IV_LEN) 219 P = E.decrypt(K2, SIV, C) 220 T' = F*(K1, AD1, ..., ADn, P) 222 if T = T' then 223 return P 224 else 225 destroy P and T' 226 return FAIL 227 fi 228 } 230 2.3. Generalised S2V 232 SIV requires a PRF that takes a vector of strings as input, while 233 most PRFs in current use are designed to only take a single string. 234 In principle, any unambiguous encoding can be used to convert a 235 vector of inputs into a single string, but SIV defines a particularly 236 efficient encoding provided by the function S2V (for "string to 237 vector") that converts a single-string PRF to a vector input PRF. 238 S2V is defined using bitwise exclusive OR (XOR) and a doubling 239 operation in the finite field GF(2^n) where n is the bit length of 240 the output of the PRF. For AES-SIV, which uses AES-CMAC as the PRF, 241 this is GF(2^128). In this section we show how to define S2V for 242 PRFs with different tag lengths. 244 Points in the finite field GF(2^n) are represented as n-bit strings 245 a_(n-1) ... a_1 a_0, which can also be seen as binary coefficients 246 for a polynomial f(x) = a_(n-1) * x^(n-1) + ... + a_1 * x + a_0. 247 Multiplication is then defined as the product of two polynomials, 248 with the remainder taken after division by a fixed polynomial. In 249 S2V, the fixed polynomial is the lexicographically first minimum- 250 weight primitive polynomial [SIV] (section 2). For GF(2^128), such a 251 primitive polynomial is: 253 f(x) = x^128 + x^7 + x^2 + x + 1 255 Primitive polynomials for other fields can be found in published 256 tables, such as [HPL-98-135]. The following polynomials are 257 indicated for common PRF output sizes: 259 +-----------+-------------------------------------+ 260 | Field | Primitive Polynomial | 261 +-----------+-------------------------------------+ 262 | GF(2^64) | f(x) = x^64 + x^4 + x^3 + x + 1 | 263 | GF(2^96) | f(x) = x^96 + x^10 + x^9 + x^6 + 1 | 264 | GF(2^128) | f(x) = x^128 + x^7 + x^2 + x + 1 | 265 | GF(2^160) | f(x) = x^160 + x^5 + x^3 + x^2 + 1 | 266 | GF(2^192) | f(x) = x^192 + x^7 + x^2 + x + 1 | 267 | GF(2^224) | f(x) = x^224 + x^9 + x^8 + x^3 + 1 | 268 | GF(2^256) | f(x) = x^256 + x^10 + x^5 + x^2 + 1 | 269 | GF(2^384) | f(x) = x^384 + x^12 + x^3 + x^2 + 1 | 270 | GF(2^512) | f(x) = x^512 + x^8 + x^5 + x^2 + 1 | 271 +-----------+-------------------------------------+ 273 Doubling for S2V is defined as multiplication with the binary value 274 0^(n-2)10 (i.e., the number 2 represented as an n-bit binary string). 275 The doubling operation can be efficiently implemented as a left-shift 276 operation followed by a conditional XOR with an n-bit constant 277 derived from the binary coefficients of the primitive polynomial. 278 The condition being whether the most significant bit of the value 279 being shifted off is 1. For GF(2^128), the constant is 280 0^(120)10000111, with one bits corresponding to x^7, x^2, x and 1 281 respectively. The following table lists the constants for common PRF 282 output sizes in binary and hexadecimal form. Leading zero octets are 283 omitted from the hexadecimal format. 285 +-----------+----------------------------+-------------------------+ 286 | Field | Doubling Constant - Binary | Doubling Constant - Hex | 287 +-----------+----------------------------+-------------------------+ 288 | GF(2^64) | 0^(59)11011 | 0x1b | 289 | GF(2^92) | 0^(150)1100100001 | 0x0321 | 290 | GF(2^128) | 0^(120)10000111 | 0x87 | 291 | GF(2^160) | 0^(154)101101 | 0x2d | 292 | GF(2^192) | 0^(184)10000111 | 0x87 | 293 | GF(2^224) | 0^(214)1100001001 | 0x0309 | 294 | GF(2^256) | 0^(245)10000100101 | 0x0425 | 295 | GF(2^384) | 0^(371)1000000001101 | 0x100d | 296 | GF(2^256) | 0^(503)100100101 | 0x0125 | 297 +-----------+----------------------------+-------------------------+ 299 It is recommended that the conditional XOR be performed in constant 300 time. A constant time bit-sliced implementation is provided in 301 Appendix A. 303 The S2V algorithm parameterised over a particular PRF, F, written 304 S2V[F] is as follows, where TAG_LEN is the output size of the PRF in 305 bits, dbl(x) is the appropriate doubling operation for TAG_LEN, and 306 xorend is defined as in [RFC5297]. The constant is the 307 TAG_LEN sequence of all zero bits, and is TAG_LEN-1 zero bits 308 followed by a single 1 bit. The function pad(X) pads the input to 309 TAG_LEN bits by appending a single 1 bit followed by as many 0 bits 310 as necessary. 312 S2V[F](K, S1, ..., Sn) { 313 if n = 0 then 314 return F(K, ) 315 fi 316 D = F(K, ) 317 for i = 1 to n-1 do 318 D = dbl(D) xor F(K, Si) 319 done 320 if len(Sn) >= TAG_LEN then 321 T = Sn xorend D 322 else 323 T = dbl(D) xor pad(Sn) 324 fi 325 return F(K, T) 326 } 328 2.4. AES-SIV 330 This section is non-normative. 332 The original AES-SIV mode of [RFC5297] can be seen as an 333 instantiation of the generic SIV construction in this document, with 334 the following parameters: 336 F* = S2V[AES-CMAC] 338 E = AES-CTR where the 31st and 63rd bits of the IV are zeroed 339 prior to use as described in [RFC5297] section 2.5. 341 PRF_KEY_LEN = 128, 192 or 256 bits 343 CIPHER_KEY_LEN = 128, 192 or 256 bits (to match PRF_KEY_LEN). 345 IV_LEN = TAG_LEN = 128 bits. 347 3. XChaCha20-HMAC-SHA256-SIV 349 ChaCha20 is a stream cipher that has been adopted for use in IETF 350 protocols by [RFC8439]. It has several attractive properties, most 351 notably that it can be implemented efficiently in software and is 352 relatively easy to make resistant to cache-timing side-channel 353 attacks. As originally specified, ChaCha20 takes a 256-bit key and a 354 64-bit nonce, which was extended to 96-bits when adopted by the IETF. 355 A 96-bit nonce is too small to be safely generated randomly (or 356 pseudorandomly as in SIV) without artificially limiting the number of 357 messages that can be encrypted with a single key. To address this 358 problem, an extended nonce variant known as XChaCha20 359 [I-D.arciszewski-xchacha] has been proposed, which increase the nonce 360 to 192-bits. This makes it an excellent choice for an SIV 361 instantiation, providing a MRAE cipher mode alternative to AES. 363 In principle, any PRF that produces at least a 192-bit output could 364 be used with XChaCha20. For concreteness, we specify the use of HMAC 365 [RFC2104] with the SHA-256 secure hash function [RFC6234] as HMAC- 366 SHA256 is widely implemented. The S2V function of section 2.3 is 367 used to allow HMAC-SHA256 to take a vector of strings as input, with 368 the primitive polynomial for GF(2^256) used for point doubling and 369 the leftmost 192 bits of the S2V[HMAC-SHA256] tag used as the 370 synthetic IV for XChaCha20. 372 The encryption and decryption procedures are as described in sections 373 2.1 and 2.2 above, with the following constant values: 375 PRF_KEY_LEN = 256 bits. 377 CIPHER_KEY_LEN = 256 bits. 379 IV_LEN = 192 bits. 381 TAG_LEN = 256 bits. 383 Test vectors for XChaCha20-HMAC-SHA256-SIV are provided in 384 Appendix A. 386 4. IANA considerations 388 This section registers AEAD algorithms as per the registry 389 established in [RFC5116]. As specified in [RFC5297] section 6, the 390 interface of RFC 5116 only allows a single associated data (AD) 391 component. When SIV is accessed via this interface, multiple AD 392 components must be marshalled into a single string prior to calling 393 the SIV procedures. 395 4.1. AEAD_XCHACHA20_SIV_HMAC_SHA256 397 The AEAD_XCHACHA20_SIV_HMAC_SHA256 algorithm is an instantiation of 398 the generalised SIV mode described in Sections 2.1 and 2.2 with the 399 XChaCha20 extended-nonce stream cipher [I-D.arciszewski-xchacha] and 400 HMAC-SHA256 as the PRF, as described in Section 3. XChaCha20 uses a 401 32-bit block counter and a 512-bit block size, therefore the maximum 402 size of plaintext that can be encrypted in a single invocation is 403 2^38 octets, around 256 GB. The ciphertext length is equal to the 404 length of the plaintext plus 32 octets for the HMAC-SHA256 405 authentication tag (of which the leftmost 24 octets comprise the 406 SIV). 408 The input and output lengths for AEAD_XCHACHA20_SIV_HMAC_SHA256 as 409 defined by [RFC5116] are: 411 K_LEN is 64 octets. 412 P_MAX is 2^38 octets. 413 A_MAX is unlimited. 414 N_MIN is 1 octet. 415 N_MAX is unlimited. 416 C_MAX is 2^38 + 32 octets. 418 5. Security Considerations 420 The security considerations of [RFC5297] apply here. 422 The security proofs for SIV [DAE] require that F* (and F if 423 constructing F* using S2V) behaves as a pseudorandom function (PRF). 424 E must be a length-preserving semantically-secure encryption scheme. 426 It is RECOMMENDED that SIV mode is always used with a unique random 427 component included as the last element of the header (associated 428 data) to ensure semantic security. While SIV mode loses a minimal 429 amount of security if this component is omitted (or accidentally 430 reused), an attacker in this case is able to determine if the same 431 plaintext has been encrypted under the same key and with the same 432 associated data. Depending on the application this may still be a 433 significant loss of confidentiality. For example, a service that 434 produces yes/no answers to questions would lose all confidentiality 435 of its responses in this case. The misuse resistance of SIV should 436 be considered a failsafe and not as a way to do without a nonce. 438 The requirement that E be length-preserving means that the ciphertext 439 produced by SIV mode will be equal in length to the input plaintext, 440 plus the authentication tag (which is of fixed size for any concrete 441 instantiation of this mode). If the length of the plaintext on its 442 own may reveal information then care should be taken to obscure this 443 prior to encryption -- by padding to a known maximum length, for 444 example. In the case of the yes/no answer service the English words 445 "yes" and "no" can be distinguished purely by length, to give a 446 simple example. 448 In [tightness], Chatterjee, Menezes and Sarkar show an attack on SIV 449 within the multi-user setting. It is RECOMMENDED that concrete 450 instantiations intended for such use define a MAC_KEY_LENGTH of at 451 least 256 bits or describe other countermeasures. 453 The number of components passed to any invocation of S2V (including 454 the plaintext) must not exceed TAG_LEN - 1. For example, a 128-bit 455 PRF such as AES-CMAC should allow no more than 127 components. For 456 XChaCha20-HMAC-SHA256-SIV no more than 255 components should be 457 allowed. 459 6. References 461 6.1. Normative References 463 [I-D.arciszewski-xchacha] 464 Arciszewski, S., "XChaCha: eXtended-nonce ChaCha and 465 AEAD_XChaCha20_Poly1305", draft-arciszewski-xchacha-02 466 (work in progress), October 2018. 468 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 469 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 470 . 472 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 473 Authenticated Encryption Using the Advanced Encryption 474 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 475 2008, . 477 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 478 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 479 May 2017, . 481 6.2. Informative References 483 [DAE] Rogaway, P. and T. Shrimpton, "Deterministic 484 Authenticated-Encryption. A Provable-Security Treatment of 485 the Key-Wrap Problem.", IACR ePrint 2006/221, August 2007. 487 [HPL-98-135] 488 Seroussi, G., "Table of Low-Weight Binary Irreducible 489 Polynomials", HPL HPL-98-135, August 1998. 491 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 492 Hashing for Message Authentication", RFC 2104, 493 DOI 10.17487/RFC2104, February 1997, 494 . 496 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 497 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 498 2006, . 500 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 501 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 502 DOI 10.17487/RFC6234, May 2011, 503 . 505 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 506 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 507 . 509 [SIV] Rogaway, P. and T. Shrimpton, "The SIV Mode of Operation 510 for Deterministic Authenticated-Encryption (Key Wrap) and 511 Misuse-Resistant Nonce-Based Authenticated-Encryption.", 512 August 2007. 514 [SP800-38D] 515 Dworkin, M., "Recommendation for Block Cipher Modes of 516 Operation: Galois/Counter Mode (GCM) and GMAC.", NIST 517 Special Publication 800-38D, November 2007. 519 [tightness] 520 Chatterjee, S., Menezes, A., and P. Sarkar, "Another Look 521 at Tightness", Proceedings of SAC 2011, Lecture Notes in 522 Computer Science 7118, August 2011. 524 Appendix A. Test Vectors 526 A.1. Nonce-Based Authenticated Encryption Example 528 Input 529 ----- 530 Key: 531 000 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................ 532 016 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................ 533 032 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................ 534 048 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................ 536 Plaintext: 537 000 4c 61 64 69 65 73 20 61 6e 64 20 47 65 6e 74 6c Ladies and Gentl 538 016 65 6d 65 6e 20 6f 66 20 74 68 65 20 63 6c 61 73 emen of the clas 539 032 73 20 6f 66 20 27 39 39 3a 20 49 66 20 49 20 63 s of '99: If I c 540 048 6f 75 6c 64 20 6f 66 66 65 72 20 79 6f 75 20 6f ould offer you o 541 064 6e 6c 79 20 6f 6e 65 20 74 69 70 20 66 6f 72 20 nly one tip for 542 080 74 68 65 20 66 75 74 75 72 65 2c 20 73 75 6e 73 the future, suns 543 096 63 72 65 65 6e 20 77 6f 75 6c 64 20 62 65 20 69 creen would be i 544 112 74 2e t. 546 Nonce: 547 000 50 51 52 53 c0 c1 c2 c3 c4 c5 c6 c7 PQRS........ 549 IV: 550 000 40 41 42 43 44 45 46 47 @ABCDEFG 552 S2V[HMAC-SHA256] 553 ---------------- 554 HMAC-SHA256(): 555 318dcd14 73a3c69c 643eb853 e66eb357 556 c5bcb67b cd96ea83 4af2a3c6 f462136f 558 dbl(): 559 631b9a28 e7478d38 c87d70a7 ccdd66af 560 8b796cf7 9b2dd506 95e5478d e8c426de 562 HMAC-SHA256(AD1): 563 8b80c006 47844e6b 54617036 b1c09145 564 0ab8ad63 1e7ca653 326a8d4f e135dafb 566 xor: 567 e89b5a2e a0c3c353 9c1c0091 7d1df7ea 568 81c1c194 85517355 a78fcac2 09f1fc25 570 dbl(): 571 d136b45d 418786a7 38380122 fa3befd5 572 03838329 0aa2e6ab 4f1f9584 13e3fc6f 574 HMAC-SHA256(Nonce): 575 7c07875c 75e0021c 6f58cbd2 052675e3 576 2690107a 1f618e40 34b79efc d23d3a57 578 xor: 579 ad313301 346784bb 5760caf0 ff1d9a36 580 25139353 15c368eb 7ba80b78 c1dec638 582 xorend: 583 4c616469 65732061 6e642047 656e746c 584 656d656e 206f6620 74686520 636c6173 585 73206f66 20273939 3a204966 20492063 586 6f756c64 206f6666 65722079 6f75206f 587 6e6c7920 6f6e6520 74697020 666f7220 588 7468c811 55744012 f6de7b40 b985916e 589 f9444076 fd7362ac 1d871f88 691de1b7 590 b216 592 HMAC-SHA256(final): 593 28fdb5d4 d89e4860 11774606 5456a5df 594 924e8f4b 0f42bc77 a7415bd0 e0430628 596 XChaCha20 597 --------- 598 SIV: 599 28fdb5d4 d89e4860 11774606 5456a5df 600 924e8f4b 0f42bc77 602 Block Counter: 603 00000000 605 XChaCha20 Subkey: 606 70c5831f 36e439c1 b90e375e 2b98c3da 607 ef42de2e c120e1d1 2706af76 45381de1 609 XChaCha20 Nonce: 610 00000000 924e8f4b 0f42bc77 612 Output 613 ------ 614 T || C: 615 000 28 fd b5 d4 d8 9e 48 60 11 77 46 06 54 56 a5 df (.....H`.wF.TV.. 616 016 92 4e 8f 4b 0f 42 bc 77 a7 41 5b d0 e0 43 06 28 .N.K.B.w.A[..C.( 617 032 26 53 ea bf c6 ae cc 14 d0 46 aa 7e 3c 0b a2 8e &S.......F.~<... 618 048 fd 68 f3 d5 91 fc ac 6d b1 2e a2 3c f4 28 69 01 .h.....m...<.(i. 619 064 3b 2b e4 83 ce 08 8a f8 2d e4 29 3a 07 e2 40 07 ;+......-.):..@. 621 080 f3 7b d1 e3 78 81 a0 4b 11 5b 11 09 94 78 ae 34 .{..x..K.[...x.4 622 096 75 05 43 26 8e 57 0d 1f 27 f4 da fc 5a d8 71 97 u.C&.W..'...Z.q. 623 112 7f 08 b3 0b af df b5 3b 19 ef 34 2c d9 5c e7 91 .......;..4,.\.. 624 128 5c b4 f6 79 db 64 0d 8e c4 8a 06 b6 f3 ef 50 8c \..y.d........P. 625 144 53 30 S0 627 Author's Address 629 Neil Madden 630 ForgeRock 631 Broad Quay House 632 Prince Street 633 Bristol BS1 4DJ 634 United Kingdom 636 Email: neil.madden@forgerock.com