idnits 2.17.1 draft-mcgrew-aead-aes-cbc-hmac-sha2-03.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 (February 13, 2014) is 3725 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: August 17, 2014 K. Paterson 6 Royal Holloway, University of 7 London 8 February 13, 2014 10 Authenticated Encryption with AES-CBC and HMAC-SHA 11 draft-mcgrew-aead-aes-cbc-hmac-sha2-03.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 August 17, 2014. 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 . . . . . . . . . . . . . . . 15 76 5.3. AEAD_AES_256_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 17 77 5.4. AEAD_AES_256_CBC_HMAC_SHA512 . . . . . . . . . . . . . . . 18 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 83 Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 26 84 Appendix B. Alternative Interface for Legacy Encoding . . . . . . 28 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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 02 from version 01 are: 128 Added test cases for each of the five operational modes. 130 Added John as a coauthor. 132 Adds a legacy-style interface in Appendix B. 134 The changes of version 01 from version 00 are: 136 MIN_LEN_A and associated logic was eliminated. 138 Padding String (PS) typo corrected in Section 2.1. 140 Decryption Step 3 refers to the appropriate step in the encryption 141 process. 143 Random IV min-entropy clarified in Section 3. 145 HMAC keys are now the same size as the truncated output (128 or 146 256 bits). Previously, the HMAC keys were the same size as the 147 full hash output (256, 384, or 512 bits). 149 An algorithm based on the combination of AES-256 and HMAC-SHA-384 150 has been added, for compatibility with 151 draft-burgin-kerberos-aes-cbc-hmac-sha2. 153 The test cases in the previous version are no longer valid, and 154 thus have been removed. New test cases have been computed (and 155 the authors thank John Foley for this contribution) but have not 156 been included, pending confirmation from a second, independent 157 implementation. 159 1.2. Conventions Used In This Document 161 We use the following notational conventions. 163 CBC-ENC(X,P) denotes the CBC encryption of P using the cipher with 164 the key X 166 MAC(Y, M) denotes the application of the Message Authentication 167 Code (MAC) to the message M, using the key Y 169 The concatenation of two octet strings A and B is denoted as 170 A || B 172 len(X) denotes the number of bits in the string X, expressed as an 173 unsigned integer in network byte order. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 2. CBC-HMAC algorithms 181 This section defines CBC-HMAC, an algorithm based on the the encrypt- 182 then-MAC method defined in Section 4.3 of [BN00]. That method 183 constructs a randomized AEAD algorithm out of a randomized cipher, 184 such as a block cipher mode of operation that uses a random 185 initialization vector, and a MAC. 187 Section 2.1 and Section 2.2 define the CBC-HMAC encryption and 188 decryption algorithms, without specifying the particular block cipher 189 or hash function to be used. Section 2.4, Section 2.5, and 190 Section 2.7 define instances of CBC-HMAC that specify those details. 192 2.1. Encryption 194 We briefly recall the encryption interface defined in Section 2 of 195 [RFC5116]. The AEAD encryption algorithm takes as input four octet 196 strings: a secret key K, a plaintext P, associated data A, and a 197 nonce N. An authenticated ciphertext value is provided as output. 198 The data in the plaintext are encrypted and authenticated, and the 199 associated data are authenticated, but not encrypted. The key MUST 200 MUST be generated in a way that is uniformly random or pseudorandom; 201 guidance on random sources is provided in [RFC4086]. 203 In CBC-HMAC, the nonce N MUST be a zero-length string; a nonce is not 204 needed and is not used (see Section 4 for further background). 206 The CBC-HMAC encryption process is as follows, or uses an equivalent 207 set of steps: 209 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 210 input key K as follows. Each of these two keys is an octet 211 string. 213 MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in 214 order. 216 ENC_KEY consists of the final ENC_KEY_LEN octets of K, in 217 order. 219 Here we denote the number of octets in the MAC_KEY as 220 MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN; 221 the values of these parameters are specified by the AEAD 222 algorithms (in Section 2.4 and Section 2.5). The number of 223 octets in the input key K is the sum of MAC_KEY_LEN and 224 ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY 225 and ENC_KEY MUST NOT overlap. 227 2. Prior to CBC encryption, the plaintext P is padded by appending a 228 padding string PS to that data, to ensure that len(P || PS) is a 229 multiple of 128, as is needed for the CBC operation. The value 230 of PS is as follows: 232 PS = 01 if len(P) mod 128 = 120, 233 PS = 0202 if len(P) mod 128 = 112, 234 PS = 030303 if len(P) mod 128 = 104, 235 PS = 04040404 if len(P) mod 128 = 96, 236 PS = 0505050505 if len(P) mod 128 = 88, 237 PS = 060606060606 if len(P) mod 128 = 80, 238 PS = 07070707070707 if len(P) mod 128 = 72, 239 PS = 0808080808080808 if len(P) mod 128 = 64, 240 PS = 090909090909090909 if len(P) mod 128 = 56, 241 PS = 0A0A0A0A0A0A0A0A0A0A if len(P) mod 128 = 48, 242 PS = 0B0B0B0B0B0B0B0B0B0B0B if len(P) mod 128 = 40, 243 PS = 0C0C0C0C0C0C0C0C0C0C0C0C if len(P) mod 128 = 32, 244 PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) mod 128 = 24, 245 PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) mod 128 = 16, 246 PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F if len(P) mod 128 = 8, 247 PS = 10101010101010101010101010101010 if len(P) mod 128 = 0. 249 Note that padding MUST be added to the plaintext; if the number 250 of bits in P is a multiple of 128, then 128 bits of padding will 251 be added. 253 3. The plaintext and appended padding P || PS is CBC encrypted using 254 ENC_KEY as the key, as described in Appendix A. We denote the 255 ciphertext output from this step as S. 257 4. The octet string AL is equal to the number of bits in A expressed 258 as a 64-bit unsigned integer in network byte order. 260 5. A message authentication tag T is computed by applying HMAC 261 [RFC2104] to the following data, in order: 263 the associated data A, 265 the ciphertext S computed in the previous step, and 267 the octet string AL defined above. 269 The string MAC_KEY is used as the MAC key. We denote the output 270 of the MAC computed in this step as T. 272 6. The AEAD Ciphertext consists of the string S, with the string T 273 appended to it. This Ciphertext is returned as the output of the 274 AEAD encryption operation. 276 The encryption process can be illustrated as follows. Here P, A, and 277 C denote the AEAD plaintext, associated data, and ciphertext, 278 respectively. 280 MAC_KEY = initial MAC_KEY_LEN bytes of K 282 ENC_KEY = final ENC_KEY_LEN bytes of K 284 S = CBC-ENC(ENC_KEY, P || PS), 286 T = MAC(MAC_KEY, A || S || AL), 288 C = S || T. 290 2.2. Decryption 292 The authenticated decryption operation has four inputs: K, N, and A, 293 as defined above, and the Ciphertext C. As discussed above, N is an 294 empty string in AES-CBC and is not used below. It has only a single 295 output, either a plaintext value P or a special symbol FAIL that 296 indicates that the inputs are not authentic. The authenticated 297 decryption algorithm takes is as follows, or uses an equivalent set 298 of steps: 300 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 301 input key K as in Step 1 of Section 2.1. 303 2. The final T_LEN octets are stripped from C. Here T_LEN denotes 304 the number of octets in the MAC, which is a fixed parameter of 305 the AEAD algorithm. We denote the initial octets of C as S, and 306 denote the final T_LEN octets as T. 308 3. The integrity and authenticity of A and C are checked by 309 computing HMAC with the inputs as in Step 6 of Section 2.1. The 310 value T, from the previous step, is compared to the HMAC output, 311 using a comparison routine that takes constant time to execute. 312 If those values are identical, then A and C are considered valid, 313 and the processing continues. Otherwise, all of the data used in 314 the MAC validation are discarded, and the AEAD decryption 315 operation returns an indication that it failed, and the operation 316 halts. 318 4. The value S is CBC decrypted, as described in Appendix A, using 319 the value ENC_KEY is as the decryption key. 321 5. The padding string is stripped from the resulting plaintext. 322 Note that the length of PS can be inferred from the value of the 323 final octet of P || PS, if that value is between 01 and 10 324 (hexadecimal). If the final octet has a value outside that 325 range, then all of the data used in the processing of the message 326 is zeroized and discarded, and the AEAD decryption operation 327 returns an indication that it failed, and the operation halts. 329 6. The plaintext value is returned. 331 2.3. Length 333 The length of the ciphertext can be inferred from that of the 334 plaintext. The number L of octets in the ciphertext is given by 336 L = 16 * ( floor(M / 16) + 2) 338 where M denotes the number of octets in the plaintext, and the 339 function floor() rounds its argument down to the nearest integer. 340 This fact is useful to applications that need to reserve space for a 341 ciphertext within a message or data structure. 343 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 345 This algorithm is randomized; each invocation of the encrypt 346 operation makes use of a random value (the IV described in 347 Appendix A. It is based on the CBC-HMAC algorithm detailed above, 348 and uses the HMAC message authentication code [RFC2104] with the SHA- 349 256 hash function [FIPS186-2] to provide message authentication, with 350 the HMAC output truncated to 128 bits, corresponding to the HMAC-SHA- 351 256-128 algorithm defined in [RFC4868]. For encryption, it uses the 352 Advanced Encryption Standard (AES) [FIPS197] block cipher defined in 353 CBC mode. 355 The input key K is 48 octets long. 357 ENC_KEY_LEN is 16 octets. 359 The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16 360 octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by 361 stripping off the final 16 octets. Test cases for HMAC-SHA-256 are 362 provided in [RFC4231]. 364 The lengths of the inputs are restricted as follows: 366 K_LEN is 48 octets, 368 P_MAX is 2^64 - 1 octets, 370 A_MAX is 2^64 - 1 octets, 371 N_MIN and N_MAX are zero octets, 373 C_MAX is 2^64 + 47 octets. 375 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 377 AEAD_AES_192_CBC_HMAC_SHA_384 is based on 378 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 380 AES-192 is used instead of AES-128. 382 SHA-384 is used in HMAC instead of SHA-256. 384 ENC_KEY_LEN is 24 octets. 386 MAC_KEY_LEN is 24 octets. 388 The length of the input key K is 48 octets. 390 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 391 16 octets. 393 The input length restrictions are as for 394 AEAD_AES_CBC_128_HMAC_SHA_256. 396 2.6. AEAD_AES_256_CBC_HMAC_SHA_384 398 AEAD_AES_256_CBC_HMAC_SHA_384 is based on 399 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 401 AES-256 is used instead of AES-128. 403 SHA-384 is used in HMAC instead of SHA-256. 405 ENC_KEY_LEN is 32 octets. 407 MAC_KEY_LEN is 24 octets. 409 The length of the input key K is 56 octets. 411 The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 412 16 octets. 414 The input length restrictions are as for 415 AEAD_AES_CBC_128_HMAC_SHA_256. 417 2.7. AEAD_AES_256_CBC_HMAC_SHA_512 419 AEAD_AES_256_CBC_HMAC_SHA_512 is based on 420 AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences: 422 AES-256 is used instead of AES-128. 424 SHA-512 is used in HMAC instead of SHA-256. 426 ENC_KEY_LEN is 32 octets. 428 MAC_KEY_LEN is 32 octets. 430 The length of the input key K is 64 octets. 432 The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of 433 16 octets. 435 The input length restrictions are as for 436 AEAD_AES_CBC_128_HMAC_SHA_256. 438 2.8. Summary 440 The parameters of the CBC-HMAC algorithms are summarized in the 441 following table. 443 +-------------------------------+-------------+-------------+-------+ 444 | algorithm | ENC_KEY_LEN | MAC_KEY_LEN | T_LEN | 445 +-------------------------------+-------------+-------------+-------+ 446 | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 16 | 16 | 447 | | | | | 448 | AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 24 | 24 | 449 | | | | | 450 | AEAD_AES_256_CBC_HMAC_SHA_384 | 32 | 24 | 24 | 451 | | | | | 452 | AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 32 | 32 | 453 +-------------------------------+-------------+-------------+-------+ 455 3. Randomness Requirements 457 Each IV MUST be unpredictable to the adversary. It MAY be chosen 458 uniformly at random, in which case it SHOULD have min-entropy within 459 one bit of len(IV). Alternatively, it MAY be generated 460 pseudorandomly, using any method that provides the same level of 461 security as the block cipher in use. However, if a pseudorandom 462 method is used, that method MUST NOT make use of ENC_KEY or MAC_KEY. 464 4. Rationale 466 The CBC-HMAC AEAD algorithms defined in this note are intended to be 467 useful in the following applications: 469 systems that have the CBC and HMAC algorithms available, but do 470 not have dedicated AEAD algorithms such as GCM or CCM [RFC5116], 472 scenarios in which AEAD is useful, but it is undesirable to have 473 the application maintain a deterministic nonce; see Section 4 of 474 [RFC5116] for more background, 476 new systems, such as JSON Cryptography and W3C Web Crypto, which 477 can omit unauthenticated symmetric encryption altogether by 478 providing CBC and HMAC through an AEAD interface. 480 These algorithms are not intended to replace existing uses of AES-CBC 481 and HMAC, except in those circumstances where the existing use is not 482 sufficiently secure or sufficiently general-purpose. 484 The length of the associated data input A is included in the HMAC 485 input to ensure that the encrypter and the decrypter have the same 486 understanding of that length. Because of this, an attacker cannot 487 trick the receiver into interpreting the initial bytes of C as the 488 final bytes of A, or vice-versa. 490 The padding method used in this note is based on that of Privacy 491 Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS), 492 because it is implemented in many environments. 494 The encrypt-then-MAC method is used because of its better security 495 properties. It would be possible to define AEAD algorithms based on 496 the MAC-encode-encrypt (MEE) method that is used by the Transport 497 Layer Security (TLS) protocol [RFC5246]. That alternative would 498 provide more code-sharing opportunities for an implementation that is 499 co-resident with a TLS implementation. It is possible (but tricky) 500 to implement MEE in a way that provides good security, as was shown 501 in [PRS11]. But its negatives outweigh its positives; its security 502 is inadequate for some parameter choices, and it has proven to be 503 difficult to implement in a way that resists padding oracle and 504 related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For 505 future uses of CBC and HMAC, it is better to use encrypt-then-MAC." 507 This note uses HMAC-SHA-2 because it is widely deployed, it is 508 mandated in newer standards, and because SHA1 is being deprecated. 509 It has been recently announced that the SHA-3 standard will be based 510 on KECCAK, but this note does not incorporate that hash function. To 511 do so would be to speculate on the final form of the SHA-3 standard. 513 In addition, while the use of KECCAK as a hash function is 514 straightforward, there are multiple options for its use in 515 authenticated encryption. The focus of this note is the definition 516 of AEAD algorithms based on currently used cryptographic mechanisms, 517 so SHA-3 is out of scope. 519 5. Test Cases 521 5.1. AEAD_AES_128_CBC_HMAC_SHA256 523 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 524 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 526 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 528 ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 530 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 531 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 532 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 533 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 534 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 535 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 536 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 537 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 539 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 541 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 542 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 543 4b 65 72 63 6b 68 6f 66 66 73 545 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 547 AL = 00 00 00 00 00 00 01 50 549 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 550 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 551 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 552 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 553 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 554 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 555 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 556 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 557 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 558 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 560 T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 561 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 562 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 563 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 564 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 565 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 566 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 567 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 568 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 569 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 570 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 571 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 573 5.2. AEAD_AES_192_CBC_HMAC_SHA384 575 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 576 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 577 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 579 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 580 10 11 12 13 14 15 16 17 582 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 583 28 29 2a 2b 2c 2d 2e 2f 585 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 586 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 587 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 588 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 589 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 590 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 591 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 592 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 594 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 596 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 597 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 598 4b 65 72 63 6b 68 6f 66 66 73 600 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 602 AL = 00 00 00 00 00 00 01 50 603 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 604 ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 605 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 606 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 607 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 608 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 609 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 610 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 611 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 612 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 614 T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 615 75 16 80 39 cc c7 33 d7 617 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 618 ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 619 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 620 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 621 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 622 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 623 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 624 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 625 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 626 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 627 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 628 75 16 80 39 cc c7 33 d7 630 5.3. AEAD_AES_256_CBC_HMAC_SHA384 632 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 633 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 634 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 635 30 31 32 33 34 35 36 37 637 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 638 10 11 12 13 14 15 16 17 640 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 641 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 643 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 644 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 645 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 646 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 647 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 648 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 649 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 650 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 652 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 654 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 655 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 656 4b 65 72 63 6b 68 6f 66 66 73 658 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 660 AL = 00 00 00 00 00 00 01 50 662 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 663 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 664 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 665 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 666 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 667 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 668 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 669 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 670 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 671 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 673 T = dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 674 7f 1e 9a 54 1d 9c 23 e7 676 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 677 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 678 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 679 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 680 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 681 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 682 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 683 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 684 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 685 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 686 dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 687 7f 1e 9a 54 1d 9c 23 e7 689 5.4. AEAD_AES_256_CBC_HMAC_SHA512 691 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 692 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 693 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 694 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 696 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 697 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 699 ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 700 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 702 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 703 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 704 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 705 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 706 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 707 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 708 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 709 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 711 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 713 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 714 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 715 4b 65 72 63 6b 68 6f 66 66 73 717 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 719 AL = 00 00 00 00 00 00 01 50 720 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 721 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 722 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 723 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 724 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 725 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 726 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 727 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 728 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 729 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 731 T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 732 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 734 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 735 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 736 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 737 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 738 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 739 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 740 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 741 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 742 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 743 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 744 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 745 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 747 6. Security Considerations 749 The algorithms defined in this document use the generic composition 750 of CBC encryption with HMAC authentication, with the encrypt-then-MAC 751 method defined in Section 4.3 of [BN00]. This method has sound and 752 well-understood security properties; for details, please see that 753 reference. Note that HMAC is a good pseudorandom function and is 754 "strongly unforgeable", and thus meets all of the security goals of 755 that reference. 757 Implementations of the encryption and decryption algorithms should 758 avoid side channels that would leak information about the secret key. 759 To avoid timing channels, the processing time should be independent 760 of the secret key. The Encrypt-then-MAC construction used in this 761 note has some inherent strength against timing attacks because, 762 during the decryption operation, the authentication check is computed 763 before the plaintext padding is processed. However, the security of 764 the algorithm still relies on the absence of timing channels in both 765 CBC and HMAC. Additionally, comparison between the authentication 766 tag T and the HMAC output should be done using a constant-time 767 operation. 769 During the decryption process, the inputs A and C are mapped into the 770 input of the HMAC algorithm. It is essential for security that each 771 possible input to the MAC algorithm corresponds unambiguously to 772 exactly one pair (A, C) of possible inputs. The fact that this 773 property holds can be verified as follows. The HMAC input is X = A 774 || C || len(A). Let (A,C) and (A',C') denote two distinct input 775 pairs, in which either 1) A != A' and C = C', 2) C != C and A = A', 776 or 3) both inequalities hold. We also let X' = A' || C' || len(A'). 777 In cases 1 and 2, X != X' follows immediately. In case 3, if len(A) 778 != len(A'), then X != X' directly. If len(A) = len(A'), then X != X 779 follows from the fact that the initial len(A) bits of X and X' must 780 be distinct. 782 There are security benefits to providing both confidentiality and 783 authentication in a single atomic operation, as done in this note. 784 This tight binding prevents subtle attacks such as the padding oracle 785 attack. 787 As with any block cipher mode of operation, the security of AES-CBC 788 degrades as the amount of data that is process increases. Each fixed 789 key value SHOULD NOT be used to protect more than 2^64 bytes of data. 790 This limit ensures that the AES-CBC algorithm will stay under the 791 birthday bound, i.e. because of the limit, it is unlikely that there 792 will be two AES plaintext inputs that are equal. (If this event 793 occurs, information about the colliding plaintexts is leaked, so it 794 is desirable to bound the amount of plaintext processed in order to 795 make it unlikely.) 797 7. Acknowledgements 799 Thanks are due to Matt Miller for his constructive feedback, Kelly 800 Burgin, Michael Peck, and Mike Jones for their suggestions and help, 801 and Jim Schaad and Rob Napier for their excellent review and 802 suggestions. 804 8. References 806 8.1. Normative References 808 [FIPS186-2] 809 "FIPS 180-2: Secure Hash Standard,", Federal Information 810 Processing Standard 811 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 813 [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal 814 Information Processing Standard 815 (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. 817 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 818 Hashing for Message Authentication", RFC 2104, 819 February 1997. 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 825 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 826 RFC 4231, December 2005. 828 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 829 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 831 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 832 Encryption", RFC 5116, January 2008. 834 8.2. Informative References 836 [AP12] Paterson, K. and N. AlFardan, "Plaintext-Recovery Attacks 837 Against Datagram TLS", Network and Distributed System 838 Security Symposium (NDSS) 839 2012 http://www.isg.rhul.ac.uk/~kp/dtls.pdf, 2012. 841 [B96] Bellovin, S., "Problem areas for the IP security 842 protocols", Proceedings of the Sixth Usenix Unix Security 843 Symposium https://www.cs.columbia.edu/~smb/papers/ 844 badesp.pdf, 1996. 846 [BN00] "Authenticated encryption: Relations among notions and 847 analysis of the generic composition paradigm", Proceedings 848 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 849 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. 851 [CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux, 852 "Password Interception in a SSL/TLS Channel", CRYPT0 853 2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps, 854 2003. 856 [DP07] Paterson, K. and J. Degabriele, "Attacking the IPsec 857 Standards in Encryption-only Configurations", IEEE 858 Symposium on Privacy and 859 Security http://eprint.iacr.org/2007/125.pdf, 2007. 861 [DP10] Paterson, K. and J. Degabriele, "On the (in)security of 862 IPsec in MAC-then-encrypt configurations.", ACM Conference 863 on Computer and Communications Security (ACM CCS) 864 2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf, 865 2010. 867 [M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 868 Problems and Countermeasures", Web 869 Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004. 871 [PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 872 Does Matter: Attacks and Proofs for the TLS Record 873 Protocol", IEEE Symposium on Security and Privacy 874 2012 http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf, 875 January 2012. 877 [R02] "Authenticated encryption with Associated-Data", 878 Proceedings of the 2002 ACM Conference on Computer and 879 Communication Security (CCS'02), pp. 98-107, ACM Press, 880 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. 882 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 883 Requirements for Security", BCP 106, RFC 4086, June 2005. 885 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 886 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 888 [SP800-38] 889 Dworkin, M., "NIST Special Publication 800-38: 890 Recommendation for Block Cipher Modes of Operation", U.S. 891 National Institue of Standards and Technology http:// 892 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 894 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 895 Applications to SSL, IPSEC, WTLS ....", EUROCRYPT 2002 htt 896 p://lasecwww.epfl.ch/php_code/publications/ 897 search.php?ref=Vau02a, 2002. 899 [YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of 900 Unauthenticated Encryption: Kerberos Version 4", Network 901 and Distributed Security Symposium (NDSS) 902 2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf, 903 2004. 905 Appendix A. CBC Encryption and Decryption 907 The Cipher Block Chaining (CBC) mode of operation is defined in 908 Section 6.2 of [SP800-38]. This section recalls how that mode works, 909 for the convenience of the reader. The following notation is used: 911 K denotes the key of the underlying block cipher, 913 The function CIPHER(K, P) denotes the encryption of the block P 914 with the block cipher, where P contains exactly b bits, 916 The function CIPHER-INV(K, C) denotes the decryption of the block 917 C with the block cipher, where C contains exactly b bits; this is 918 the inverse operation of CIPHER(), and CIPHER-INV(K, CIPHER(K, P)) 919 = P for all P and all K, 921 P_1, P_2, ... , P_n denotes the sequence of plaintext blocks, 922 where each block contains exactly b bits, 924 C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext 925 blocks, where each block contains exactly b bits, 927 P_i and C_i denote the ith blocks of the plaintext, and 929 IV denotes the initialization vector, which contains exactly b 930 bits. 932 The CBC encryption operation (denoted as CBC-ENC) takes as input a 933 sequence of n plaintext blocks and produces a sequence of n + 1 934 ciphertext blocks as follows: 936 IV = random 937 C_i = / IV if i=0, 938 \ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n. 940 CBC-ENC(K, P_1 || P_2 || ... || P_n) returns the value C_0 || C_1 || 941 C_2 || ... || C_n. Note that the returned value is one block longer 942 than the input value, and that C_0 = IV. 944 The IV MUST be generated using a uniformly random process, or a 945 pseudorandom process with a cryptographic strength equivalent to that 946 of the underlying block cipher; see [RFC4086] for background on 947 random sources. It MUST NOT be predictable to an attacker; in 948 particular, it MUST NOT be set to the value of any previous 949 ciphertext blocks. 951 The CBC decryption operation (denoted as CBC-DEC) takes as input a 952 sequence of m ciphertext blocks and produces a sequence of m-1 953 plaintext blocks as follows: 955 P_i = CIPHER-INV(K, C_i) XOR C_{i-1} for i=1, 2, ... , n. 957 The initial block C_0 corresponds to the initialization vector. 959 Appendix B. Alternative Interface for Legacy Encoding 961 In some scenarios, cryptographic data such as the ciphertext, 962 initialization vector, and message authentication tag are encoded 963 separately. To allow for the use of the algorithms defined in this 964 document in such scenarios, this appendix describes an interface in 965 which those data elements are discrete. New implementations SHOULD 966 NOT use this interface, because it is incompatible with other 967 authenticated encryption methods and is more complex; however, it MAY 968 be useful in scenarios in which the separate encoding is already in 969 use. 971 The alternative interface is as follows. The inputs to the 972 encryption operation the same as those defined in Section 2.1 (the 973 secret key K, the plaintext P, the associated data A). The outputs 974 of the encryption operation are: 976 the initialization vector IV as defined in Appendix A, 978 the ciphertext C, as defined in Appendix A, and 980 the message authentication tag T, as defined in Section 2.1. 982 The inputs to the decryption operation are: 984 the initialization vector IV as defined in Appendix A, 986 the ciphertext C, as defined in Appendix A, and 988 the message authentication tag T, as defined in Section 2.1. 990 The output of the decryption operation is the same as that defined in 991 Section 2.2 (either a plaintext value P or a special symbol FAIL that 992 indicates that the inputs are not authentic). 994 All processing other than the encoding and decoding of IV, C, and T 995 is done as defined above. In particular, the IV is an output of the 996 encryption operation, rather than an input. 998 Authors' Addresses 1000 David McGrew 1001 Cisco Systems 1002 13600 Dulles Technology Drive 1003 Herndon, VA 20171 1004 US 1006 Email: mcgrew@cisco.com 1007 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1009 John Foley 1010 Cisco Systems 1011 7025-2 Kit Creek Road 1012 Research Triangle Park, NC 14987 1013 US 1015 Email: foleyj@cisco.com 1017 Kenny Paterson 1018 Royal Holloway, University of London 1019 TW20 0EX 1020 Egham, Surrey TW20 0EX 1021 UK 1023 Phone: +44 1784 414393 1024 Email: Kenny.Paterson@rhul.ac.uk 1025 URI: http://www.isg.rhul.ac.uk/~kp/