idnits 2.17.1 draft-mcgrew-aead-aes-cbc-hmac-sha2-01.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 (October 22, 2012) is 4197 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 Cisco Systems, Inc. 4 Intended status: Standards Track K. Paterson 5 Expires: April 25, 2013 Royal Holloway, University of 6 London 7 October 22, 2012 9 Authenticated Encryption with AES-CBC and HMAC-SHA 10 draft-mcgrew-aead-aes-cbc-hmac-sha2-01.txt 12 Abstract 14 This document specifies algorithms for authenticated encryption with 15 associated data (AEAD) that are based on the composition of the 16 Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC) 17 mode of operation for encryption, and the HMAC-SHA message 18 authentication code (MAC). 20 These are randomized encryption algorithms, and thus are suitable for 21 use with applications that cannot provide distinct nonces to each 22 invocation of the AEAD encrypt operation. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Conventions Used In This Document . . . . . . . . . . . . 4 61 2. CBC-HMAC algorithms . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3. Length . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 8 66 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9 67 2.6. AEAD_AES_256_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9 68 2.7. AEAD_AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 10 69 2.8. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 10 70 2.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 12 72 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 79 Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 Authenticated Encryption (AE) [BN00] is a form of encryption that, in 85 addition to providing confidentiality for the plaintext that is 86 encrypted, provides a way to check its integrity and authenticity. 87 This combination of features can, when properly implemented, provide 88 security against adversaries who have access to full decryption 89 capabilities for ciphertexts of their choice, and access to full 90 encryption capabilities for plaintexts of their choice. The strong 91 form of security provided by AE is known to robust against a large 92 class of adversaries for general purpose applications of AE, 93 including applications such as securing network communications over 94 untrusted networks. The strong security properties of AE stand in 95 contrast to the known weaknesses of "encryption only" forms of 96 encryption, see [B96][YHR04] [DP07] for examples. 98 Authenticated encryption with Associated Data, or AEAD [R02], adds 99 the ability to check the integrity and authenticity of some 100 associated data (sometimes called "additional authenticated data") 101 for which confidentiality is not required (or is not desirable). 102 While many approaches to building AEAD schemes are known, a 103 particularly simple, well-understood, and cryptographically strong 104 method is to employ an "Encrypt-then-MAC" construction. This 105 document defines new AEAD algorithms of this general type, using the 106 interface defined in [RFC5116], based on the Advanced Encryption 107 Standard (AES) [FIPS197] in the Cipher Block Chaining (CBC) mode of 108 operation [SP800-38] and HMAC using the Secure Hash Algorithm (SHA) 109 [FIPS186-2], with security levels of 128, 192, and 256 bits. 111 1.1. History 113 This subsection describes the revision history of this Internet 114 Draft. It should be removed by the RFC Editor before publication as 115 an RFC. 117 The changes of version 01 from version 00 are: 119 MIN_LEN_A and associated logic was eliminated. 121 Padding String (PS) typo corrected in Section 2.1. 123 Decryption Step 3 refers to the appropriate step in the encryption 124 process. 126 Random IV min-entropy clarified in Section 3. 128 HMAC keys are now the same size as the truncated output (128 or 129 256 bits). Previously, the HMAC keys were the same size as the 130 full hash output (256, 384, or 512 bits). 132 An algorithm based on the combination of AES-256 and HMAC-SHA-384 133 has been added, for compatibility with 134 draft-burgin-kerberos-aes-cbc-hmac-sha2. 136 The test cases in the previous version are no longer valid, and 137 thus have been removed. New test cases have been computed (and 138 the authors thank John Foley for this contribution) but have not 139 been included, pending confirmation from a second, independent 140 implementation. 142 1.2. Conventions Used In This Document 144 We use the following notational conventions. 146 CBC-ENC(X,P) denotes the CBC encryption of P using the cipher with 147 the key X 149 MAC(Y, M) denotes the application of the Message Authentication 150 Code (MAC) to the message M, using the key Y 152 The concatenation of two octet strings A and B is denoted as 153 A || B 155 len(X) denotes the number of bits in the string X, expressed as an 156 unsigned integer in network byte order. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. CBC-HMAC algorithms 164 This section defines CBC-HMAC, an algorithm based on the the encrypt- 165 then-MAC method defined in Section 4.3 of [BN00]. That method 166 constructs a randomized AEAD algorithm out of a randomized cipher, 167 such as a block cipher mode of operation that uses a random 168 initialization vector, and a MAC. 170 Section 2.1 and Section 2.2 define the CBC-HMAC encryption and 171 decryption algorithms, without specifying the particular block cipher 172 or hash function to be used. Section 2.4, Section 2.5, Section 2.7, 173 and Section 2.8, define instances of CBC-HMAC that specify those 174 details. 176 2.1. Encryption 178 We briefly recall the encryption interface defined in Section 2 of 179 [RFC5116]. The AEAD encryption algorithm takes as input four octet 180 strings: a secret key K, a plaintext P, associated data A, and a 181 nonce N. An authenticated ciphertext value is provided as output. 182 The data in the plaintext are encrypted and authenticated, and the 183 associated data are authenticated, but not encrypted. 185 In CBC-HMAC, the nonce MUST be a zero-length string; a nonce is not 186 needed and is not used (see Section 4 for further background). 188 The CBC-HMAC encryption process is as follows, or uses an equivalent 189 set of steps: 191 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 192 input key K as follows. Each of these two keys is an octet 193 string. 195 MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in 196 order. 198 ENC_KEY consists of the final ENC_KEY_LEN octets of K, in 199 order. 201 Here we denote the number of octets in the MAC_KEY as 202 MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN; 203 the values of these parameters are specified by the AEAD 204 algorithms (in Section 2.4 and Section 2.5). The number of 205 octets in the input key K is the sum of MAC_KEY_LEN and 206 ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY 207 and ENC_KEY MUST NOT overlap. 209 2. An Initialization Vector (IV) is generated randomly or 210 pseudorandomly, as described in Section 3, for use in the cipher. 212 3. Prior to CBC encryption, the plaintext P is padded by appending a 213 padding string PS to that data, to ensure that len(P || PS) is a 214 multiple of 128, as is needed for the CBC operation. The value 215 of PS is as follows: 217 PS = 01 if len(P) mod 128 = 120, 218 PS = 0202 if len(P) mod 128 = 112, 219 PS = 030303 if len(P) mod 128 = 104, 220 PS = 04040404 if len(P) mod 128 = 96, 221 PS = 0505050505 if len(P) mod 128 = 88, 222 PS = 060606060606 if len(P) mod 128 = 80, 223 PS = 07070707070707 if len(P) mod 128 = 72, 224 PS = 0808080808080808 if len(P) mod 128 = 64, 225 PS = 090909090909090909 if len(P) mod 128 = 56, 226 PS = 0A0A0A0A0A0A0A0A0A0A if len(P) mod 128 = 48, 227 PS = 0B0B0B0B0B0B0B0B0B0B0B if len(P) mod 128 = 40, 228 PS = 0C0C0C0C0C0C0C0C0C0C0C0C if len(P) mod 128 = 32, 229 PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) mod 128 = 24, 230 PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) mod 128 = 16, 231 PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F if len(P) mod 128 = 8, 232 PS = 10101010101010101010101010101010 if len(P) mod 128 = 0. 234 Note that padding MUST be added to the plaintext; if the number 235 of bits in P is a multiple of 128, then 128 bits of padding will 236 be added. 238 4. The plaintext and appended padding P || PS is CBC encrypted using 239 ENC_KEY as the key, and the IV generated in the previous step. 240 We denote the ciphertext output from this step as S, and it MUST 241 include the IV as its prefix. 243 5. The octet string AL is equal to the number of bits in A expressed 244 as a 64-bit unsigned integer in network byte order. 246 6. A message authentication tag T is computed by applying HMAC 247 [RFC2104] to the following data, in order: 249 the associated data A, 251 the ciphertext S computed in the previous step, and 253 the octet string AL defined above. 255 The string MAC_KEY is used as the MAC key. We denote the output 256 of the MAC computed in this step as T. 258 7. The AEAD Ciphertext consists of the string S, with the string T 259 appended to it. This Ciphertext is returned as the output of the 260 AEAD encryption operation. 262 The encryption process can be illustrated as follows. Here P, A, and 263 C denote the AEAD plaintext, associated data, and ciphertext, 264 respectively. 266 MAC_KEY = initial MAC_KEY_LEN bytes of K 268 ENC_KEY = final ENC_KEY_LEN bytes of K 270 S = CBC-ENC(ENC_KEY, P || PS), 272 T = MAC(MAC_KEY, A || S || AL), 274 C = S || T. 276 2.2. Decryption 278 The authenticated decryption operation has four inputs: K, N, and A, 279 as defined above, and the Ciphertext C. It has only a single output, 280 either a plaintext value P or a special symbol FAIL that indicates 281 that the inputs are not authentic. The authenticated decryption 282 algorithm takes is as follows, or uses an equivalent set of steps: 284 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 285 input key K as in Step 1 of Section 2.1. 287 2. The final T_LEN octets are stripped from C. Here T_LEN denotes 288 the number of octets in the MAC, which is a fixed parameter of 289 the AEAD algorithm. We denote the initial octets of C as S, and 290 denote the final T_LEN octets as T. 292 3. The integrity and authenticity of A and C are checked by 293 computing HMAC with the inputs as in Step 6 of Section 2.1. The 294 value T, from the previous step, is compared to the HMAC output. 295 If those values are identical, then A and C are considered valid, 296 and processing is continued. Otherwise, all of the data used in 297 the MAC validation are discarded, and the AEAD decryption 298 operation returns an indication that it failed, and the operation 299 halts. 301 4. The value S is decrypted, using the initial 16 octets of the 302 ciphertext as the IV. The value ENC_KEY is used as the 303 decryption key. 305 5. The padding string is removed. Note that the length of PS can be 306 inferred from the value of the final octet of P || PS, if that 307 value is between 00 and 0F (hexadecimal). If the final octet has 308 a value outside that range, then all of the data used in the 309 processing of the message is zeroized and discarded, and the AEAD 310 decryption operation returns an indication that it failed, and 311 the operation halts. 313 6. The plaintext value is returned. 315 2.3. Length 317 The length of the ciphertext can be inferred from that of the 318 plaintext. The number L of octets in the ciphertext is given by 320 L = 16 * ( floor(M / 16) + 2) 322 where M denotes the number of octets in the plaintext, and the 323 function floor() rounds its argument down to the nearest integer. 324 This fact is useful to applications that need to reserve space for a 325 ciphertext within a message or data structure. 327 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 329 This algorithm is randomized and stateless. It is based on the CBC- 330 HMAC algorithm detailed above. It uses the HMAC message 331 authentication code [RFC2104] with the SHA-256 hash function 332 [FIPS186-2] to provide message authentication, with the HMAC output 333 truncated to 128 bits, corresponding to the HMAC-SHA-256-128 334 algorithm defined in [RFC4868]. For encryption, it uses AES in the 335 cipher block chaining (CBC) mode of operation as defined in Section 336 6.2 of [SP800-38], with the padding method used by PEM, PKCS, and 337 TLS. 339 The input key K is 32 octets long. 341 The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets. 343 The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16 344 octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by 345 stripping off the final 16 octets. Test cases for HMAC-SHA-256 are 346 provided in [RFC4231]. 348 The lengths of the inputs are restricted as follows: 350 K_LEN is 48 octets, 351 P_MAX is 2^64 - 1 octets, 353 A_MAX is 2^64 - 1 octets, 355 N_MIN is zero octets, 357 N_MAX is 2^64 octets, and 359 C_MAX is 2^64 + 47 octets. 361 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 363 AEAD_AES_192_CBC_HMAC_SHA_384 is based on 364 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 366 AES-192 is used instead of AES-128. 368 SHA-384 is used in HMAC instead of SHA-256. 370 ENC_KEY_LEN is 24 octets. 372 MAC_KEY_LEN is 24 octets. 374 The length of the input key K is 48 octets. 376 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 377 16 octets. 379 The input length restrictions are as for 380 AEAD_AES_CBC_128_HMAC_SHA_256. 382 2.6. AEAD_AES_256_CBC_HMAC_SHA_384 384 AEAD_AES_256_CBC_HMAC_SHA_384 is based on 385 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 387 AES-256 is used instead of AES-128. 389 SHA-384 is used in HMAC instead of SHA-256. 391 ENC_KEY_LEN is 32 octets. 393 MAC_KEY_LEN is 24 octets. 395 The length of the input key K is 56 octets. 397 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 398 16 octets. 400 The input length restrictions are as for 401 AEAD_AES_CBC_128_HMAC_SHA_256. 403 2.7. AEAD_AES_256_CBC_HMAC_SHA_512 405 AEAD_AES_256_CBC_HMAC_SHA_512 is based on 406 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 408 AES-256 is used instead of AES-128. 410 SHA-512 is used in HMAC instead of SHA-256. 412 ENC_KEY_LEN is 32 octets. 414 MAC_KEY_LEN is 32 octets. 416 The length of the input key K is 64 octets. 418 The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of 419 16 octets. 421 The input length restrictions are as for 422 AEAD_AES_CBC_128_HMAC_SHA_256. 424 2.8. AEAD_AES_128_CBC_HMAC_SHA1 426 AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256, 427 but with the following differences: 429 HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for HMAC- 430 SHA1 are provided in [RFC2202]. 432 MAC_KEY_LEN is 20 octets. 434 The length of the input key K is 36 octets. 436 The HMAC-SHA-1 value is truncated to T_LEN=12 octets instead of 16 437 octets. (Note that this matches the truncation used in 438 [RFC2404].) 440 The input length restrictions are as for 441 AEAD_AES_CBC_128_HMAC_SHA_256. 443 2.9. Summary 445 The parameters of the CBC-HMAC algorithms are summarized in the 446 following table. 448 +-------------------------------+-------------+-------------+-------+ 449 | algorithm | ENC_KEY_LEN | MAC_KEY_LEN | T_LEN | 450 +-------------------------------+-------------+-------------+-------+ 451 | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 16 | 16 | 452 | | | | | 453 | AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 24 | 24 | 454 | | | | | 455 | AEAD_AES_256_CBC_HMAC_SHA_384 | 32 | 24 | 24 | 456 | | | | | 457 | AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 32 | 32 | 458 | | | | | 459 | AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 20 | 12 | 460 +-------------------------------+-------------+-------------+-------+ 462 3. Randomness Requirements 464 Each IV MUST be unpredictable to the adversary. It MAY be chosen 465 uniformly at random, in which case it SHOULD have min-entropy within 466 one bit of len(IV). Alternatively, it MAY be generated 467 pseudorandomly, using any method that provides the same level of 468 security as the block cipher in use. However, if a pseudorandom 469 method is used, that method MUST NOT make use of ENC_KEY or MAC_KEY. 471 SP 800-90 describes suitable pseudorandom generators. 473 4. Rationale 475 The CBC-HMAC AEAD algorithms defined in this note are intended to be 476 useful in the following applications: 478 systems that have the CBC and HMAC algorithms available, but do 479 not have dedicated AEAD algorithms such as GCM or CCM [RFC5116], 481 scenarios in which AEAD is useful, but it is undesirable to have 482 the applicaiton maintain a deterministic nonce; see Section 4 of 483 [RFC5116] for more background, 485 new systems, such as JSON Cryptography and W3C Web Crypto, which 486 can omit unauthenticated symmetric encryption altogether by 487 providing CBC and HMAC through an AEAD interface. 489 These algorithms are not intended to replace existing uses of AES-CBC 490 and HMAC, except in those circumstances where the existing use is not 491 sufficiently secure or sufficiently general-purpose. 493 The length of the associated data input A is included in the HMAC 494 input to ensure that the encrypter and the decrypter have the same 495 understanding of that length. Because of this, an attacker cannot 496 trick the receiver into interpreting the initial bytes of C as the 497 final bytes of A, or vice-versa. 499 The padding method used in this note is based on that of Privacy 500 Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS), 501 because it is implemented in many environments. 503 The encrypt-then-MAC method is used because of its better security 504 properties. It would be possible to define AEAD algorithms based on 505 the MAC-encode-encrypt (MEE) method that is used by the Transport 506 Layer Security (TLS) protocol [RFC5246]. That alternative would 507 provide more code-sharing opportunities for an implementation that is 508 co-resident with a TLS implementation. It is possible (but tricky) 509 to implement MEE in a way that provides good security, as was shown 510 in [PRS11]. But its negatives outweigh its positives; its security 511 is inadequate for some parameter choices, and it has proven to be 512 difficult to implement in a way that resists padding oracle and 513 related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For 514 future uses of CBC and HMAC, it is better to use encrypt-then-MAC." 516 This note uses HMAC-SHA1 because it is widely deployed and is 517 adequately secure, and HMAC-SHA-2, because it is used in newer 518 standards and is expected to become widely deployed. It has been 519 recently announced that the SHA-3 standard will be based on KECCAK, 520 but this note does not incorporate that hash function. To do so 521 would be to speculate on the final form of the SHA-3 standard. In 522 addition, while the use of KECCAK as a hash function is 523 straightforward, there are multiple options for its use in 524 authenticated encryption. The focus of this note is the definition 525 of AEAD algorithms based on currently used cryptographic mechanisms, 526 so SHA-3 is out of scope. 528 5. Test Cases 530 A future version of this note will contain test cases for all of the 531 AEAD algorithms that it defines. 533 6. Security Considerations 535 An earlier version of this document benefitted from some review. 536 Comments on this version are requested and should be forwarded to the 537 IRTF Crypto Forum Research Group (CFRG). 539 The algorithms defined in this document use the generic composition 540 of CBC encryption with HMAC authentication, with the encrypt-then-MAC 541 method defined in Section 4.3 of [BN00]. This method has sound and 542 well-understood security properties; for details, please see that 543 reference. Note that HMAC is a good pseudorandom function and is 544 "strongly unforgeable", and thus meets all of the security goals of 545 that reference. 547 During the decryption process, the inputs A and C are mapped into the 548 input of the HMAC algorithm. It is essential for security that each 549 possible input to the MAC algorithm corresponds unambiguously to 550 exactly one pair (A, C) of possible inputs. The fact that this 551 property holds can be verified as follows. The HMAC input is X = A 552 || C || len(A). Let (A,C) and (A',C') denote two distinct input 553 pairs, in which either 1) A != A' and C = C', 2) C != C and A = A', 554 or 3) both inequalities hold. We also let X' = A' || C' || len(A'). 555 In cases 1 and 2, X != X' follows immediately. In case 3, if len(A) 556 != len(A'), then X != X' directly. If len(A) = len(A'), then X != X 557 follows from the fact that the initial len(A) bits of X and X' must 558 be distinct. 560 There are security benefits to providing both confidentiality and 561 authentication in a single atomic operation, as done in this note. 562 This tight binding prevents subtle attacks such as the padding oracle 563 attack. 565 As with any block cipher mode of operation, the security of AES-CBC 566 degrades as the amount of data that is process increases. Each fixed 567 key value SHOULD NOT be used to protect more than 2^64 bytes of data. 568 This limit ensures that the AES-CBC algorithm will stay under the 569 birthday bound, i.e. because of the limit, it is unlikely that there 570 will be two AES plaintext inputs that are equal. (If this event 571 occurs, information about the colliding plaintexts is leaked, so it 572 is desirable to bound the amount of plaintext processed in order to 573 make it unlikely.) 575 7. Acknowledgements 577 Thanks are due to Matt Miller and John Foley for their constructive 578 feedback; special thanks to John for his generation of the test 579 cases. Thanks also to Kelly Burgin and Michael Peck for their 580 suggestions and help. 582 8. References 584 8.1. Normative References 586 [FIPS186-2] 587 "FIPS 180-2: Secure Hash Standard,", Federal Information 588 Processing Standard 589 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 591 [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal 592 Information Processing Standard 593 (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. 595 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 596 Hashing for Message Authentication", RFC 2104, 597 February 1997. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 603 SHA-1", RFC 2202, September 1997. 605 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 606 ESP and AH", RFC 2404, November 1998. 608 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 609 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 610 RFC 4231, December 2005. 612 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 613 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 615 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 616 Encryption", RFC 5116, January 2008. 618 8.2. Informative References 620 [AP12] Paterson, K. and N. AlFardan, "Plaintext-Recovery Attacks 621 Against Datagram TLS", Network and Distributed System 622 Security Symposium (NDSS) 623 2012 http://www.isg.rhul.ac.uk/~kp/dtls.pdf, 2012. 625 [B96] Bellovin, S., "Problem areas for the IP security 626 protocols", Proceedings of the Sixth Usenix Unix Security 627 Symposium https://www.cs.columbia.edu/~smb/papers/ 628 badesp.pdf, 1996. 630 [BN00] "Authenticated encryption: Relations among notions and 631 analysis of the generic composition paradigm", Proceedings 632 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 633 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. 635 [CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux, 636 "Password Interception in a SSL/TLS Channel", CRYPT0 637 2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps, 638 2003. 640 [DP07] Paterson, K. and J. Degabriele, "Attacking the IPsec 641 Standards in Encryption-only Configurations", IEEE 642 Symposium on Privacy and 643 Security http://eprint.iacr.org/2007/125.pdf, 2007. 645 [DP10] Paterson, K. and J. Degabriele, "On the (in)security of 646 IPsec in MAC-then-encrypt configurations.", ACM Conference 647 on Computer and Communications Security (ACM CCS) 648 2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf, 649 2010. 651 [M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 652 Problems and Countermeasures", Web 653 Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004. 655 [PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 656 Does Matter: Attacks and Proofs for the TLS Record 657 Protocol", IEEE Symposium on Security and Privacy 658 2012 http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf, 659 January 2012. 661 [R02] "Authenticated encryption with Associated-Data", 662 Proceedings of the 2002 ACM Conference on Computer and 663 Communication Security (CCS'02), pp. 98-107, ACM Press, 664 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. 666 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 667 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 669 [SP800-38] 670 Dworkin, M., "NIST Special Publication 800-38: 671 Recommendation for Block Cipher Modes of Operation", U.S. 672 National Institue of Standards and Technology http:// 673 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 675 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 676 Applications to SSL, IPSEC, WTLS ....", EUROCRYPT 2002 htt 677 p://lasecwww.epfl.ch/php_code/publications/ 678 search.php?ref=Vau02a, 2002. 680 [YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of 681 Unauthenticated Encryption: Kerberos Version 4", Network 682 and Distributed Security Symposium (NDSS) 683 2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf, 684 2004. 686 Appendix A. CBC Encryption and Decryption 688 The Cipher Block Chaining (CBC) mode of operation is defined in 689 [SP800-38]. This section recalls how that mode works, for the 690 convenience of the reader. The following notation is used: 692 K denotes the key of the underlying block cipher, 694 The function CIPHER(K, P) denotes the encryption of the block P 695 with the block cipher, 697 The function CIPHER-INV(K, C) denotes the decryption of the block 698 C with the block cipher; this is the inverse operation of 699 CIPHER(), and CIPHER-INV(K, CIPHER(K, P)) = P for all P and all K. 701 P_1, P_2, ... , P_n denotes the sequence of plaintext blocks, 702 where each block contains exactly the number of bits that the 703 block cipher accepts as its plaintext input, 705 C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext 706 blocks, where each block contains exactly the number of bits that 707 the block cipher accepts as its plaintext input, 709 P_i and C_i denote the ith blocks of the plaintext, and 711 IV denotes the initialization vector, which contains exactly the 712 number of bits that the block cipher accepts as its plaintext 713 input. 715 The CBC encryption operation (denoted as CBC-ENC) takes as input a 716 sequence of n plaintext blocks and produces a sequence of n + 1 717 ciphertext blocks as follows: 719 IV = random 720 C_i = / IV if i=0, 721 \ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n. 723 The IV MUST be generated using a uniformly random process, or a 724 pseudorandom process with a cryptographic strength equivalent to that 725 of the underlying block cipher. It MUST NOT be predictable to an 726 attacker; in particular, it MUST NOT be set to the value of any 727 previous ciphertext blocks. 729 The CBC decryption operation (denoted as CBC-DEC) takes as input a 730 sequence of m ciphertext blocks and produces a sequence of m-1 731 plaintext blocks as follows: 733 P_i = CIPHER-INV(K, P_1 XOR IV) for i=1, 2, ... , n. 735 Authors' Addresses 737 David A. McGrew 738 Cisco Systems, Inc. 739 13600 Dulles Technology Drive 740 Herndon, VA 20171 741 US 743 Phone: (408) 525 8651 744 Email: mcgrew@cisco.com 745 URI: http://www.mindspring.com/~dmcgrew/dam.htm 747 Kenny Paterson 748 Royal Holloway, University of London 749 TW20 0EX 750 Egham, Surrey TW20 0EX 751 UK 753 Phone: +44 1784 414393 754 Email: Kenny.Paterson@rhul.ac.uk 755 URI: http://www.isg.rhul.ac.uk/~kp/