idnits 2.17.00 (12 Aug 2021) /tmp/idnits24817/draft-mcgrew-aead-aes-cbc-hmac-sha2-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 : ---------------------------------------------------------------------------- ** 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 (June 11, 2012) is 3630 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: December 13, 2012 Royal Holloway, University of 6 London 7 June 11, 2012 9 Authenticated Encryption with AES-CBC and HMAC-SHA 10 draft-mcgrew-aead-aes-cbc-hmac-sha2-00.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 December 13, 2012. 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. Conventions Used In This Document . . . . . . . . . . . . 3 60 2. CBC-HMAC algorithms . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3. Length . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 7 65 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 8 66 2.6. AEAD_AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 8 67 2.7. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 9 68 2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 10 70 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 13 73 5.2. AEAD_AES_128_CBC_HMAC_SHA256 . . . . . . . . . . . . . . . 14 74 5.3. AEAD_AES_192_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 15 75 5.4. AEAD_AES_256_CBC_HMAC_SHA512 . . . . . . . . . . . . . . . 16 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 81 Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 84 1. Introduction 86 Authenticated Encryption (AE) [BN00] is a form of encryption that, in 87 addition to providing confidentiality for the plaintext that is 88 encrypted, provides a way to check its integrity and authenticity. 89 This combination of features can, when properly implemented, provide 90 security against adversaries who have access to full decryption 91 capabilities for ciphertexts of their choice, and access to full 92 encryption capabilities for plaintexts of their choice. The strong 93 form of security provided by AE is known to robust against a large 94 class of adversaries for general purpose applications of AE, 95 including applications such as securing network communications over 96 untrusted networks. The strong security properties of AE stand in 97 contrast to the known weaknesses of "encryption only" forms of 98 encryption, see [B96][YHR04][DP09] for examples. 100 Authenticated encryption with Associated Data, or AEAD [R02], adds 101 the ability to check the integrity and authenticity of some 102 associated data (sometimes called "additional authenticated data") 103 for which confidentiality is not required (or is not desirable). 104 While many approaches to building AEAD schemes are known, a 105 particularly simple, well-understood, and cryptographically strong 106 method is to employ an "Encrypt-then-MAC" construction. This 107 document defines new AEAD algorithms of this general type, using the 108 interface defined in [RFC5116], based on the Advanced Encryption 109 Standard (AES) [FIPS197] in the Cipher Block Chaining (CBC) mode of 110 operation [SP800-38] and HMAC using the Secure Hash Algorithm (SHA) 111 [FIPS186-2], with security levels of 128, 192, and 256 bits. 113 1.1. Conventions Used In This Document 115 We use the following notational conventions. 117 CBC-ENC(X,P) denotes the CBC encryption of P using the cipher with 118 the key X 120 MAC(Y, M) denotes the application of the Message Authentication 121 Code (MAC) to the message M, using the key Y 123 The concatenation of two octet strings A and B is denoted as 124 A || B 126 len(X) denotes the number of bits in the string X, expressed as an 127 unsigned integer in network byte order. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. CBC-HMAC algorithms 135 This section defines CBC-HMAC, an algorithm based on the the encrypt- 136 then-MAC method defined in Section 4.3 of [BN00]. That method 137 constructs a randomized AEAD algorithm out of a randomized cipher, 138 such as a block cipher mode of operation that uses a random 139 initialization vector, and a MAC. 141 Section 2.1 and Section 2.2 define the CBC-HMAC encryption and 142 decryption algorithms, without specifying the particular block cipher 143 or hash function to be used. Section 2.4, Section 2.5, Section 2.6, 144 and Section 2.7, define instances of CBC-HMAC that specify those 145 details. 147 2.1. Encryption 149 We briefly recall the encryption interface defined in Section 2 of 150 [RFC5116]. The AEAD encryption algorithm takes as input four octet 151 strings: a secret key K, a plaintext P, associated data A, and a 152 nonce N. An authenticated ciphertext value is provided as output. 153 The data in the plaintext are encrypted and authenticated, and the 154 associated data are authenticated, but not encrypted. 156 In CBC-HMAC, the nonce MUST be a zero-length string; a nonce is not 157 needed and is not used (see Section 4 for further background). CBC- 158 HMAC also has an additional parameter MIN_LEN_A, which is a 159 nonnegative integer that indicates the smallest value of A that will 160 be used with the particular key K. The value of MIN_LEN_A SHOULD be 161 provided when a key is initialized, and the value MUST be unchanging 162 across the life of the key. If the value of MIN_LEN_A is not 163 provided, then it MUST be assumed to be zero. 165 The CBC-HMAC encryption process is as follows, or uses an equivalent 166 set of steps: 168 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 169 input key K as follows. Each of these two keys is an octet 170 string. 172 MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in 173 order. 175 ENC_KEY consists of the final ENC_KEY_LEN octets of K, in 176 order. 178 Here we denote the number of octets in the MAC_KEY as 179 MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN; 180 the values of these parameters are specified by the AEAD 181 algorithms (in Section 2.4 and Section 2.5). The number of 182 octets in the input key K is the sum of MAC_KEY_LEN and 183 ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY 184 and ENC_KEY MUST NOT overlap. 186 2. An Initialization Vector (IV) is generated randomly or 187 pseudorandomly, as described in Section 3, for use in the cipher. 189 3. Prior to CBC encryption, the plaintext P is padded by appending a 190 padding string PS to that data, to ensure that len(P || PS) is a 191 multiple of 128, as is needed for the CBC operation. The value 192 of PS is as follows: 194 PS = 01, if len(P) mod 128 = 120, 195 PS = 0202, if len(P) mod 128 = 112, 196 PS = 030303, if len(P) mod 128 = 104, 197 ... 198 PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F, if len(P) mod 128 = 0. 200 Note that padding MUST be added to the plaintext; if the number 201 of bits in P is a multiple of 128, then 128 bits of padding will 202 be added. 204 4. The plaintext and appended padding P || PS is CBC encrypted using 205 ENC_KEY as the key, and the IV generated in the previous step. 206 We denote the ciphertext output from this step as S, and it MUST 207 include the IV as its prefix. 209 5. The octet string AL is computed as follows. If len(A) = 210 MIN_LEN_A, then AL is the zero-length string. Otherwise, it is 211 equal to the number of bits in A expressed as a 64-bit unsigned 212 integer in network byte order. 214 6. A message authentication tag T is computed by applying HMAC 215 [RFC2104] to the following data, in order: 217 the associated data A, 219 the ciphertext S computed in the previous step, and 221 the octet string AL defined above. 223 The string MAC_KEY is used as the MAC key. We denote the output 224 of the MAC computed in this step as T. 226 7. The AEAD Ciphertext consists of the string S, with the string T 227 appended to it. This Ciphertext is returned as the output of the 228 AEAD encryption operation. 230 The encryption process can be illustrated as follows. Here P, A, and 231 C denote the AEAD plaintext, associated data, and ciphertext, 232 respectively. 234 MAC_KEY = initial MAC_KEY_LEN bytes of K 236 ENC_KEY = final ENC_KEY_LEN bytes of K 238 S = CBC-ENC(ENC_KEY, P || PS), 240 T = MAC(MAC_KEY, A || S || AL), 242 C = S || T. 244 2.2. Decryption 246 The authenticated decryption operation has four inputs: K, N, and A, 247 as defined above, and the Ciphertext C. It has only a single output, 248 either a plaintext value P or a special symbol FAIL that indicates 249 that the inputs are not authentic. The authenticated decryption 250 algorithm takes is as follows, or uses an equivalent set of steps: 252 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 253 input key K as in Step 1 of Section 2.1. 255 2. The final T_LEN octets are stripped from C. Here T_LEN denotes 256 the number of octets in the MAC, which is a fixed parameter of 257 the AEAD algorithm. We denote the initial octets of C as S, and 258 denote the final T_LEN octets as T. 260 3. The integrity and authenticity of A and C are checked by 261 computing HMAC with the inputs as in Step 5 of the Section 2.1. 262 The value T, from the previous step, is compared to the HMAC 263 output. If those values are identical, then A and C are 264 considered valid, and processing is continued. Otherwise, all of 265 the data used in the MAC validation are discarded, and the AEAD 266 decryption operation returns an indication that it failed, and 267 the operation halts. 269 4. The value S is decrypted, using the initial 16 octets of the 270 ciphertext as the IV. The value ENC_KEY is used as the 271 decryption key. 273 5. The padding string is removed. Note that the length of PS can be 274 inferred from the value of the final octet of P || PS, if that 275 value is between 00 and 0F (hexadecimal). If the final octet has 276 a value outside that range, then all of the data used in the 277 processing of the message is zeroized and discarded, and the AEAD 278 decryption operation returns an indication that it failed, and 279 the operation halts. 281 6. The plaintext value is returned. 283 2.3. Length 285 The length of the ciphertext can be inferred from that of the 286 plaintext. The number L of octets in the ciphertext is given by 288 L = 16 * ( floor(M / 16) + 2) 290 where M denotes the number of octets in the plaintext, and the 291 function floor() rounds its argument down to the nearest integer. 292 This fact is useful to applications that need to reserve space for a 293 ciphertext within a message or data structure. 295 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 297 This algorithm is randomized and stateless. It is based on the CBC- 298 HMAC algorithm detailed above. It uses the HMAC message 299 authentication code [RFC2104] with the SHA-256 hash function 300 [FIPS186-2] to provide message authentication, with the HMAC output 301 truncated to 128 bits, corresponding to the HMAC-SHA-256-128 302 algorithm defined in [RFC4868]. For encryption, it uses AES in the 303 cipher block chaining (CBC) mode of operation as defined in Section 304 6.2 of [SP800-38], with the padding method used by PEM, PKCS, and 305 TLS. 307 The input key K is 48 octets long. 309 The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets. 311 The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 32 312 octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by 313 stripping off the final 16 octets. Test cases for HMAC-SHA-256 are 314 provided in [RFC4231]. 316 The lengths of the inputs are restricted as follows: 318 K_LEN is 48 octets, 320 P_MAX is 2^64 - 1 octets, 322 A_MAX is 2^64 - 1 octets, 324 N_MIN is zero octets, 325 N_MAX is 2^64 octets, and 327 C_MAX is 2^64 + 47 octets. 329 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 331 AEAD_AES_192_CBC_HMAC_SHA_384 is based on 332 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 334 AES-192 is used instead of AES-128. 336 SHA-384 is used in HMAC instead of SHA-256. 338 ENC_KEY_LEN is 24 octets. 340 MAC_KEY_LEN is 48 octets. 342 The length of the input key K is 72 octets. 344 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 345 16 octets. 347 The input length restrictions are as for 348 AEAD_AES_CBC_128_HMAC_SHA_256. 350 2.6. AEAD_AES_256_CBC_HMAC_SHA_512 352 AEAD_AES_256_CBC_HMAC_SHA_512 is based on 353 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 355 AES-256 is used instead of AES-128. 357 SHA-512 is used in HMAC instead of SHA-256. 359 ENC_KEY_LEN is 32 octets. 361 MAC_KEY_LEN is 64 octets. 363 The length of the input key K is 96 octets. 365 The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of 366 16 octets. 368 The input length restrictions are as for 369 AEAD_AES_CBC_128_HMAC_SHA_256. 371 2.7. AEAD_AES_128_CBC_HMAC_SHA1 373 AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256, 374 but with the following differences: 376 HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for HMAC- 377 SHA1 are provided in [RFC2202]. 379 MAC_KEY_LEN is 20 octets. 381 The length of the input key K is 36 octets. 383 The HMAC-SHA-1 value is truncated to T_LEN=12 octets instead of 16 384 octets. (Note that this matches the truncation used in 385 [RFC2404].) 387 The input length restrictions are as for 388 AEAD_AES_CBC_128_HMAC_SHA_256. 390 2.8. Summary 392 The parameters of the CBC-HMAC algorithms are summarized in the 393 following table. 395 +-------------------------------+-------------+-------------+-------+ 396 | algorithm | ENC_KEY_LEN | MAC_KEY_LEN | T_LEN | 397 +-------------------------------+-------------+-------------+-------+ 398 | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 32 | 16 | 399 | | | | | 400 | AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 48 | 24 | 401 | | | | | 402 | AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 64 | 32 | 403 | | | | | 404 | AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 20 | 12 | 405 +-------------------------------+-------------+-------------+-------+ 407 3. Randomness Requirements 409 Each IV MUST be unpredictable to the adversary. It MAY be chosen 410 uniformly at random, in which case it SHOULD have min-entropy equal 411 within one bit of ENC_KEY_LEN. Alternatively, it MAY be generated 412 pseudorandomly, using any method that provides the same level of 413 security as the block cipher in use. However, if a pseudorandom 414 method is used, that method MUST NOT make use of ENC_KEY or MAC_KEY. 416 SP 800-90 describes suitable pseudorandom generators. 418 4. Rationale 420 The CBC-HMAC AEAD algorithms defined in this note are intended to be 421 useful in the following applications: 423 systems that have the CBC and HMAC algorithms available, but do 424 not have dedicated AEAD algorithms such as GCM or CCM [RFC5116], 426 scenarios in which AEAD is useful, but it is undesirable to have 427 the applicaiton maintain a deterministic nonce; see Section 4 of 428 [RFC5116] for more background, 430 new systems, such as JSON Cryptography and W3C Web Crypto, which 431 can omit unauthenticated symmetric encryption altogether by 432 providing CBC and HMAC through an AEAD interface. 434 These algorithms are not intended to replace existing uses of AES-CBC 435 and HMAC, except in those circumstances where the existing use is not 436 sufficiently secure or sufficiently general-purpose. 438 The length of the associated data input A is included in the HMAC 439 input to ensure that the encrypter and the decrypter have the same 440 understanding of that length. Because of this, an attacker cannot 441 trick the receiver into interpreting the initial bytes of C as the 442 final bytes of A, or vice-versa. The MIN_LEN_A parameter is included 443 so that it is possible to use CBC-HMAC in a way that corresponds to 444 existing uses of CBC and HMAC. Some existing systems (such as ESP or 445 IEEE 1619.1) make use of those algorithms, but do not include the 446 length of the associated data in the HMAC input. These systems can 447 be secure because the length of the associated data is fixed, or can 448 be inferred by other means. The MIN_LEN_A parameter allows the AL 449 field to be zero-length when both the encrypter and the decrypter 450 know the length of the associated data field. This enables 451 implementations of CBC-HMAC to be compatible with existing systems 452 that do not include the length of A in the HMAC input. 454 The padding method used in this note is based on that of Privacy 455 Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS), 456 because it is implemented in many environments. 458 The encrypt-then-MAC method is used because of its better security 459 properties. It would be possible to define AEAD algorithms based on 460 the MAC-encode-encrypt (MEE) method that is used by the Transport 461 Layer Security (TLS) protocol [RFC5246]. That alternative would 462 provide more code-sharing opportunities for an implementation that is 463 co-resident with a TLS implementation. It is possible (but tricky) 464 to implement MEE in a way that provides good security, as was shown 465 in [PRS11]. But its negatives outweigh its positives; its security 466 is inadequate for some parameter choices, and it has proven to be 467 difficult to implement in a way that resists padding oracle and 468 related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For 469 future uses of CBC and HMAC, it is better to use encrypt-then-MAC." 471 5. Test Cases 473 5.1. AEAD_AES_128_CBC_HMAC_SHA1 475 P = 41206369706865722073797374656d206d757374206e6f742062652072657175 476 6972656420746f206265207365637265742c20616e64206974206d7573742062 477 652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66 478 2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365 480 K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 481 20212223 483 MAC_KEY = 000102030405060708090a0b0c0d0e0f10111213 484 ENC_KEY = 1415161718191a1b1c1d1e1f20212223 486 A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520 487 4b6572636b686f666673 489 IV = 1af38c2dc2b96ffdd86694092341bc04 491 C_0 = 1af38c2dc2b96ffdd86694092341bc04 492 P_1 = 41206369706865722073797374656d20 493 C_1 = c63aec9963f4ff33a85e564cd05f9240 494 P_2 = 6d757374206e6f742062652072657175 495 C_2 = 0a71fe98bcb339acc1d78c92b3aa6a32 496 P_3 = 6972656420746f206265207365637265 497 C_3 = 1460d2aecec43b784b3b08b830be5291 498 P_4 = 742c20616e64206974206d7573742062 499 C_4 = dc0400b8afc6cd1c8475764632a83605 500 P_5 = 652061626c6520746f2066616c6c2069 501 C_5 = 01e5319a128127ae4b0eaa9b2f97ea6d 502 P_6 = 6e746f207468652068616e6473206f66 503 C_6 = f02200d6f68c743b794ed5d6139e84c4 504 P_7 = 2074686520656e656d7920776974686f 505 C_7 = cb919ebb8d8256098b6385e41476c416 506 P_8 = 757420696e636f6e76656e69656e6365 507 C_8 = cfc85a46fac40ea450d2b4c0fd7e03dc 508 P_9 = 10101010101010101010101010101010 509 C_9 = d833c8c3d2135f0d109bd231808bb3fd 511 S = 1af38c2dc2b96ffdd86694092341bc04c63aec9963f4ff33a85e564cd05f9240 512 0a71fe98bcb339acc1d78c92b3aa6a321460d2aecec43b784b3b08b830be5291 513 dc0400b8afc6cd1c8475764632a8360501e5319a128127ae4b0eaa9b2f97ea6d 514 f02200d6f68c743b794ed5d6139e84c4cb919ebb8d8256098b6385e41476c416 515 cfc85a46fac40ea450d2b4c0fd7e03dcd833c8c3d2135f0d109bd231808bb3fd 517 T = 9aed4feb1e6d25070b9a6f07 518 C = 1af38c2dc2b96ffdd86694092341bc04c63aec9963f4ff33a85e564cd05f92400 519 a71fe98bcb339acc1d78c92b3aa6a321460d2aecec43b784b3b08b830be5291dc 520 0400b8afc6cd1c8475764632a8360501e5319a128127ae4b0eaa9b2f97ea6df02 521 200d6f68c743b794ed5d6139e84c4cb919ebb8d8256098b6385e41476c416cfc8 522 5a46fac40ea450d2b4c0fd7e03dcd833c8c3d2135f0d109bd231808bb3fd9aed4 523 feb1e6d25070b9a6f07 525 5.2. AEAD_AES_128_CBC_HMAC_SHA256 527 K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 528 20212223242526270001020304050607 530 P = 41206369706865722073797374656d206d757374206e6f742062652072657175 531 6972656420746f206265207365637265742c20616e64206974206d7573742062 532 652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66 533 2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365 535 A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520 536 4b6572636b686f666673 538 IV = 1af38c2dc2b96ffdd86694092341bc04 540 S = 1af38c2dc2b96ffdd86694092341bc04bec9dc25654f7eee633a29d2a14becfe 541 79d5b3bfd19b0676584990ee84bb4279197d7ebca389b7e5c101898eed58c34b 542 df22b74683a82cf07ae4ddeb4bf5731fc00dd4a98195de6e2e36985161bbe5ec 543 13067e3508162da908dede1808a97578dc896d221063c7425679fd6bcfb8ce90 544 c197fd05447a2cf7f2fe02a03fdf29c675fa66ecb12e398b7f6fc3c9ae3d03ba 546 T = e0f20e4a7d3fa9dd5aadcd3ad982f09e 548 C = 1af38c2dc2b96ffdd86694092341bc04bec9dc25654f7eee633a29d2a14becfe 549 79d5b3bfd19b0676584990ee84bb4279197d7ebca389b7e5c101898eed58c34b 550 df22b74683a82cf07ae4ddeb4bf5731fc00dd4a98195de6e2e36985161bbe5ec 551 13067e3508162da908dede1808a97578dc896d221063c7425679fd6bcfb8ce90 552 c197fd05447a2cf7f2fe02a03fdf29c675fa66ecb12e398b7f6fc3c9ae3d03ba 553 e0f20e4a7d3fa9dd5aadcd3ad982f09e 555 5.3. AEAD_AES_192_CBC_HMAC_SHA384 557 K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 558 2021222324252627000102030405060708090a0b0c0d0e0f1011121314151617 559 18191a1b1c1d1e1f 561 P = 41206369706865722073797374656d206d757374206e6f742062652072657175 562 6972656420746f206265207365637265742c20616e64206974206d7573742062 563 652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66 564 2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365 566 IV = 1af38c2dc2b96ffdd86694092341bc04 568 A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520 569 4b6572636b686f666673 571 PS = 10101010101010101010101010101010 573 AL = 0000000000000150 575 S = 1af38c2dc2b96ffdd86694092341bc04ac57bb8225686ff568320b98ad54fa10 576 eea70c609d4d11d4c34435e386623d0240e9f6c0f78126678546ae2ba2d3017c 577 4e0ef70d7c5ec2724fecf715518bc48e9048e446077db090e135f33710a2c40d 578 e0ea744adeca3149a94f9be65fe3e2982ca63e89d026e39319322b417ff9ee5a 579 b06b71ea5894d9f0ad5089402e174a90cf65bed15f8835d3134a6302ef6cfd4d 581 T = 0b3948b860797cc2ba0f89d3e79d5465ed770cc8e5b8a430 583 C = 1af38c2dc2b96ffdd86694092341bc04ac57bb8225686ff568320b98ad54fa10 584 eea70c609d4d11d4c34435e386623d0240e9f6c0f78126678546ae2ba2d3017c 585 4e0ef70d7c5ec2724fecf715518bc48e9048e446077db090e135f33710a2c40d 586 e0ea744adeca3149a94f9be65fe3e2982ca63e89d026e39319322b417ff9ee5a 587 b06b71ea5894d9f0ad5089402e174a90cf65bed15f8835d3134a6302ef6cfd4d 588 0b3948b860797cc2ba0f89d3e79d5465ed770cc8e5b8a430 590 5.4. AEAD_AES_256_CBC_HMAC_SHA512 592 K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 593 2021222324252627000102030405060708090a0b0c0d0e0f1011121314151617 594 18191a1b1c1d1e1f2021222324252627000102030405060708090a0b0c0d0e0f 596 P = 41206369706865722073797374656d206d757374206e6f742062652072657175 597 6972656420746f206265207365637265742c20616e64206974206d7573742062 598 652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66 599 2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365 601 IV = 1af38c2dc2b96ffdd86694092341bc04 603 A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520 604 4b6572636b686f666673 606 PS = 10101010101010101010101010101010 608 AL = 0000000000000150 610 S = 1af38c2dc2b96ffdd86694092341bc04d39c2d2b1248eb14a7f8d1c1e8f3ff17 611 309d44cb0cb0dfd38695bf29f37258f74fc9ef1d05b7c71cb3c6fb04bad09105 612 bc605e8b9c737008a47453b9415cd7407e7314cc73f5ba432172b6da53c33553 613 8ba9614d79f36e393c8178ba8fb2deec0eaa4cf1eda1cf279fabd9799af60542 614 04c96e06eacedb231c76c33e38317882eeb55fd9e534c1e73343d8cf00ff283a 616 T = 2cf60bc4a50b569f0ae708a7889761b3f867c37537a8bd74c162e9b8ee859b08 618 C = 1af38c2dc2b96ffdd86694092341bc04d39c2d2b1248eb14a7f8d1c1e8f3ff17 619 309d44cb0cb0dfd38695bf29f37258f74fc9ef1d05b7c71cb3c6fb04bad09105 620 bc605e8b9c737008a47453b9415cd7407e7314cc73f5ba432172b6da53c33553 621 8ba9614d79f36e393c8178ba8fb2deec0eaa4cf1eda1cf279fabd9799af60542 622 04c96e06eacedb231c76c33e38317882eeb55fd9e534c1e73343d8cf00ff283a 623 2cf60bc4a50b569f0ae708a7889761b3f867c37537a8bd74c162e9b8ee859b08 625 6. Security Considerations 627 An earlier version of this document benefitted from some review. 628 Comments on this version are requested and should be forwarded to the 629 IRTF Crypto Forum Research Group (CFRG). 631 The algorithms defined in this document use the generic composition 632 of CBC encryption with HMAC authentication, with the encrypt-then-MAC 633 method defined in Section 4.3 of [BN00]. This method has sound and 634 well-understood security properties; for details, please see that 635 reference. Note that HMAC is a good pseudorandom function and is 636 "strongly unforgeable", and thus meets all of the security goals of 637 that reference. 639 There are security benefits to providing both confidentiality and 640 authentication in a single atomic operation, as done in this note. 641 This tight binding prevents subtle attacks such as the padding oracle 642 attack. 644 As with any block cipher mode of operation, the security of AES-CBC 645 degrades as the amount of data that is process increases. Each fixed 646 key value SHOULD NOT be used to protect more than 2^64 bytes of data. 647 This limit ensures that the AES-CBC algorithm will stay under the 648 birthday bound, i.e. because of the limit, it is unlikely that there 649 will be two AES plaintext inputs that are equal. (If this event 650 occurs, information about the colliding plaintexts is leaked, so it 651 is desirable to bound the amount of plaintext processed in order to 652 make it unlikely.) 654 7. Acknowledgements 656 Thanks are due to Matt Miller and John Foley for their constructive 657 feedback; special thanks to John for his generation of the test 658 cases. 660 8. References 662 8.1. Normative References 664 [FIPS186-2] 665 "FIPS 180-2: Secure Hash Standard,", Federal Information 666 Processing Standard 667 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 669 [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal 670 Information Processing Standard 671 (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. 673 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 674 Hashing for Message Authentication", RFC 2104, 675 February 1997. 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 681 SHA-1", RFC 2202, September 1997. 683 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 684 ESP and AH", RFC 2404, November 1998. 686 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 687 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 688 RFC 4231, December 2005. 690 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 691 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 693 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 694 Encryption", RFC 5116, January 2008. 696 8.2. Informative References 698 [AP12] Paterson, K. and N. AlFardan, "Plaintext-Recovery Attacks 699 Against Datagram TLS", Network and Distributed System 700 Security Symposium (NDSS) 701 2012 http://www.isg.rhul.ac.uk/~kp/dtls.pdf, 2012. 703 [B96] Bellovin, S., "Problem areas for the IP security 704 protocols", Proceedings of the Sixth Usenix Unix Security 705 Symposium https://www.cs.columbia.edu/~smb/papers/ 706 badesp.pdf, 1996. 708 [BN00] "Authenticated encryption: Relations among notions and 709 analysis of the generic composition paradigm", Proceedings 710 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 711 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. 713 [CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux, 714 "Password Interception in a SSL/TLS Channel", CRYPT0 715 2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps, 716 2003. 718 [DP09] Paterson, K. and D. Degabriele, "On the (in)security of 719 IPsec in MAC-then-encrypt configurations", IEEE Symposium 720 on Privacy and 721 Security http://eprint.iacr.org/2007/125.pdf, 2009. 723 [DP10] Paterson, K. and D. Degabriele, "On the (in)security of 724 IPsec in MAC-then-encrypt configurations.", ACM Conference 725 on Computer and Communications Security (ACM CCS) 726 2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf, 727 2010. 729 [M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 730 Problems and Countermeasures", Web 731 Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004. 733 [PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 734 Does Matter: Attacks and Proofs for the TLS Record 735 Protocol", IEEE Symposium on Security and Privacy 736 2012 http://web.cecs.pdx.edu/~teshrim/tmAnotherLook.pdf, 737 January 2012. 739 [R02] "Authenticated encryption with Associated-Data", 740 Proceedings of the 2002 ACM Conference on Computer and 741 Communication Security (CCS'02), pp. 98-107, ACM Press, 742 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. 744 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 745 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 747 [SP800-38] 748 Dworkin, M., "NIST Special Publication 800-38: 749 Recommendation for Block Cipher Modes of Operation", U.S. 750 National Institue of Standards and Technology http:// 751 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 753 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 754 Applications to SSL, IPSEC, WTLS ....", EUROCRYPT 2002 htt 755 p://lasecwww.epfl.ch/php_code/publications/ 756 search.php?ref=Vau02a, 2002. 758 [YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of 759 Unauthenticated Encryption: Kerberos Version 4", Network 760 and Distributed Security Symposium (NDSS) 761 2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf, 762 2004. 764 Appendix A. CBC Encryption and Decryption 766 The Cipher Block Chaining (CBC) mode of operation is defined in 767 [SP800-38]. This section recalls how that mode works, for the 768 convenience of the reader. The following notation is used: 770 K denotes the key of the underlying block cipher, 772 The function CIPHER(K, P) denotes the encryption of the block P 773 with the block cipher, 775 The function CIPHER-INV(K, C) denotes the decryption of the block 776 C with the block cipher; this is the inverse operation of 777 CIPHER(), and CIPHER-INV(K, CIPHER(K, P)) = P for all P and all K. 779 P_1, P_2, ... , P_n denotes the sequence of plaintext blocks, 780 where each block contains exactly the number of bits that the 781 block cipher accepts as its plaintext input, 783 C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext 784 blocks, where each block contains exactly the number of bits that 785 the block cipher accepts as its plaintext input, 787 P_i and C_i denote the ith blocks of the plaintext, and 789 IV denotes the initialization vector, which contains exactly the 790 number of bits that the block cipher accepts as its plaintext 791 input. 793 The CBC encryption operation (denoted as CBC-ENC) takes as input a 794 sequence of n plaintext blocks and produces a sequence of n + 1 795 ciphertext blocks as follows: 797 IV = random 798 C_i = / IV if i=0, 799 \ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n. 801 The IV MUST be generated using a uniformly random process, or a 802 pseudorandom process with a cryptographic strength equivalent to that 803 of the underlying block cipher. It MUST NOT be predictable to an 804 attacker; in particular, it MUST NOT be set to the value of any 805 previous ciphertext blocks. 807 The CBC decryption operation (denoted as CBC-DEC) takes as input a 808 sequence of m ciphertext blocks and produces a sequence of m-1 809 plaintext blocks as follows: 811 P_i = CIPHER-INV(K, P_1 XOR IV) for i=1, 2, ... , n. 813 Authors' Addresses 815 David A. McGrew 816 Cisco Systems, Inc. 817 13600 Dulles Technology Drive 818 Herndon, VA 20171 819 US 821 Phone: (408) 525 8651 822 Email: mcgrew@cisco.com 823 URI: http://www.mindspring.com/~dmcgrew/dam.htm 825 Kenny Paterson 826 Royal Holloway, University of London 827 TW20 0EX 828 Egham, Surrey TW20 0EX 829 UK 831 Phone: +44 1784 414393 832 Email: Kenny.Paterson@rhul.ac.uk 833 URI: http://www.isg.rhul.ac.uk/~kp/