idnits 2.17.00 (12 Aug 2021) /tmp/idnits22338/draft-mcgrew-aead-aes-cbc-hmac-sha2-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3231 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2202 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft J. Foley 4 Intended status: Standards Track Cisco Systems 5 Expires: January 16, 2014 K. Paterson 6 Royal Holloway, University of 7 London 8 July 15, 2013 10 Authenticated Encryption with AES-CBC and HMAC-SHA 11 draft-mcgrew-aead-aes-cbc-hmac-sha2-02.txt 13 Abstract 15 This document specifies algorithms for authenticated encryption with 16 associated data (AEAD) that are based on the composition of the 17 Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC) 18 mode of operation for encryption, and the HMAC-SHA message 19 authentication code (MAC). 21 These are randomized encryption algorithms, and thus are suitable for 22 use with applications that cannot provide distinct nonces to each 23 invocation of the AEAD encrypt operation. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Conventions Used In This Document . . . . . . . . . . . . 4 62 2. CBC-HMAC algorithms . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.3. Length . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 8 67 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9 68 2.6. AEAD_AES_256_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9 69 2.7. AEAD_AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 10 70 2.8. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 10 71 2.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 12 73 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.1. AEAD_AES_128_CBC_HMAC_SHA256 . . . . . . . . . . . . . . . 15 76 5.2. AEAD_AES_192_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 16 77 5.3. AEAD_AES_256_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 17 78 5.4. AEAD_AES_256_CBC_HMAC_SHA512 . . . . . . . . . . . . . . . 19 79 5.5. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 20 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 85 Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 27 86 Appendix B. Alternative Interface for Legacy Encoding . . . . . . 28 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 89 1. Introduction 91 Authenticated Encryption (AE) [BN00] is a form of encryption that, in 92 addition to providing confidentiality for the plaintext that is 93 encrypted, provides a way to check its integrity and authenticity. 94 This combination of features can, when properly implemented, provide 95 security against adversaries who have access to full decryption 96 capabilities for ciphertexts of their choice, and access to full 97 encryption capabilities for plaintexts of their choice. The strong 98 form of security provided by AE is known to be robust against a large 99 class of adversaries for general purpose applications of AE, 100 including applications such as securing network communications over 101 untrusted networks. The strong security properties of AE stand in 102 contrast to the known weaknesses of "encryption only" forms of 103 encryption, see [B96][YHR04] [DP07] for examples. 105 Authenticated encryption with Associated Data, or AEAD [R02], adds 106 the ability to check the integrity and authenticity of some 107 associated data (sometimes called "additional authenticated data") 108 for which confidentiality is not required (or is not desirable). 109 While many approaches to building AEAD schemes are known, a 110 particularly simple, well-understood, and cryptographically strong 111 method is to employ an "Encrypt-then-MAC" construction. This 112 document defines new AEAD algorithms of this general type, using the 113 interface defined in [RFC5116], based on the Advanced Encryption 114 Standard (AES) [FIPS197] in the Cipher Block Chaining (CBC) mode of 115 operation [SP800-38] and HMAC using the Secure Hash Algorithm (SHA) 116 [FIPS186-2], with security levels of 128, 192, and 256 bits. 118 1.1. History 120 This subsection describes the revision history of this Internet 121 Draft. It should be removed by the RFC Editor before publication as 122 an RFC. 124 The changes of version 02 from version 01 are: 126 Added test cases for each of the five operational modes. 128 Added John as a coauthor. 130 Adds a legacy-style interface in Appendix B. 132 The changes of version 01 from version 00 are: 134 MIN_LEN_A and associated logic was eliminated. 136 Padding String (PS) typo corrected in Section 2.1. 138 Decryption Step 3 refers to the appropriate step in the encryption 139 process. 141 Random IV min-entropy clarified in Section 3. 143 HMAC keys are now the same size as the truncated output (128 or 144 256 bits). Previously, the HMAC keys were the same size as the 145 full hash output (256, 384, or 512 bits). 147 An algorithm based on the combination of AES-256 and HMAC-SHA-384 148 has been added, for compatibility with 149 draft-burgin-kerberos-aes-cbc-hmac-sha2. 151 The test cases in the previous version are no longer valid, and 152 thus have been removed. New test cases have been computed (and 153 the authors thank John Foley for this contribution) but have not 154 been included, pending confirmation from a second, independent 155 implementation. 157 1.2. Conventions Used In This Document 159 We use the following notational conventions. 161 CBC-ENC(X,P) denotes the CBC encryption of P using the cipher with 162 the key X 164 MAC(Y, M) denotes the application of the Message Authentication 165 Code (MAC) to the message M, using the key Y 167 The concatenation of two octet strings A and B is denoted as 168 A || B 170 len(X) denotes the number of bits in the string X, expressed as an 171 unsigned integer in network byte order. 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 2. CBC-HMAC algorithms 179 This section defines CBC-HMAC, an algorithm based on the the encrypt- 180 then-MAC method defined in Section 4.3 of [BN00]. That method 181 constructs a randomized AEAD algorithm out of a randomized cipher, 182 such as a block cipher mode of operation that uses a random 183 initialization vector, and a MAC. 185 Section 2.1 and Section 2.2 define the CBC-HMAC encryption and 186 decryption algorithms, without specifying the particular block cipher 187 or hash function to be used. Section 2.4, Section 2.5, Section 2.7, 188 and Section 2.8, define instances of CBC-HMAC that specify those 189 details. 191 2.1. Encryption 193 We briefly recall the encryption interface defined in Section 2 of 194 [RFC5116]. The AEAD encryption algorithm takes as input four octet 195 strings: a secret key K, a plaintext P, associated data A, and a 196 nonce N. An authenticated ciphertext value is provided as output. 197 The data in the plaintext are encrypted and authenticated, and the 198 associated data are authenticated, but not encrypted. 200 In CBC-HMAC, the nonce MUST be a zero-length string; a nonce is not 201 needed and is not used (see Section 4 for further background). 203 The CBC-HMAC encryption process is as follows, or uses an equivalent 204 set of steps: 206 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 207 input key K as follows. Each of these two keys is an octet 208 string. 210 MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in 211 order. 213 ENC_KEY consists of the final ENC_KEY_LEN octets of K, in 214 order. 216 Here we denote the number of octets in the MAC_KEY as 217 MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN; 218 the values of these parameters are specified by the AEAD 219 algorithms (in Section 2.4 and Section 2.5). The number of 220 octets in the input key K is the sum of MAC_KEY_LEN and 221 ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY 222 and ENC_KEY MUST NOT overlap. 224 2. An Initialization Vector (IV) is generated randomly or 225 pseudorandomly, as described in Section 3, for use in the cipher. 227 3. Prior to CBC encryption, the plaintext P is padded by appending a 228 padding string PS to that data, to ensure that len(P || PS) is a 229 multiple of 128, as is needed for the CBC operation. The value 230 of PS is as follows: 232 PS = 01 if len(P) mod 128 = 120, 233 PS = 0202 if len(P) mod 128 = 112, 234 PS = 030303 if len(P) mod 128 = 104, 235 PS = 04040404 if len(P) mod 128 = 96, 236 PS = 0505050505 if len(P) mod 128 = 88, 237 PS = 060606060606 if len(P) mod 128 = 80, 238 PS = 07070707070707 if len(P) mod 128 = 72, 239 PS = 0808080808080808 if len(P) mod 128 = 64, 240 PS = 090909090909090909 if len(P) mod 128 = 56, 241 PS = 0A0A0A0A0A0A0A0A0A0A if len(P) mod 128 = 48, 242 PS = 0B0B0B0B0B0B0B0B0B0B0B if len(P) mod 128 = 40, 243 PS = 0C0C0C0C0C0C0C0C0C0C0C0C if len(P) mod 128 = 32, 244 PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) mod 128 = 24, 245 PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) mod 128 = 16, 246 PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F if len(P) mod 128 = 8, 247 PS = 10101010101010101010101010101010 if len(P) mod 128 = 0. 249 Note that padding MUST be added to the plaintext; if the number 250 of bits in P is a multiple of 128, then 128 bits of padding will 251 be added. 253 4. The plaintext and appended padding P || PS is CBC encrypted using 254 ENC_KEY as the key, and the IV generated in the previous step. 255 We denote the ciphertext output from this step as S, and it MUST 256 include the IV as its prefix. 258 5. The octet string AL is equal to the number of bits in A expressed 259 as a 64-bit unsigned integer in network byte order. 261 6. A message authentication tag T is computed by applying HMAC 262 [RFC2104] to the following data, in order: 264 the associated data A, 266 the ciphertext S computed in the previous step, and 268 the octet string AL defined above. 270 The string MAC_KEY is used as the MAC key. We denote the output 271 of the MAC computed in this step as T. 273 7. The AEAD Ciphertext consists of the string S, with the string T 274 appended to it. This Ciphertext is returned as the output of the 275 AEAD encryption operation. 277 The encryption process can be illustrated as follows. Here P, A, and 278 C denote the AEAD plaintext, associated data, and ciphertext, 279 respectively. 281 MAC_KEY = initial MAC_KEY_LEN bytes of K 283 ENC_KEY = final ENC_KEY_LEN bytes of K 285 S = CBC-ENC(ENC_KEY, P || PS), 287 T = MAC(MAC_KEY, A || S || AL), 289 C = S || T. 291 2.2. Decryption 293 The authenticated decryption operation has four inputs: K, N, and A, 294 as defined above, and the Ciphertext C. It has only a single output, 295 either a plaintext value P or a special symbol FAIL that indicates 296 that the inputs are not authentic. The authenticated decryption 297 algorithm takes is as follows, or uses an equivalent set of steps: 299 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 300 input key K as in Step 1 of Section 2.1. 302 2. The final T_LEN octets are stripped from C. Here T_LEN denotes 303 the number of octets in the MAC, which is a fixed parameter of 304 the AEAD algorithm. We denote the initial octets of C as S, and 305 denote the final T_LEN octets as T. 307 3. The integrity and authenticity of A and C are checked by 308 computing HMAC with the inputs as in Step 6 of Section 2.1. The 309 value T, from the previous step, is compared to the HMAC output. 310 If those values are identical, then A and C are considered valid, 311 and processing is continued. Otherwise, all of the data used in 312 the MAC validation are discarded, and the AEAD decryption 313 operation returns an indication that it failed, and the operation 314 halts. 316 4. The value S is decrypted, using the initial 16 octets of the 317 ciphertext as the IV. The value ENC_KEY is used as the 318 decryption key. 320 5. The padding string is removed. Note that the length of PS can be 321 inferred from the value of the final octet of P || PS, if that 322 value is between 00 and 0F (hexadecimal). If the final octet has 323 a value outside that range, then all of the data used in the 324 processing of the message is zeroized and discarded, and the AEAD 325 decryption operation returns an indication that it failed, and 326 the operation halts. 328 6. The plaintext value is returned. 330 2.3. Length 332 The length of the ciphertext can be inferred from that of the 333 plaintext. The number L of octets in the ciphertext is given by 335 L = 16 * ( floor(M / 16) + 2) 337 where M denotes the number of octets in the plaintext, and the 338 function floor() rounds its argument down to the nearest integer. 339 This fact is useful to applications that need to reserve space for a 340 ciphertext within a message or data structure. 342 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 344 This algorithm is randomized and stateless. It is based on the CBC- 345 HMAC algorithm detailed above. It uses the HMAC message 346 authentication code [RFC2104] with the SHA-256 hash function 347 [FIPS186-2] to provide message authentication, with the HMAC output 348 truncated to 128 bits, corresponding to the HMAC-SHA-256-128 349 algorithm defined in [RFC4868]. For encryption, it uses AES in the 350 cipher block chaining (CBC) mode of operation as defined in Section 351 6.2 of [SP800-38], with the padding method used by PEM, PKCS, and 352 TLS. 354 The input key K is 32 octets long. 356 The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets. 358 The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16 359 octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by 360 stripping off the final 16 octets. Test cases for HMAC-SHA-256 are 361 provided in [RFC4231]. 363 The lengths of the inputs are restricted as follows: 365 K_LEN is 48 octets, 366 P_MAX is 2^64 - 1 octets, 368 A_MAX is 2^64 - 1 octets, 370 N_MIN is zero octets, 372 N_MAX is 2^64 octets, and 374 C_MAX is 2^64 + 47 octets. 376 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 378 AEAD_AES_192_CBC_HMAC_SHA_384 is based on 379 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 381 AES-192 is used instead of AES-128. 383 SHA-384 is used in HMAC instead of SHA-256. 385 ENC_KEY_LEN is 24 octets. 387 MAC_KEY_LEN is 24 octets. 389 The length of the input key K is 48 octets. 391 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 392 16 octets. 394 The input length restrictions are as for 395 AEAD_AES_CBC_128_HMAC_SHA_256. 397 2.6. AEAD_AES_256_CBC_HMAC_SHA_384 399 AEAD_AES_256_CBC_HMAC_SHA_384 is based on 400 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 402 AES-256 is used instead of AES-128. 404 SHA-384 is used in HMAC instead of SHA-256. 406 ENC_KEY_LEN is 32 octets. 408 MAC_KEY_LEN is 24 octets. 410 The length of the input key K is 56 octets. 412 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 413 16 octets. 415 The input length restrictions are as for 416 AEAD_AES_CBC_128_HMAC_SHA_256. 418 2.7. AEAD_AES_256_CBC_HMAC_SHA_512 420 AEAD_AES_256_CBC_HMAC_SHA_512 is based on 421 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 423 AES-256 is used instead of AES-128. 425 SHA-512 is used in HMAC instead of SHA-256. 427 ENC_KEY_LEN is 32 octets. 429 MAC_KEY_LEN is 32 octets. 431 The length of the input key K is 64 octets. 433 The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of 434 16 octets. 436 The input length restrictions are as for 437 AEAD_AES_CBC_128_HMAC_SHA_256. 439 2.8. AEAD_AES_128_CBC_HMAC_SHA1 441 AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256, 442 but with the following differences: 444 HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for HMAC- 445 SHA1 are provided in [RFC2202]. 447 MAC_KEY_LEN is 20 octets. 449 The length of the input key K is 36 octets. 451 The HMAC-SHA-1 value is truncated to T_LEN=12 octets instead of 16 452 octets. (Note that this matches the truncation used in 453 [RFC2404].) 455 The input length restrictions are as for 456 AEAD_AES_CBC_128_HMAC_SHA_256. 458 2.9. Summary 460 The parameters of the CBC-HMAC algorithms are summarized in the 461 following table. 463 +-------------------------------+-------------+-------------+-------+ 464 | algorithm | ENC_KEY_LEN | MAC_KEY_LEN | T_LEN | 465 +-------------------------------+-------------+-------------+-------+ 466 | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 16 | 16 | 467 | | | | | 468 | AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 24 | 24 | 469 | | | | | 470 | AEAD_AES_256_CBC_HMAC_SHA_384 | 32 | 24 | 24 | 471 | | | | | 472 | AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 32 | 32 | 473 | | | | | 474 | AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 20 | 12 | 475 +-------------------------------+-------------+-------------+-------+ 477 3. Randomness Requirements 479 Each IV MUST be unpredictable to the adversary. It MAY be chosen 480 uniformly at random, in which case it SHOULD have min-entropy within 481 one bit of len(IV). Alternatively, it MAY be generated 482 pseudorandomly, using any method that provides the same level of 483 security as the block cipher in use. However, if a pseudorandom 484 method is used, that method MUST NOT make use of ENC_KEY or MAC_KEY. 486 SP 800-90 describes suitable pseudorandom generators. 488 4. Rationale 490 The CBC-HMAC AEAD algorithms defined in this note are intended to be 491 useful in the following applications: 493 systems that have the CBC and HMAC algorithms available, but do 494 not have dedicated AEAD algorithms such as GCM or CCM [RFC5116], 496 scenarios in which AEAD is useful, but it is undesirable to have 497 the application maintain a deterministic nonce; see Section 4 of 498 [RFC5116] for more background, 500 new systems, such as JSON Cryptography and W3C Web Crypto, which 501 can omit unauthenticated symmetric encryption altogether by 502 providing CBC and HMAC through an AEAD interface. 504 These algorithms are not intended to replace existing uses of AES-CBC 505 and HMAC, except in those circumstances where the existing use is not 506 sufficiently secure or sufficiently general-purpose. 508 The length of the associated data input A is included in the HMAC 509 input to ensure that the encrypter and the decrypter have the same 510 understanding of that length. Because of this, an attacker cannot 511 trick the receiver into interpreting the initial bytes of C as the 512 final bytes of A, or vice-versa. 514 The padding method used in this note is based on that of Privacy 515 Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS), 516 because it is implemented in many environments. 518 The encrypt-then-MAC method is used because of its better security 519 properties. It would be possible to define AEAD algorithms based on 520 the MAC-encode-encrypt (MEE) method that is used by the Transport 521 Layer Security (TLS) protocol [RFC5246]. That alternative would 522 provide more code-sharing opportunities for an implementation that is 523 co-resident with a TLS implementation. It is possible (but tricky) 524 to implement MEE in a way that provides good security, as was shown 525 in [PRS11]. But its negatives outweigh its positives; its security 526 is inadequate for some parameter choices, and it has proven to be 527 difficult to implement in a way that resists padding oracle and 528 related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For 529 future uses of CBC and HMAC, it is better to use encrypt-then-MAC." 531 This note uses HMAC-SHA1 because it is widely deployed and is 532 adequately secure, and HMAC-SHA-2, because it is used in newer 533 standards and is expected to become widely deployed. It has been 534 recently announced that the SHA-3 standard will be based on KECCAK, 535 but this note does not incorporate that hash function. To do so 536 would be to speculate on the final form of the SHA-3 standard. In 537 addition, while the use of KECCAK as a hash function is 538 straightforward, there are multiple options for its use in 539 authenticated encryption. The focus of this note is the definition 540 of AEAD algorithms based on currently used cryptographic mechanisms, 541 so SHA-3 is out of scope. 543 5. Test Cases 545 5.1. AEAD_AES_128_CBC_HMAC_SHA256 547 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 549 ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 551 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 552 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 553 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 554 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 555 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 556 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 557 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 558 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 560 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 562 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 563 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 564 4b 65 72 63 6b 68 6f 66 66 73 566 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 568 AL = 00 00 00 00 00 00 01 50 570 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 571 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 572 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 573 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 574 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 575 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 576 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 577 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 578 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 579 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 581 T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 582 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 583 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 584 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 585 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 586 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 587 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 588 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 589 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 590 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 591 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 592 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 594 5.2. AEAD_AES_192_CBC_HMAC_SHA384 596 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 597 10 11 12 13 14 15 16 17 599 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 600 28 29 2a 2b 2c 2d 2e 2f 602 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 603 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 604 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 605 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 606 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 607 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 608 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 609 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 611 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 613 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 614 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 615 4b 65 72 63 6b 68 6f 66 66 73 617 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 619 AL = 00 00 00 00 00 00 01 50 620 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 621 ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 622 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 623 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 624 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 625 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 626 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 627 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 628 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 629 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 631 T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 632 75 16 80 39 cc c7 33 d7 634 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 635 ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 636 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 637 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 638 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 639 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 640 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 641 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 642 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 643 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 644 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 645 75 16 80 39 cc c7 33 d7 647 5.3. AEAD_AES_256_CBC_HMAC_SHA384 649 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 650 10 11 12 13 14 15 16 17 652 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 653 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 655 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 656 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 657 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 658 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 659 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 660 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 661 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 662 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 664 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 666 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 667 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 668 4b 65 72 63 6b 68 6f 66 66 73 670 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 672 AL = 00 00 00 00 00 00 01 50 674 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 675 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 676 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 677 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 678 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 679 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 680 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 681 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 682 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 683 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 685 T = dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 686 7f 1e 9a 54 1d 9c 23 e7 688 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 689 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 690 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 691 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 692 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 693 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 694 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 695 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 696 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 697 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 698 dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 699 7f 1e 9a 54 1d 9c 23 e7 701 5.4. AEAD_AES_256_CBC_HMAC_SHA512 703 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 704 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 706 ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 707 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 709 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 710 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 711 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 712 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 713 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 714 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 715 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 716 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 718 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 720 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 721 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 722 4b 65 72 63 6b 68 6f 66 66 73 724 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 726 AL = 00 00 00 00 00 00 01 50 728 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 729 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 730 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 731 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 732 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 733 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 734 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 735 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 736 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 737 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 739 T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 740 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 742 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 743 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 744 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 745 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 746 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 747 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 748 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 749 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 750 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 751 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 752 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 753 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 755 5.5. AEAD_AES_128_CBC_HMAC_SHA1 757 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 758 10 11 12 13 760 ENC_KEY = 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 762 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 763 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 764 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 765 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 766 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 767 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 768 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 769 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 771 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 773 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 774 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 775 4b 65 72 63 6b 68 6f 66 66 73 777 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 779 AL = 00 00 00 00 00 00 01 50 780 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 781 c6 3a ec 99 63 f4 ff 33 a8 5e 56 4c d0 5f 92 40 782 0a 71 fe 98 bc b3 39 ac c1 d7 8c 92 b3 aa 6a 32 783 14 60 d2 ae ce c4 3b 78 4b 3b 08 b8 30 be 52 91 784 dc 04 00 b8 af c6 cd 1c 84 75 76 46 32 a8 36 05 785 01 e5 31 9a 12 81 27 ae 4b 0e aa 9b 2f 97 ea 6d 786 f0 22 00 d6 f6 8c 74 3b 79 4e d5 d6 13 9e 84 c4 787 cb 91 9e bb 8d 82 56 09 8b 63 85 e4 14 76 c4 16 788 cf c8 5a 46 fa c4 0e a4 50 d2 b4 c0 fd 7e 03 dc 789 d8 33 c8 c3 d2 13 5f 0d 10 9b d2 31 80 8b b3 fd 791 T = 4d 9d f6 8e 54 f7 d9 7e 91 4b 4a 9d 793 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 794 c6 3a ec 99 63 f4 ff 33 a8 5e 56 4c d0 5f 92 40 795 0a 71 fe 98 bc b3 39 ac c1 d7 8c 92 b3 aa 6a 32 796 14 60 d2 ae ce c4 3b 78 4b 3b 08 b8 30 be 52 91 797 dc 04 00 b8 af c6 cd 1c 84 75 76 46 32 a8 36 05 798 01 e5 31 9a 12 81 27 ae 4b 0e aa 9b 2f 97 ea 6d 799 f0 22 00 d6 f6 8c 74 3b 79 4e d5 d6 13 9e 84 c4 800 cb 91 9e bb 8d 82 56 09 8b 63 85 e4 14 76 c4 16 801 cf c8 5a 46 fa c4 0e a4 50 d2 b4 c0 fd 7e 03 dc 802 d8 33 c8 c3 d2 13 5f 0d 10 9b d2 31 80 8b b3 fd 803 4d 9d f6 8e 54 f7 d9 7e 91 4b 4a 9d 805 6. Security Considerations 807 Comments on this version are requested and should be forwarded to the 808 IRTF Crypto Forum Research Group (CFRG). An earlier version of this 809 document benefited from some review from that group. 811 The algorithms defined in this document use the generic composition 812 of CBC encryption with HMAC authentication, with the encrypt-then-MAC 813 method defined in Section 4.3 of [BN00]. This method has sound and 814 well-understood security properties; for details, please see that 815 reference. Note that HMAC is a good pseudorandom function and is 816 "strongly unforgeable", and thus meets all of the security goals of 817 that reference. 819 During the decryption process, the inputs A and C are mapped into the 820 input of the HMAC algorithm. It is essential for security that each 821 possible input to the MAC algorithm corresponds unambiguously to 822 exactly one pair (A, C) of possible inputs. The fact that this 823 property holds can be verified as follows. The HMAC input is X = A 824 || C || len(A). Let (A,C) and (A',C') denote two distinct input 825 pairs, in which either 1) A != A' and C = C', 2) C != C and A = A', 826 or 3) both inequalities hold. We also let X' = A' || C' || len(A'). 827 In cases 1 and 2, X != X' follows immediately. In case 3, if len(A) 828 != len(A'), then X != X' directly. If len(A) = len(A'), then X != X 829 follows from the fact that the initial len(A) bits of X and X' must 830 be distinct. 832 There are security benefits to providing both confidentiality and 833 authentication in a single atomic operation, as done in this note. 834 This tight binding prevents subtle attacks such as the padding oracle 835 attack. 837 As with any block cipher mode of operation, the security of AES-CBC 838 degrades as the amount of data that is process increases. Each fixed 839 key value SHOULD NOT be used to protect more than 2^64 bytes of data. 840 This limit ensures that the AES-CBC algorithm will stay under the 841 birthday bound, i.e. because of the limit, it is unlikely that there 842 will be two AES plaintext inputs that are equal. (If this event 843 occurs, information about the colliding plaintexts is leaked, so it 844 is desirable to bound the amount of plaintext processed in order to 845 make it unlikely.) 847 7. Acknowledgements 849 Thanks are due to Matt Miller for his constructive feedback, and 850 Kelly Burgin, Michael Peck, and Mike Jones for their suggestions and 851 help. 853 8. References 855 8.1. Normative References 857 [FIPS186-2] 858 "FIPS 180-2: Secure Hash Standard,", Federal Information 859 Processing Standard 860 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 862 [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal 863 Information Processing Standard 864 (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. 866 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 867 Hashing for Message Authentication", RFC 2104, 868 February 1997. 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 874 SHA-1", RFC 2202, September 1997. 876 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 877 ESP and AH", RFC 2404, November 1998. 879 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 880 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 881 RFC 4231, December 2005. 883 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 884 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 886 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 887 Encryption", RFC 5116, January 2008. 889 8.2. Informative References 891 [AP12] Paterson, K. and N. AlFardan, "Plaintext-Recovery Attacks 892 Against Datagram TLS", Network and Distributed System 893 Security Symposium (NDSS) 894 2012 http://www.isg.rhul.ac.uk/~kp/dtls.pdf, 2012. 896 [B96] Bellovin, S., "Problem areas for the IP security 897 protocols", Proceedings of the Sixth Usenix Unix Security 898 Symposium https://www.cs.columbia.edu/~smb/papers/ 899 badesp.pdf, 1996. 901 [BN00] "Authenticated encryption: Relations among notions and 902 analysis of the generic composition paradigm", Proceedings 903 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 904 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. 906 [CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux, 907 "Password Interception in a SSL/TLS Channel", CRYPT0 908 2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps, 909 2003. 911 [DP07] Paterson, K. and J. Degabriele, "Attacking the IPsec 912 Standards in Encryption-only Configurations", IEEE 913 Symposium on Privacy and 914 Security http://eprint.iacr.org/2007/125.pdf, 2007. 916 [DP10] Paterson, K. and J. Degabriele, "On the (in)security of 917 IPsec in MAC-then-encrypt configurations.", ACM Conference 918 on Computer and Communications Security (ACM CCS) 919 2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf, 920 2010. 922 [M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 923 Problems and Countermeasures", Web 924 Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004. 926 [PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 927 Does Matter: Attacks and Proofs for the TLS Record 928 Protocol", IEEE Symposium on Security and Privacy 929 2012 http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf, 930 January 2012. 932 [R02] "Authenticated encryption with Associated-Data", 933 Proceedings of the 2002 ACM Conference on Computer and 934 Communication Security (CCS'02), pp. 98-107, ACM Press, 935 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. 937 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 938 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 940 [SP800-38] 941 Dworkin, M., "NIST Special Publication 800-38: 942 Recommendation for Block Cipher Modes of Operation", U.S. 943 National Institue of Standards and Technology http:// 944 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 946 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 947 Applications to SSL, IPSEC, WTLS ....", EUROCRYPT 2002 htt 948 p://lasecwww.epfl.ch/php_code/publications/ 949 search.php?ref=Vau02a, 2002. 951 [YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of 952 Unauthenticated Encryption: Kerberos Version 4", Network 953 and Distributed Security Symposium (NDSS) 954 2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf, 955 2004. 957 Appendix A. CBC Encryption and Decryption 959 The Cipher Block Chaining (CBC) mode of operation is defined in 960 [SP800-38]. This section recalls how that mode works, for the 961 convenience of the reader. The following notation is used: 963 K denotes the key of the underlying block cipher, 965 The function CIPHER(K, P) denotes the encryption of the block P 966 with the block cipher, 968 The function CIPHER-INV(K, C) denotes the decryption of the block 969 C with the block cipher; this is the inverse operation of 970 CIPHER(), and CIPHER-INV(K, CIPHER(K, P)) = P for all P and all K. 972 P_1, P_2, ... , P_n denotes the sequence of plaintext blocks, 973 where each block contains exactly the number of bits that the 974 block cipher accepts as its plaintext input, 976 C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext 977 blocks, where each block contains exactly the number of bits that 978 the block cipher accepts as its plaintext input, 980 P_i and C_i denote the ith blocks of the plaintext, and 982 IV denotes the initialization vector, which contains exactly the 983 number of bits that the block cipher accepts as its plaintext 984 input. 986 The CBC encryption operation (denoted as CBC-ENC) takes as input a 987 sequence of n plaintext blocks and produces a sequence of n + 1 988 ciphertext blocks as follows: 990 IV = random 991 C_i = / IV if i=0, 992 \ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n. 994 The IV MUST be generated using a uniformly random process, or a 995 pseudorandom process with a cryptographic strength equivalent to that 996 of the underlying block cipher. It MUST NOT be predictable to an 997 attacker; in particular, it MUST NOT be set to the value of any 998 previous ciphertext blocks. 1000 The CBC decryption operation (denoted as CBC-DEC) takes as input a 1001 sequence of m ciphertext blocks and produces a sequence of m-1 1002 plaintext blocks as follows: 1004 P_i = CIPHER-INV(K, P_1 XOR IV) for i=1, 2, ... , n. 1006 Appendix B. Alternative Interface for Legacy Encoding 1008 In some scenarios, cryptographic data such as the ciphertext, 1009 initialization vector, and message authentication tag are encoded 1010 separately. To allow for the use of the algorithms defined in this 1011 document in such scenarios, this appendix describes an interface in 1012 which those data elements are discrete. New implementations SHOULD 1013 NOT use this interface, because it is incompatible with other 1014 authenticated encryption methods and is more complex; however, it MAY 1015 be useful in scenarios in which the separate encoding is already in 1016 use. 1018 The alternative interface is as follows. The inputs to the 1019 encryption operation the same as those defined in Section 2.1 (the 1020 secret key K, the plaintext P, the associated data A). The outputs 1021 of the encryption operation are: 1023 the initialization vector IV as defined in Appendix A, 1025 the ciphertext C, as defined in Appendix A, and 1027 the message authentication tag T, as defined in Section 2.1. 1029 The inputs to the decryption operation are: 1031 the initialization vector IV as defined in Appendix A, 1033 the ciphertext C, as defined in Appendix A, and 1035 the message authentication tag T, as defined in Section 2.1. 1037 The output of the decryption operation is the same as that defined in 1038 Section 2.2 (either a plaintext value P or a special symbol FAIL that 1039 indicates that the inputs are not authentic). 1041 All processing other than the encoding and decoding of IV, C, and T 1042 is done as defined above. In particular, the IV is an output of the 1043 encryption operation, rather than an input. 1045 Authors' Addresses 1047 David McGrew 1048 Cisco Systems 1049 13600 Dulles Technology Drive 1050 Herndon, VA 20171 1051 US 1053 Email: mcgrew@cisco.com 1054 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1056 John Foley 1057 Cisco Systems 1058 7025-2 Kit Creek Road 1059 Research Triangle Park, NC 14987 1060 US 1062 Email: foleyj@cisco.com 1064 Kenny Paterson 1065 Royal Holloway, University of London 1066 TW20 0EX 1067 Egham, Surrey TW20 0EX 1068 UK 1070 Phone: +44 1784 414393 1071 Email: Kenny.Paterson@rhul.ac.uk 1072 URI: http://www.isg.rhul.ac.uk/~kp/