idnits 2.17.00 (12 Aug 2021) /tmp/idnits26482/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.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 14, 2014) is 3017 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 18, 2014 K. Paterson 6 Royal Holloway, University of 7 London 8 February 14, 2014 10 Authenticated Encryption with AES-CBC and HMAC-SHA 11 draft-mcgrew-aead-aes-cbc-hmac-sha2-04.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 18, 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 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 in CBC 353 mode. 355 The input key K is 32 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 32 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 algorithms in this note truncate the HMAC output to half of the 485 size of the output of the underlying hash function. This size is the 486 recommended minimum (see Section 5 of [RFC2104]), and this parameter 487 choice has withstood the test of time. 489 The length of the associated data input A is included in the HMAC 490 input to ensure that the encrypter and the decrypter have the same 491 understanding of that length. Because of this, an attacker cannot 492 trick the receiver into interpreting the initial bytes of C as the 493 final bytes of A, or vice-versa. 495 The padding method used in this note is based on that of Privacy 496 Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS), 497 because it is implemented in many environments. 499 The encrypt-then-MAC method is used because of its better security 500 properties. It would be possible to define AEAD algorithms based on 501 the MAC-encode-encrypt (MEE) method that is used by the Transport 502 Layer Security (TLS) protocol [RFC5246]. That alternative would 503 provide more code-sharing opportunities for an implementation that is 504 co-resident with a TLS implementation. It is possible (but tricky) 505 to implement MEE in a way that provides good security, as was shown 506 in [PRS11]. But its negatives outweigh its positives; its security 507 is inadequate for some parameter choices, and it has proven to be 508 very difficult to implement in a way that resists padding oracle and 509 related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For 510 future uses of CBC and HMAC, it is better to use encrypt-then-MAC. 512 This note uses HMAC-SHA-2 because it is widely deployed, it is 513 mandated in newer standards, and because SHA1 is being deprecated. 514 It has been recently announced that the SHA-3 standard will be based 515 on KECCAK, but this note does not incorporate that hash function. To 516 do so would be to speculate on the final form of the SHA-3 standard. 517 In addition, while the use of KECCAK as a hash function is 518 straightforward, there are multiple options for its use in 519 authenticated encryption. The focus of this note is the definition 520 of AEAD algorithms based on currently used cryptographic mechanisms, 521 so SHA-3 is out of scope. 523 5. Test Cases 525 5.1. AEAD_AES_128_CBC_HMAC_SHA256 527 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 528 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 530 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 532 ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 534 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 535 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 536 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 537 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 538 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 539 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 540 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 541 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 543 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 545 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 546 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 547 4b 65 72 63 6b 68 6f 66 66 73 549 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 551 AL = 00 00 00 00 00 00 01 50 553 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 554 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 555 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 556 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 557 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 558 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 559 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 560 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 561 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 562 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 564 T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 565 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 566 c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 567 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 568 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 569 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 570 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 571 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 572 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 573 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 574 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 575 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 577 5.2. AEAD_AES_192_CBC_HMAC_SHA384 579 K = 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 18 19 1a 1b 1c 1d 1e 1f 581 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 583 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 584 10 11 12 13 14 15 16 17 586 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 587 28 29 2a 2b 2c 2d 2e 2f 589 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 590 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 591 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 592 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 593 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 594 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 595 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 596 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 598 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 600 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 601 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 602 4b 65 72 63 6b 68 6f 66 66 73 604 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 606 AL = 00 00 00 00 00 00 01 50 607 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 608 ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 609 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 610 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 611 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 612 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 613 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 614 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 615 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 616 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 618 T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 619 75 16 80 39 cc c7 33 d7 621 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 622 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 631 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 632 75 16 80 39 cc c7 33 d7 634 5.3. AEAD_AES_256_CBC_HMAC_SHA384 636 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 637 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 638 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 639 30 31 32 33 34 35 36 37 641 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 642 10 11 12 13 14 15 16 17 644 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 645 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 647 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 648 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 649 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 650 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 651 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 652 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 653 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 654 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 656 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 658 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 659 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 660 4b 65 72 63 6b 68 6f 66 66 73 662 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 664 AL = 00 00 00 00 00 00 01 50 666 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 667 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 668 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 669 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 670 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 671 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 672 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 673 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 674 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 675 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 677 T = dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 678 7f 1e 9a 54 1d 9c 23 e7 680 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 681 89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3 682 60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e 683 58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5 684 c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21 685 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 686 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 687 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 688 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 689 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 690 dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 691 7f 1e 9a 54 1d 9c 23 e7 693 5.4. AEAD_AES_256_CBC_HMAC_SHA512 695 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 696 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 697 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 698 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 700 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 701 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 703 ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 704 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 706 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 707 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 708 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 709 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 710 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 711 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 712 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 713 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 715 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 717 A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 718 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 719 4b 65 72 63 6b 68 6f 66 66 73 721 PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 723 AL = 00 00 00 00 00 00 01 50 724 S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 725 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 726 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 727 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 728 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 729 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 730 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 731 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 732 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 733 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 735 T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 736 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 738 C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 739 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 740 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 741 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 742 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 743 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 744 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 745 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 746 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 747 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 748 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 749 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 751 6. Security Considerations 753 The algorithms defined in this document use the generic composition 754 of CBC encryption with HMAC authentication, with the encrypt-then-MAC 755 method defined in Section 4.3 of [BN00]. This method has sound and 756 well-understood security properties; for details, please see that 757 reference. Note that HMAC is a good pseudorandom function and is 758 "strongly unforgeable", and thus meets all of the security goals of 759 that reference. 761 Implementations of the encryption and decryption algorithms should 762 avoid side channels that would leak information about the secret key. 763 To avoid timing channels, the processing time should be independent 764 of the secret key. The Encrypt-then-MAC construction used in this 765 note has some inherent strength against timing attacks because, 766 during the decryption operation, the authentication check is computed 767 before the plaintext padding is processed. However, the security of 768 the algorithm still relies on the absence of timing channels in both 769 CBC and HMAC. Additionally, comparison between the authentication 770 tag T and the HMAC output should be done using a constant-time 771 operation. 773 During the decryption process, the inputs A and C are mapped into the 774 input of the HMAC algorithm. It is essential for security that each 775 possible input to the MAC algorithm corresponds unambiguously to 776 exactly one pair (A, C) of possible inputs. The fact that this 777 property holds can be verified as follows. The HMAC input is X = A 778 || C || len(A). Let (A,C) and (A',C') denote two distinct input 779 pairs, in which either 1) A != A' and C = C', 2) C != C and A = A', 780 or 3) both inequalities hold. We also let X' = A' || C' || len(A'). 781 In cases 1 and 2, X != X' follows immediately. In case 3, if len(A) 782 != len(A'), then X != X' directly. If len(A) = len(A'), then X != X 783 follows from the fact that the initial len(A) bits of X and X' must 784 be distinct. 786 There are security benefits to providing both confidentiality and 787 authentication in a single atomic operation, as done in this note. 788 This tight binding prevents subtle attacks such as the padding oracle 789 attack. 791 As with any block cipher mode of operation, the security of AES-CBC 792 degrades as the amount of data that is process increases. Each fixed 793 key value SHOULD NOT be used to protect more than 2^64 bytes of data. 794 This limit ensures that the AES-CBC algorithm will stay under the 795 birthday bound, i.e. because of the limit, it is unlikely that there 796 will be two AES plaintext inputs that are equal. (If this event 797 occurs, information about the colliding plaintexts is leaked, so it 798 is desirable to bound the amount of plaintext processed in order to 799 make it unlikely.) 801 7. Acknowledgements 803 Thanks are due to Matt Miller for his constructive feedback, Kelly 804 Burgin, Michael Peck, and Mike Jones for their suggestions and help, 805 and Jim Schaad, Rob Napier, James Manger, and David Jacobson for 806 their excellent review and suggestions. 808 8. References 810 8.1. Normative References 812 [FIPS186-2] 813 "FIPS 180-2: Secure Hash Standard,", Federal Information 814 Processing Standard 815 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 817 [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal 818 Information Processing Standard 819 (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. 821 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 822 Hashing for Message Authentication", RFC 2104, 823 February 1997. 825 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 826 Requirement Levels", BCP 14, RFC 2119, March 1997. 828 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 829 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 830 RFC 4231, December 2005. 832 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 833 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 835 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 836 Encryption", RFC 5116, January 2008. 838 8.2. Informative References 840 [AP12] Paterson, K. and N. AlFardan, "Plaintext-Recovery Attacks 841 Against Datagram TLS", Network and Distributed System 842 Security Symposium (NDSS) 843 2012 http://www.isg.rhul.ac.uk/~kp/dtls.pdf, 2012. 845 [B96] Bellovin, S., "Problem areas for the IP security 846 protocols", Proceedings of the Sixth Usenix Unix Security 847 Symposium https://www.cs.columbia.edu/~smb/papers/ 848 badesp.pdf, 1996. 850 [BN00] "Authenticated encryption: Relations among notions and 851 analysis of the generic composition paradigm", Proceedings 852 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 853 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. 855 [CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux, 856 "Password Interception in a SSL/TLS Channel", CRYPT0 857 2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps, 858 2003. 860 [DP07] Paterson, K. and J. Degabriele, "Attacking the IPsec 861 Standards in Encryption-only Configurations", IEEE 862 Symposium on Privacy and 863 Security http://eprint.iacr.org/2007/125.pdf, 2007. 865 [DP10] Paterson, K. and J. Degabriele, "On the (in)security of 866 IPsec in MAC-then-encrypt configurations.", ACM Conference 867 on Computer and Communications Security (ACM CCS) 868 2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf, 869 2010. 871 [M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 872 Problems and Countermeasures", Web 873 Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004. 875 [PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 876 Does Matter: Attacks and Proofs for the TLS Record 877 Protocol", IEEE Symposium on Security and Privacy 878 2012 http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf, 879 January 2012. 881 [R02] "Authenticated encryption with Associated-Data", 882 Proceedings of the 2002 ACM Conference on Computer and 883 Communication Security (CCS'02), pp. 98-107, ACM Press, 884 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. 886 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 887 Requirements for Security", BCP 106, RFC 4086, June 2005. 889 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 890 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 892 [SP800-38] 893 Dworkin, M., "NIST Special Publication 800-38: 894 Recommendation for Block Cipher Modes of Operation", U.S. 895 National Institue of Standards and Technology http:// 896 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 898 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 899 Applications to SSL, IPSEC, WTLS ....", EUROCRYPT 2002 htt 900 p://lasecwww.epfl.ch/php_code/publications/ 901 search.php?ref=Vau02a, 2002. 903 [YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of 904 Unauthenticated Encryption: Kerberos Version 4", Network 905 and Distributed Security Symposium (NDSS) 906 2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf, 907 2004. 909 Appendix A. CBC Encryption and Decryption 911 The Cipher Block Chaining (CBC) mode of operation is defined in 912 Section 6.2 of [SP800-38]. This section recalls how that mode works, 913 for the convenience of the reader. The following notation is used: 915 K denotes the key of the underlying block cipher, 917 The function CIPHER(K, P) denotes the encryption of the block P 918 with the block cipher, where P contains exactly b bits, 920 The function CIPHER-INV(K, C) denotes the decryption of the block 921 C with the block cipher, where C contains exactly b bits; this is 922 the inverse operation of CIPHER(), and CIPHER-INV(K, CIPHER(K, P)) 923 = P for all P and all K, 925 P_1, P_2, ... , P_n denotes the sequence of plaintext blocks, 926 where each block contains exactly b bits, 928 C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext 929 blocks, where each block contains exactly b bits, 931 P_i and C_i denote the ith blocks of the plaintext, and 933 IV denotes the initialization vector, which contains exactly b 934 bits. 936 The CBC encryption operation (denoted as CBC-ENC) takes as input a 937 sequence of n plaintext blocks and produces a sequence of n + 1 938 ciphertext blocks as follows: 940 IV = random 941 C_i = / IV if i=0, 942 \ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n. 944 CBC-ENC(K, P_1 || P_2 || ... || P_n) returns the value C_0 || C_1 || 945 C_2 || ... || C_n. Note that the returned value is one block longer 946 than the input value, and that C_0 = IV. 948 The IV MUST be generated using a uniformly random process, or a 949 pseudorandom process with a cryptographic strength equivalent to that 950 of the underlying block cipher; see [RFC4086] for background on 951 random sources. It MUST NOT be predictable to an attacker; in 952 particular, it MUST NOT be set to the value of any previous 953 ciphertext blocks. 955 The CBC decryption operation (denoted as CBC-DEC) takes as input a 956 sequence of m ciphertext blocks and produces a sequence of m-1 957 plaintext blocks as follows: 959 P_i = CIPHER-INV(K, C_i) XOR C_{i-1} for i=1, 2, ... , n. 961 The initial block C_0 corresponds to the initialization vector. 963 Appendix B. Alternative Interface for Legacy Encoding 965 In some scenarios, cryptographic data such as the ciphertext, 966 initialization vector, and message authentication tag are encoded 967 separately. To allow for the use of the algorithms defined in this 968 document in such scenarios, this appendix describes an interface in 969 which those data elements are discrete. New implementations SHOULD 970 NOT use this interface, because it is incompatible with other 971 authenticated encryption methods and is more complex; however, it MAY 972 be useful in scenarios in which the separate encoding is already in 973 use. 975 The alternative interface is as follows. The inputs to the 976 encryption operation the same as those defined in Section 2.1 (the 977 secret key K, the plaintext P, the associated data A). The outputs 978 of the encryption operation are: 980 the initialization vector IV as defined in Appendix A, 982 the ciphertext C, as defined in Appendix A, and 984 the message authentication tag T, as defined in Section 2.1. 986 The inputs to the decryption operation (in addition to K and A) are: 988 the initialization vector IV as defined in Appendix A, 990 the ciphertext C as defined in Appendix A, excluding the initial 991 block C_0 (which is equal to the IV), and 993 the message authentication tag T, as defined in Section 2.1. 995 The output of the decryption operation are the same as that defined 996 in Section 2.2 (either a plaintext value P or a special symbol FAIL 997 that indicates that the inputs are not authentic). 999 All processing other than the encoding and decoding of IV, C, and T 1000 is done as defined above. In particular, the IV is an output of the 1001 encryption operation, rather than an input. 1003 Authors' Addresses 1005 David McGrew 1006 Cisco Systems 1007 13600 Dulles Technology Drive 1008 Herndon, VA 20171 1009 US 1011 Email: mcgrew@cisco.com 1012 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1014 John Foley 1015 Cisco Systems 1016 7025-2 Kit Creek Road 1017 Research Triangle Park, NC 14987 1018 US 1020 Email: foleyj@cisco.com 1022 Kenny Paterson 1023 Royal Holloway, University of London 1024 TW20 0EX 1025 Egham, Surrey TW20 0EX 1026 UK 1028 Phone: +44 1784 414393 1029 Email: Kenny.Paterson@rhul.ac.uk 1030 URI: http://www.isg.rhul.ac.uk/~kp/