idnits 2.17.1 draft-mcgrew-aead-aes-cbc-hmac-sha2-05.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 4, 2014) is 3555 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 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 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 5, 2015 K. Paterson 6 Royal Holloway, University of 7 London 8 July 4, 2014 10 Authenticated Encryption with AES-CBC and HMAC-SHA 11 draft-mcgrew-aead-aes-cbc-hmac-sha2-05.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 5, 2015. 42 Copyright Notice 44 Copyright (c) 2014 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. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 11 72 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.1. AEAD_AES_128_CBC_HMAC_SHA256 . . . . . . . . . . . . . . . 14 75 5.2. AEAD_AES_192_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 16 76 5.3. AEAD_AES_256_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 18 77 5.4. AEAD_AES_256_CBC_HMAC_SHA512 . . . . . . . . . . . . . . . 20 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 83 Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 28 84 Appendix B. Alternative Interface for Legacy Encoding . . . . . . 30 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 87 1. Introduction 89 Authenticated Encryption (AE) [BN00] is a form of encryption that, in 90 addition to providing confidentiality for the plaintext that is 91 encrypted, provides a way to check its integrity and authenticity. 92 This combination of features can, when properly implemented, provide 93 security against adversaries who have access to full decryption 94 capabilities for ciphertexts of their choice, and access to full 95 encryption capabilities for plaintexts of their choice. The strong 96 form of security provided by AE is known to be robust against a large 97 class of adversaries for general purpose applications of AE, 98 including applications such as securing network communications over 99 untrusted networks. The strong security properties of AE stand in 100 contrast to the known weaknesses of "encryption only" forms of 101 encryption, see [B96][YHR04] [DP07] for examples. 103 Authenticated encryption with Associated Data, or AEAD [R02], adds 104 the ability to check the integrity and authenticity of some 105 associated data (sometimes called "additional authenticated data") 106 for which confidentiality is not required (or is not desirable). 107 While many approaches to building AEAD schemes are known, a 108 particularly simple, well-understood, and cryptographically strong 109 method is to employ an "Encrypt-then-MAC" construction. This 110 document defines new AEAD algorithms of this general type, using the 111 interface defined in [RFC5116], based on the Advanced Encryption 112 Standard (AES) [FIPS197] in the Cipher Block Chaining (CBC) mode of 113 operation [SP800-38] and HMAC using the Secure Hash Algorithm (SHA) 114 [FIPS186-2], with security levels of 128, 192, and 256 bits. 116 Comments on this version are requested and should be forwarded to the 117 IRTF Crypto Forum Research Group (CFRG). An earlier version of this 118 document benefited from some review from that group. 120 1.1. History 122 This subsection describes the revision history of this Internet 123 Draft. It should be removed by the RFC Editor before publication as 124 an RFC. 126 The changes of version 05 from version 05 consist only of changes in 127 Appendix A and the test cases. A variable Q was defined to make the 128 legacy encoding more clear, after discussion between the authors and 129 Mike Jones. 131 The changes of version 02 from version 01 are: 133 Added test cases for each of the five operational modes. 135 Added John as a coauthor. 137 Adds a legacy-style interface in Appendix B. 139 The changes of version 01 from version 00 are: 141 MIN_LEN_A and associated logic was eliminated. 143 Padding String (PS) typo corrected in Section 2.1. 145 Decryption Step 3 refers to the appropriate step in the encryption 146 process. 148 Random IV min-entropy clarified in Section 3. 150 HMAC keys are now the same size as the truncated output (128 or 151 256 bits). Previously, the HMAC keys were the same size as the 152 full hash output (256, 384, or 512 bits). 154 An algorithm based on the combination of AES-256 and HMAC-SHA-384 155 has been added, for compatibility with 156 draft-burgin-kerberos-aes-cbc-hmac-sha2. 158 The test cases in the previous version are no longer valid, and 159 thus have been removed. New test cases have been computed (and 160 the authors thank John Foley for this contribution) but have not 161 been included, pending confirmation from a second, independent 162 implementation. 164 1.2. Conventions Used In This Document 166 We use the following notational conventions. 168 CBC-ENC(X,P) denotes the CBC encryption of P using the cipher with 169 the key X 171 MAC(Y, M) denotes the application of the Message Authentication 172 Code (MAC) to the message M, using the key Y 174 The concatenation of two octet strings A and B is denoted as 175 A || B 177 len(X) denotes the number of bits in the string X, expressed as an 178 unsigned integer in network byte order. 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. CBC-HMAC algorithms 186 This section defines CBC-HMAC, an algorithm based on the the encrypt- 187 then-MAC method defined in Section 4.3 of [BN00]. That method 188 constructs a randomized AEAD algorithm out of a randomized cipher, 189 such as a block cipher mode of operation that uses a random 190 initialization vector, and a MAC. 192 Section 2.1 and Section 2.2 define the CBC-HMAC encryption and 193 decryption algorithms, without specifying the particular block cipher 194 or hash function to be used. Section 2.4, Section 2.5, and 195 Section 2.7 define instances of CBC-HMAC that specify those details. 197 2.1. Encryption 199 We briefly recall the encryption interface defined in Section 2 of 200 [RFC5116]. The AEAD encryption algorithm takes as input four octet 201 strings: a secret key K, a plaintext P, associated data A, and a 202 nonce N. An authenticated ciphertext value is provided as output. 203 The data in the plaintext are encrypted and authenticated, and the 204 associated data are authenticated, but not encrypted. The key MUST 205 be generated in a way that is uniformly random or pseudorandom; 206 guidance on random sources is provided in [RFC4086]. 208 In CBC-HMAC, the nonce N MUST be a zero-length string; a nonce is not 209 needed and is not used (see Section 4 for further background). 211 The CBC-HMAC encryption process is as follows, or uses an equivalent 212 set of steps: 214 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 215 input key K as follows. Each of these two keys is an octet 216 string. 218 MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in 219 order. 221 ENC_KEY consists of the final ENC_KEY_LEN octets of K, in 222 order. 224 Here we denote the number of octets in the MAC_KEY as 225 MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN; 226 the values of these parameters are specified by the AEAD 227 algorithms (in Section 2.4 and Section 2.5). The number of 228 octets in the input key K is the sum of MAC_KEY_LEN and 229 ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY 230 and ENC_KEY MUST NOT overlap. 232 2. Prior to CBC encryption, the plaintext P is padded by appending a 233 padding string PS to that data, to ensure that len(P || PS) is a 234 multiple of 128, as is needed for the CBC operation. The value 235 of PS is as follows: 237 PS = 01 if len(P) mod 128 = 120, 238 PS = 0202 if len(P) mod 128 = 112, 239 PS = 030303 if len(P) mod 128 = 104, 240 PS = 04040404 if len(P) mod 128 = 96, 241 PS = 0505050505 if len(P) mod 128 = 88, 242 PS = 060606060606 if len(P) mod 128 = 80, 243 PS = 07070707070707 if len(P) mod 128 = 72, 244 PS = 0808080808080808 if len(P) mod 128 = 64, 245 PS = 090909090909090909 if len(P) mod 128 = 56, 246 PS = 0A0A0A0A0A0A0A0A0A0A if len(P) mod 128 = 48, 247 PS = 0B0B0B0B0B0B0B0B0B0B0B if len(P) mod 128 = 40, 248 PS = 0C0C0C0C0C0C0C0C0C0C0C0C if len(P) mod 128 = 32, 249 PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) mod 128 = 24, 250 PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) mod 128 = 16, 251 PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F if len(P) mod 128 = 8, 252 PS = 10101010101010101010101010101010 if len(P) mod 128 = 0. 254 Note that padding MUST be added to the plaintext; if the number 255 of bits in P is a multiple of 128, then 128 bits of padding will 256 be added. 258 3. The plaintext and appended padding P || PS is CBC encrypted using 259 ENC_KEY as the key, as described in Appendix A. We denote the 260 ciphertext output from this step as S. 262 4. The octet string AL is equal to the number of bits in A expressed 263 as a 64-bit unsigned integer in network byte order. 265 5. A message authentication tag T is computed by applying HMAC 266 [RFC2104] to the following data, in order: 268 the associated data A, 270 the ciphertext S computed in the previous step, and 272 the octet string AL defined above. 274 The string MAC_KEY is used as the MAC key. We denote the output 275 of the MAC computed in this step as T. 277 6. The AEAD Ciphertext consists of the string S, with the string T 278 appended to it. This Ciphertext is returned as the output of the 279 AEAD encryption operation. 281 The encryption process can be illustrated as follows. Here P, A, and 282 C denote the AEAD plaintext, associated data, and ciphertext, 283 respectively. 285 MAC_KEY = initial MAC_KEY_LEN bytes of K 287 ENC_KEY = final ENC_KEY_LEN bytes of K 289 S = CBC-ENC(ENC_KEY, P || PS), 291 T = MAC(MAC_KEY, A || S || AL), 293 C = S || T. 295 2.2. Decryption 297 The authenticated decryption operation has four inputs: K, N, and A, 298 as defined above, and the Ciphertext C. As discussed above, N is an 299 empty string in AES-CBC and is not used below. It has only a single 300 output, either a plaintext value P or a special symbol FAIL that 301 indicates that the inputs are not authentic. The authenticated 302 decryption algorithm takes is as follows, or uses an equivalent set 303 of steps: 305 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 306 input key K as in Step 1 of Section 2.1. 308 2. The final T_LEN octets are stripped from C. Here T_LEN denotes 309 the number of octets in the MAC, which is a fixed parameter of 310 the AEAD algorithm. We denote the initial octets of C as S, and 311 denote the final T_LEN octets as T. 313 3. The integrity and authenticity of A and C are checked by 314 computing HMAC with the inputs as in Step 6 of Section 2.1. The 315 value T, from the previous step, is compared to the HMAC output, 316 using a comparison routine that takes constant time to execute. 317 If those values are identical, then A and C are considered valid, 318 and the processing continues. Otherwise, all of the data used in 319 the MAC validation are discarded, and the AEAD decryption 320 operation returns an indication that it failed, and the operation 321 halts. 323 4. The value S is CBC decrypted, as described in Appendix A, using 324 the value ENC_KEY is as the decryption key. 326 5. The padding string is stripped from the resulting plaintext. 327 Note that the length of PS can be inferred from the value of the 328 final octet of P || PS, if that value is between 01 and 10 329 (hexadecimal). If the final octet has a value outside that 330 range, then all of the data used in the processing of the message 331 is zeroized and discarded, and the AEAD decryption operation 332 returns an indication that it failed, and the operation halts. 334 6. The plaintext value is returned. 336 2.3. Length 338 The length of the ciphertext can be inferred from that of the 339 plaintext. The number L of octets in the ciphertext is given by 341 L = 16 * ( floor(M / 16) + 2) 343 where M denotes the number of octets in the plaintext, and the 344 function floor() rounds its argument down to the nearest integer. 345 This fact is useful to applications that need to reserve space for a 346 ciphertext within a message or data structure. 348 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 350 This algorithm is randomized; each invocation of the encrypt 351 operation makes use of a random value (the IV described in 352 Appendix A). It is based on the CBC-HMAC algorithm detailed above, 353 and uses the HMAC message authentication code [RFC2104] with the SHA- 354 256 hash function [FIPS186-2] to provide message authentication, with 355 the HMAC output truncated to 128 bits, corresponding to the HMAC-SHA- 356 256-128 algorithm defined in [RFC4868]. For encryption, it uses the 357 Advanced Encryption Standard (AES) [FIPS197] block cipher in CBC 358 mode. 360 The input key K is 32 octets long. 362 ENC_KEY_LEN is 16 octets. 364 The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16 365 octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by 366 stripping off the final 16 octets. Test cases for HMAC-SHA-256 are 367 provided in [RFC4231]. 369 The lengths of the inputs are restricted as follows: 371 K_LEN is 32 octets, 373 P_MAX is 2^64 - 1 octets, 375 A_MAX is 2^64 - 1 octets, 376 N_MIN and N_MAX are zero octets, 378 C_MAX is 2^64 + 47 octets. 380 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 382 AEAD_AES_192_CBC_HMAC_SHA_384 is based on 383 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 385 AES-192 is used instead of AES-128. 387 SHA-384 is used in HMAC instead of SHA-256. 389 ENC_KEY_LEN is 24 octets. 391 MAC_KEY_LEN is 24 octets. 393 The length of the input key K is 48 octets. 395 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 396 16 octets. 398 The input length restrictions are as for 399 AEAD_AES_CBC_128_HMAC_SHA_256. 401 2.6. AEAD_AES_256_CBC_HMAC_SHA_384 403 AEAD_AES_256_CBC_HMAC_SHA_384 is based on 404 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 406 AES-256 is used instead of AES-128. 408 SHA-384 is used in HMAC instead of SHA-256. 410 ENC_KEY_LEN is 32 octets. 412 MAC_KEY_LEN is 24 octets. 414 The length of the input key K is 56 octets. 416 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 417 16 octets. 419 The input length restrictions are as for 420 AEAD_AES_CBC_128_HMAC_SHA_256. 422 2.7. AEAD_AES_256_CBC_HMAC_SHA_512 424 AEAD_AES_256_CBC_HMAC_SHA_512 is based on 425 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 427 AES-256 is used instead of AES-128. 429 SHA-512 is used in HMAC instead of SHA-256. 431 ENC_KEY_LEN is 32 octets. 433 MAC_KEY_LEN is 32 octets. 435 The length of the input key K is 64 octets. 437 The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of 438 16 octets. 440 The input length restrictions are as for 441 AEAD_AES_CBC_128_HMAC_SHA_256. 443 2.8. 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 +-------------------------------+-------------+-------------+-------+ 460 3. Randomness Requirements 462 Each IV MUST be unpredictable to the adversary. It MAY be chosen 463 uniformly at random, in which case it SHOULD have min-entropy within 464 one bit of len(IV). Alternatively, it MAY be generated 465 pseudorandomly, using any method that provides the same level of 466 security as the block cipher in use. However, if a pseudorandom 467 method is used, that method MUST NOT make use of ENC_KEY or MAC_KEY. 469 4. Rationale 471 The CBC-HMAC AEAD algorithms defined in this note are intended to be 472 useful in the following applications: 474 systems that have the CBC and HMAC algorithms available, but do 475 not have dedicated AEAD algorithms such as GCM or CCM [RFC5116], 477 scenarios in which AEAD is useful, but it is undesirable to have 478 the application maintain a deterministic nonce; see Section 4 of 479 [RFC5116] for more background, 481 new systems, such as JSON Cryptography and W3C Web Crypto, which 482 can omit unauthenticated symmetric encryption altogether by 483 providing CBC and HMAC through an AEAD interface. 485 These algorithms are not intended to replace existing uses of AES-CBC 486 and HMAC, except in those circumstances where the existing use is not 487 sufficiently secure or sufficiently general-purpose. 489 The algorithms in this note truncate the HMAC output to half of the 490 size of the output of the underlying hash function. This size is the 491 recommended minimum (see Section 5 of [RFC2104]), and this parameter 492 choice has withstood the test of time. 494 The length of the associated data input A is included in the HMAC 495 input to ensure that the encrypter and the decrypter have the same 496 understanding of that length. Because of this, an attacker cannot 497 trick the receiver into interpreting the initial bytes of C as the 498 final bytes of A, or vice-versa. 500 The padding method used in this note is based on that of Privacy 501 Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS), 502 because it is implemented in many environments. 504 The encrypt-then-MAC method is used because of its better security 505 properties. It would be possible to define AEAD algorithms based on 506 the MAC-encode-encrypt (MEE) method that is used by the Transport 507 Layer Security (TLS) protocol [RFC5246]. That alternative would 508 provide more code-sharing opportunities for an implementation that is 509 co-resident with a TLS implementation. It is possible (but tricky) 510 to implement MEE in a way that provides good security, as was shown 511 in [PRS11]. But its negatives outweigh its positives; its security 512 is inadequate for some parameter choices, and it has proven to be 513 very difficult to implement in a way that resists padding oracle and 514 related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For 515 future uses of CBC and HMAC, it is better to use encrypt-then-MAC. 517 This note uses HMAC-SHA-2 because it is widely deployed, it is 518 mandated in newer standards, and because SHA1 is being deprecated. 519 It has been recently announced that the SHA-3 standard will be based 520 on KECCAK, but this note does not incorporate that hash function. To 521 do so would be to speculate on the final form of the SHA-3 standard. 522 In 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 5.1. AEAD_AES_128_CBC_HMAC_SHA256 532 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 533 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 535 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 537 ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 539 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 540 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 541 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 542 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 543 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 544 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 545 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 546 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 548 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 550 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 551 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 552 4b 65 72 63 6b 68 6f 66 66 73 554 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 556 AL = 00 00 00 00 00 00 01 50 557 Q = c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 558 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 559 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 560 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 561 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 562 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 563 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 564 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 565 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 567 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 568 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 569 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 570 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 571 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 572 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 573 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 574 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 575 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 576 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 578 T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 580 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 581 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 582 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 583 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 584 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 585 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 586 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 587 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 588 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 589 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 590 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 592 5.2. AEAD_AES_192_CBC_HMAC_SHA384 594 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 595 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 596 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 598 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 599 10 11 12 13 14 15 16 17 601 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 602 28 29 2a 2b 2c 2d 2e 2f 604 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 605 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 606 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 607 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 608 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 609 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 610 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 611 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 613 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 615 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 616 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 617 4b 65 72 63 6b 68 6f 66 66 73 619 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 621 AL = 00 00 00 00 00 00 01 50 622 Q = ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 623 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 624 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 625 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 626 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 627 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 628 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 629 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 630 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 632 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 633 ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 634 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 635 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 636 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 637 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 638 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 639 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 640 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 641 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 643 T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 644 75 16 80 39 cc c7 33 d7 646 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 647 ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 648 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 649 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 650 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 651 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 652 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 653 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 654 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 655 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 656 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 657 75 16 80 39 cc c7 33 d7 659 5.3. AEAD_AES_256_CBC_HMAC_SHA384 661 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 662 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 663 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 664 30 31 32 33 34 35 36 37 666 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 667 10 11 12 13 14 15 16 17 669 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 670 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 672 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 673 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 674 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 675 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 676 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 677 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 678 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 679 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 681 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 683 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 684 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 685 4b 65 72 63 6b 68 6f 66 66 73 687 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 689 AL = 00 00 00 00 00 00 01 50 690 Q = 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 691 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 692 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 693 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 694 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 695 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 696 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 697 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 698 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 700 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 701 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 702 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 703 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 704 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 705 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 706 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 707 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 708 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 709 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 711 T = dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 712 7f 1e 9a 54 1d 9c 23 e7 714 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 715 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 716 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 717 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 718 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 719 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 720 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 721 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 722 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 723 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 724 dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 725 7f 1e 9a 54 1d 9c 23 e7 727 5.4. AEAD_AES_256_CBC_HMAC_SHA512 729 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 730 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 731 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 732 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 734 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 735 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 737 ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 738 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 740 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 741 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 742 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 743 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 744 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 745 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 746 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 747 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 749 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 751 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 752 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 753 4b 65 72 63 6b 68 6f 66 66 73 755 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 757 AL = 00 00 00 00 00 00 01 50 758 Q = 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 759 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 760 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 761 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 762 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 763 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 764 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 765 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 766 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 768 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 769 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 770 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 771 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 772 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 773 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 774 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 775 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 776 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 777 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 779 T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 780 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 782 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 783 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 784 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 785 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 786 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 787 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 788 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 789 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 790 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 791 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 792 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 793 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 795 6. Security Considerations 797 The algorithms defined in this document use the generic composition 798 of CBC encryption with HMAC authentication, with the encrypt-then-MAC 799 method defined in Section 4.3 of [BN00]. This method has sound and 800 well-understood security properties; for details, please see that 801 reference. Note that HMAC is a good pseudorandom function and is 802 "strongly unforgeable", and thus meets all of the security goals of 803 that reference. 805 Implementations of the encryption and decryption algorithms should 806 avoid side channels that would leak information about the secret key. 807 To avoid timing channels, the processing time should be independent 808 of the secret key. The Encrypt-then-MAC construction used in this 809 note has some inherent strength against timing attacks because, 810 during the decryption operation, the authentication check is computed 811 before the plaintext padding is processed. However, the security of 812 the algorithm still relies on the absence of timing channels in both 813 CBC and HMAC. Additionally, comparison between the authentication 814 tag T and the HMAC output should be done using a constant-time 815 operation. 817 During the decryption process, the inputs A and C are mapped into the 818 input of the HMAC algorithm. It is essential for security that each 819 possible input to the MAC algorithm corresponds unambiguously to 820 exactly one pair (A, C) of possible inputs. The fact that this 821 property holds can be verified as follows. The HMAC input is X = A 822 || C || len(A). Let (A,C) and (A',C') denote two distinct input 823 pairs, in which either 1) A != A' and C = C', 2) C != C and A = A', 824 or 3) both inequalities hold. We also let X' = A' || C' || len(A'). 825 In cases 1 and 2, X != X' follows immediately. In case 3, if len(A) 826 != len(A'), then X != X' directly. If len(A) = len(A'), then X != X 827 follows from the fact that the initial len(A) bits of X and X' must 828 be distinct. 830 There are security benefits to providing both confidentiality and 831 authentication in a single atomic operation, as done in this note. 832 This tight binding prevents subtle attacks such as the padding oracle 833 attack. 835 As with any block cipher mode of operation, the security of AES-CBC 836 degrades as the amount of data that is process increases. Each fixed 837 key value SHOULD NOT be used to protect more than 2^64 bytes of data. 838 This limit ensures that the AES-CBC algorithm will stay under the 839 birthday bound, i.e. because of the limit, it is unlikely that there 840 will be two AES plaintext inputs that are equal. (If this event 841 occurs, information about the colliding plaintexts is leaked, so it 842 is desirable to bound the amount of plaintext processed in order to 843 make it unlikely.) 845 7. Acknowledgements 847 Thanks are due to Matt Miller for his constructive feedback, Kelly 848 Burgin, Michael Peck, and Mike Jones for their suggestions and help, 849 and Jim Schaad, Rob Napier, James Manger, and David Jacobson for 850 their excellent review and suggestions. 852 8. References 854 8.1. Normative References 856 [FIPS186-2] 857 "FIPS 180-2: Secure Hash Standard,", Federal Information 858 Processing Standard 859 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 861 [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal 862 Information Processing Standard 863 (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. 865 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 866 Hashing for Message Authentication", RFC 2104, 867 February 1997. 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 873 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 874 RFC 4231, December 2005. 876 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 877 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 879 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 880 Encryption", RFC 5116, January 2008. 882 8.2. Informative References 884 [AP12] Paterson, K. and N. AlFardan, "Plaintext-Recovery Attacks 885 Against Datagram TLS", Network and Distributed System 886 Security Symposium (NDSS) 887 2012 http://www.isg.rhul.ac.uk/~kp/dtls.pdf, 2012. 889 [B96] Bellovin, S., "Problem areas for the IP security 890 protocols", Proceedings of the Sixth Usenix Unix Security 891 Symposium https://www.cs.columbia.edu/~smb/papers/ 892 badesp.pdf, 1996. 894 [BN00] "Authenticated encryption: Relations among notions and 895 analysis of the generic composition paradigm", Proceedings 896 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 897 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. 899 [CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux, 900 "Password Interception in a SSL/TLS Channel", CRYPT0 901 2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps, 902 2003. 904 [DP07] Paterson, K. and J. Degabriele, "Attacking the IPsec 905 Standards in Encryption-only Configurations", IEEE 906 Symposium on Privacy and 907 Security http://eprint.iacr.org/2007/125.pdf, 2007. 909 [DP10] Paterson, K. and J. Degabriele, "On the (in)security of 910 IPsec in MAC-then-encrypt configurations.", ACM Conference 911 on Computer and Communications Security (ACM CCS) 912 2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf, 913 2010. 915 [M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 916 Problems and Countermeasures", Web 917 Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004. 919 [PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 920 Does Matter: Attacks and Proofs for the TLS Record 921 Protocol", IEEE Symposium on Security and Privacy 922 2012 http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf, 923 January 2012. 925 [R02] "Authenticated encryption with Associated-Data", 926 Proceedings of the 2002 ACM Conference on Computer and 927 Communication Security (CCS'02), pp. 98-107, ACM Press, 928 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. 930 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 931 Requirements for Security", BCP 106, RFC 4086, June 2005. 933 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 934 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 936 [SP800-38] 937 Dworkin, M., "NIST Special Publication 800-38: 938 Recommendation for Block Cipher Modes of Operation", U.S. 939 National Institue of Standards and Technology http:// 940 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 942 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 943 Applications to SSL, IPSEC, WTLS ....", EUROCRYPT 2002 htt 944 p://lasecwww.epfl.ch/php_code/publications/ 945 search.php?ref=Vau02a, 2002. 947 [YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of 948 Unauthenticated Encryption: Kerberos Version 4", Network 949 and Distributed Security Symposium (NDSS) 950 2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf, 951 2004. 953 Appendix A. CBC Encryption and Decryption 955 The Cipher Block Chaining (CBC) mode of operation is defined in 956 Section 6.2 of [SP800-38]. This section recalls how that mode works, 957 for the convenience of the reader. The following notation is used: 959 K denotes the key of the underlying block cipher, 961 The function CIPHER(K, P) denotes the encryption of the block P 962 with the block cipher, where P contains exactly b bits, 964 The function CIPHER-INV(K, Q) denotes the decryption of the block 965 Q with the block cipher, where Q contains exactly b bits; this is 966 the inverse operation of CIPHER(), and CIPHER-INV(K, CIPHER(K, P)) 967 = P for all P and all K, 969 P_1, P_2, ... , P_n denotes the sequence of plaintext blocks, 970 where each block contains exactly b bits, 972 Q_1, Q_2, ... , Q_n denotes the sequence of ciphertext blocks, 973 where each block contains exactly b bits, 975 P_i and Q_i denote the ith blocks of the plaintext, and 977 IV denotes the initialization vector, which contains exactly b 978 bits. 980 The CBC encryption operation (denoted as CBC-ENC) takes as input a 981 sequence of n plaintext blocks and produces a sequence of n + 1 982 ciphertext blocks as follows: 984 IV = random 985 Q_i = / CIPHER(K, P_i XOR IV) if i=0, 986 \ CIPHER(K, P_i XOR Q_{i-1}) if i=1, 2, ... , n. 988 The operation CBC-ENC(K, P_1 || P_2 || ... || P_n) returns the value 989 IV || Q_1 || Q_2 || ... || Q_n. Note that the returned value is one 990 block longer than the input value. 992 The IV MUST be generated using a uniformly random process, or a 993 pseudorandom process with a cryptographic strength equivalent to that 994 of the underlying block cipher; see [RFC4086] for background on 995 random sources. It MUST NOT be predictable to an attacker; in 996 particular, it MUST NOT be set to the value of any previous 997 ciphertext blocks. 999 The CBC decryption operation (denoted as CBC-DEC) takes as input an 1000 octet string whose length is a multiple of b bits, decomposes it as 1001 IV || Q_1 || Q_2 || ... || Q_m, then produces a sequence of m 1002 plaintext blocks as follows: 1004 P_i = / CIPHER-INV(K, Q_i) XOR IV if i=1. 1005 \ CIPHER-INV(K, Q_i) XOR Q_{i-1} if i=2, ... , m. 1007 The operation CBC-DEC(K, IV || Q_1 || Q_2 || ... || Q_m) returns the 1008 value P_1 || P_2 || ... || P_m. 1010 Appendix B. Alternative Interface for Legacy Encoding 1012 In some scenarios, cryptographic data such as the ciphertext, 1013 initialization vector, and message authentication tag are encoded 1014 separately. To allow for the use of the algorithms defined in this 1015 document in such scenarios, this appendix describes an interface in 1016 which those data elements are discrete. New implementations SHOULD 1017 NOT use this interface, because it is incompatible with other 1018 authenticated encryption methods and is more complex; however, it MAY 1019 be useful in scenarios in which the separate encoding is already in 1020 use. 1022 The alternative interface is as follows. The inputs to the 1023 encryption operation the same as those defined in Section 2.1 (the 1024 secret key K, the plaintext P, the associated data A). The outputs 1025 of the encryption operation are: 1027 the initialization vector IV as defined in Appendix A, 1029 the ciphertext C, as defined in Appendix A, and 1031 the message authentication tag T, as defined in Section 2.1. 1033 The inputs to the decryption operation (in addition to K and A) are: 1035 the initialization vector IV as defined in Appendix A, 1037 the ciphertext C as defined in Appendix A, excluding the initial 1038 block C_0 (which is equal to the IV), and 1040 the message authentication tag T, as defined in Section 2.1. 1042 The output of the decryption operation are the same as that defined 1043 in Section 2.2 (either a plaintext value P or a special symbol FAIL 1044 that indicates that the inputs are not authentic). 1046 All processing other than the encoding and decoding of IV, C, and T 1047 is done as defined above. In particular, the IV is an output of the 1048 encryption operation, rather than an input. 1050 Authors' Addresses 1052 David McGrew 1053 Cisco Systems 1054 13600 Dulles Technology Drive 1055 Herndon, VA 20171 1056 US 1058 Email: mcgrew@cisco.com 1059 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1061 John Foley 1062 Cisco Systems 1063 7025-2 Kit Creek Road 1064 Research Triangle Park, NC 14987 1065 US 1067 Email: foleyj@cisco.com 1069 Kenny Paterson 1070 Royal Holloway, University of London 1071 TW20 0EX 1072 Egham, Surrey TW20 0EX 1073 UK 1075 Phone: +44 1784 414393 1076 Email: Kenny.Paterson@rhul.ac.uk 1077 URI: http://www.isg.rhul.ac.uk/~kp/