idnits 2.17.1 draft-raeburn-krb-rijndael-krb-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 8) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 42 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2005) is 7008 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. 'AC' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' == Outdated reference: A later version (-07) exists of draft-ietf-krb-wg-crypto-01 ** Obsolete normative reference: RFC 2898 (ref. 'PKCS5') (Obsoleted by RFC 8018) ** Downref: Normative reference to an Informational RFC: RFC 2040 (ref. 'RC5') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Obsolete informational reference (is this intentional?): RFC 3211 (ref. 'PECMS') (Obsoleted by RFC 3369, RFC 3370) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kerberos Working Group K. Raeburn 2 Document: draft-raeburn-krb-rijndael-krb-07.txt MIT 3 July 19, 2004 4 expires January 19, 2005 6 AES Encryption for Kerberos 5 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. Internet-Drafts are working documents of 12 the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. Internet-Drafts are draft documents 15 valid for a maximum of six months and may be updated, replaced, or 16 obsoleted by other documents at any time. It is inappropriate to use 17 Internet-Drafts as reference material or to cite them other than as 18 "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 28 The US National Institute of Standards and Technology has chosen a 29 new Advanced Encryption Standard, which is significantly faster and 30 (it is believed) more secure than the old DES algorithm. This 31 document is a specification for the addition of this algorithm to the 32 Kerberos cryptosystem suite. 34 1. Introduction 36 This document defines encryption key and checksum types for Kerberos 37 5 using the AES algorithm recently chosen by NIST. These new types 38 support 128-bit block encryption, and key sizes of 128 or 256 bits. 40 Using the "simplified profile" of [KCRYPTO], we can define a pair of 41 encryption and checksum schemes. AES is used with cipher text 42 stealing to avoid message expansion, and SHA-1 [SHA1] is the 43 associated checksum function. 45 2. Conventions Used in this Document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 51 3. Protocol Key Representation 53 The profile in [KCRYPTO] treats keys and random octet strings as 54 conceptually different. But since the AES key space is dense, we can 55 use any bit string of appropriate length as a key. We use the byte 56 representation for the key described in [AES], where the first bit of 57 the bit string is the high bit of the first byte of the byte string 58 (octet string) representation. 60 4. Key Generation From Pass Phrases or Random Data 62 Given the above format for keys, we can generate keys from the 63 appropriate amounts of random data (128 or 256 bits) by simply 64 copying the input string. 66 To generate an encryption key from a pass phrase and salt string, we 67 use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters 68 indicated below, to generate an intermediate key (of the same length 69 as the desired final key), which is then passed into the DK function 70 with the 8-octet ASCII string "kerberos" as is done for des3-cbc- 71 hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function 72 produces a "random octet string", hence the application of the 73 random-to-key function even though it's effectively a simple identity 74 operation.) The resulting key is the user's long-term key for use 75 with the encryption algorithm in question. 77 tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) 78 key = DK(tkey, "kerberos") 80 The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the 81 passphrase and salt, as described in Appendix B.1 to PKCS#5. 83 The number of iterations is specified by the string-to-key parameters 84 supplied. The parameter string is four octets indicating an unsigned 85 number in big-endian order. This is the number of iterations to be 86 performed. If the value is 00 00 00 00, the number of iterations to 87 be performed is 4294967296 (2**32). (Thus the minimum expressable 88 iteration count is 1.) 90 For environments where slower hardware is the norm, implementations 91 of protocols such as Kerberos may wish to limit the number of 92 iterations to prevent a spoofed response supplied by an attacker from 93 consuming lots of client-side CPU time; if such a limit is 94 implemented, it SHOULD be no less than 50000. Even for environments 95 with fast hardware, 4 billion iterations is likely to take a fairly 96 long time; much larger bounds might still be enforced, and it might 97 be wise for implementations to permit interruption of this operation 98 by the user if the environment allows for it. 100 If the string-to-key parameters are not supplied, the value used is 101 00 00 10 00 (decimal 4096, indicating 4096 iterations). 103 Note that this is not a requirement, nor even a recommendation, for 104 this value to be used in "optimistic preauthentication" (e.g., 105 attempting timestamp-based preauthentication using the user's long- 106 term key, without having first communicated with the KDC) in the 107 absence of additional information, nor as a default value for sites 108 to use for their principals' long-term keys in their Kerberos 109 database. It is simply the interpretation of the absence of the 110 string-to-key parameter field when the KDC has had an opportunity to 111 provide it. 113 Sample test vectors are given in appendix B. 115 5. Cipher Text Stealing 117 Cipher block chaining is used to encrypt messages. Unlike previous 118 Kerberos cryptosystems, we use cipher text stealing to handle the 119 possibly partial final block of the message. 121 Cipher text stealing is described on pages 195-196 of [AC], and 122 section 8 of [RC5]; it has the advantage that no message expansion is 123 done during encryption of messages of arbitrary sizes as is typically 124 done in CBC mode with padding. Some errata for [RC5] are listed in 125 appendix A, and are considered part of the cipher text stealing 126 technique as used here. 128 Cipher text stealing, as defined in [RC5], assumes that more than one 129 block of plain text is available. If exactly one block is to be 130 encrypted, that block is simply encrypted with AES (also known as ECB 131 mode). Input of less than one block is padded at the end to one 132 block; the values of the padding bits are unspecified. 133 (Implementations MAY use all-zero padding, but protocols MUST NOT 134 rely on the result being deterministic. Implementations MAY use 135 random padding, but protocols MUST NOT rely on the result not being 136 deterministic. Note that in most cases, the Kerberos encryption 137 profile will add a random confounder independent of this padding.) 139 For consistency, cipher text stealing is always used for the last two 140 blocks of the data to be encrypted, as in [RC5]. If the data length 141 is a multiple of the block size, this is equivalent to plain CBC mode 142 with the last two cipher text blocks swapped. 144 A test vector is given in appendix B. 146 The initial vector carried out from one encryption for use in a 147 following encryption is the next to last block of the encryption 148 output; this is the encrypted form of the last plaintext block. When 149 decrypting, the next to last block of the supplied ciphertext is 150 carried forward as the next initial vector. 152 6. Kerberos Algorithm Profile Parameters 154 This is a summary of the parameters to be used with the simplified 155 algorithm profile described in [KCRYPTO]: 157 +--------------------------------------------------------------------+ 158 | protocol key format 128- or 256-bit string | 159 | | 160 | string-to-key function PBKDF2+DK with variable | 161 | iteration count (see | 162 | above) | 163 | | 164 | default string-to-key parameters 00 00 10 00 | 165 | | 166 | key-generation seed length key size | 167 | | 168 | random-to-key function identity function | 169 | | 170 | hash function, H SHA-1 | 171 | | 172 | HMAC output size, h 12 octets (96 bits) | 173 | | 174 | message block size, m 1 octet | 175 | | 176 | encryption/decryption functions, AES in CBC-CTS mode | 177 | E and D (cipher block size 16 | 178 | octets), with next to | 179 | last block as CBC-style | 180 | ivec | 181 +--------------------------------------------------------------------+ 183 Using this profile with each key size gives us two each of encryption 184 and checksum algorithm definitions. 186 7. Assigned Numbers 188 The following encryption type numbers are assigned: 190 +--------------------------------------------------------------------+ 191 | encryption types | 192 +--------------------------------------------------------------------+ 193 | type name etype value key size | 194 +--------------------------------------------------------------------+ 195 | aes128-cts-hmac-sha1-96 17 128 | 196 | aes256-cts-hmac-sha1-96 18 256 | 197 +--------------------------------------------------------------------+ 199 The following checksum type numbers are assigned: 201 +--------------------------------------------------------------------+ 202 | checksum types | 203 +--------------------------------------------------------------------+ 204 | type name sumtype value length | 205 +--------------------------------------------------------------------+ 206 | hmac-sha1-96-aes128 15 96 | 207 | hmac-sha1-96-aes256 16 96 | 208 +--------------------------------------------------------------------+ 210 These checksum types will be used with the corresponding encryption 211 types defined above. 213 8. Security Considerations 215 This new algorithm has not been around long enough to receive the 216 decades of intense analysis that DES has received. It is possible 217 that some weakness exists that has not been found by the 218 cryptographers analyzing these algorithms before and during the AES 219 selection process. 221 The use of the HMAC function has drawbacks for certain pass phrase 222 lengths. For example, a pass phrase longer than the hash function 223 block size (64 bytes, for SHA-1) is hashed to a smaller size (20 224 bytes) before applying the main HMAC algorithm. However, entropy is 225 generally sparse in pass phrases, especially in long ones, so this 226 may not be a problem in the rare cases of users with long pass 227 phrases. 229 Also, generating a 256-bit key from a pass phrase of any length may 230 be deceptive, since the effective entropy in pass-phrase-derived key 231 cannot be nearly that large, given the properties of the string-to- 232 key function described here. 234 The iteration count in PBKDF2 appears to be useful primarily as a 235 constant multiplier for the amount of work required for an attacker 236 using brute-force methods. Unfortunately, it also multiplies, by the 237 same amount, the work needed by a legitimate user with a valid 238 password. Thus the work factor imposed on an attacker (who may have 239 many powerful workstations at his disposal) must be balanced against 240 the work factor imposed on the legitimate user (who may have a PDA or 241 cell phone); the available computing power on either side increases 242 as time goes on, as well. A better way to deal with the brute-force 243 attack is through preauthentication mechanisms that provide better 244 protection of the user's long-term key. Use of such mechanisms is 245 out of scope for this document. 247 If a site does wish to use this means of protection against a brute- 248 force attack, the iteration count should be chosen based on the 249 facilities available to both attacker and legitimate user, and the 250 amount of work the attacker should be required to perform to acquire 251 the key or password. 253 As an example: 255 The author's tests on a 2GHz Pentium 4 system indicated that in 256 one second, nearly 90000 iterations could be done, producing a 257 256-bit key. This was using the SHA-1 assembly implementation 258 from OpenSSL, and a pre-release version of the PBKDF2 code for 259 MIT's Kerberos package, on a single system. No attempt was made 260 to do multiple hashes in parallel, so we assume an attacker doing 261 so can probably do at least 100000 iterations per second -- 262 rounded up to 2**17, for ease of calculation. For simplicity, we 263 also assume the final AES encryption step costs nothing. 265 Paul Leach estimates [LEACH] that a password-cracking dictionary 266 may have on the order of 2**21 entries, with capitalization, 267 punctuation, and other variations contributing perhaps a factor of 268 2**11, giving a ballpark estimate of 2**32. 270 Thus, for a known iteration count N and a known salt string, an 271 attacker with some number of computers comparable to the author's 272 would need roughly N*2**15 CPU seconds to convert the entire 273 dictionary plus variations into keys. 275 An attacker using a dozen such computers for a month would have 276 roughly 2**25 CPU seconds available. So using 2**12 (4096) 277 iterations would mean an attacker with a dozen such computers 278 dedicated to a brute-force attack against a single key (actually, 279 any password-derived keys sharing the same salt and iteration 280 count) would process all the variations of the dictionary entries 281 in four months, and on average, would likely find the user's 282 password in two months. 284 Thus, if this form of attack is of concern, an iteration count a 285 few orders of magnitude higher should be chosen, and users should 286 be required to change their passwords every few months. Perhaps 287 several orders of magnitude, since many users will tend to use the 288 shorter and simpler passwords (as much as they can get away with, 289 given a site's password quality checks) that the attacker would 290 likely try first. 292 Since this estimate is based on currently available CPU power, the 293 iteration counts used for this mode of defense should be increased 294 over time, at perhaps 40%-60% each year or so. 296 Note that if the attacker has a large amount of storage available, 297 intermediate results could be cached, saving a lot of work for the 298 next attack with the same salt and a greater number of iterations 299 than had been run at the point where the intermediate results were 300 saved. Thus, it would be wise to generate a new random salt 301 string when passwords are changed. The default salt string, 302 derived from the principal name, only protects against the use of 303 one dictionary of keys against multiple users. 305 If the PBKDF2 iteration count can be spoofed by an intruder on the 306 network, and the limit on the accepted iteration count is very high, 307 the intruder may be able to introduce a form of denial of service 308 attack against the client by sending a very high iteration count, 309 causing the client to spend a great deal of CPU time computing an 310 incorrect key. 312 An intruder spoofing the KDC reply, providing a low iteration count, 313 and reading the client's reply from the network may be able to reduce 314 the work needed in the brute-force attack outlined above. Thus, 315 implementations may wish to enforce lower bounds on the number of 316 iterations that will be used. 318 Since threat models and typical end-user equipment will vary widely 319 from site to site, allowing site-specific configuration of such 320 bounds is recommended. 322 Any benefit against other attacks specific to the HMAC or SHA-1 323 algorithms is probably achieved with a fairly small number of 324 iterations. 326 In the "optimistic preauthentication" case mentioned in section 3, 327 the client may attempt to produce a key without first communicating 328 with the KDC. If the client has no additional information, it can 329 only guess as to the iteration count to be used. Even such 330 heuristics as "iteration count X was used to acquire tickets for the 331 same principal only N hours ago" can be wrong. Given the 332 recommendation above for increasing the iteration counts used over 333 time, it is impossible to recommend any specific default value for 334 this case; allowing site-local configuration is recommended. (If the 335 lower and upper bound checks described above are implemented, the 336 default count for optimistic preauthentication should be between 337 those bounds.) 339 Cipher text stealing mode, since it requires no additional padding in 340 most cases, will reveal the exact length of each message being 341 encrypted, rather than merely bounding it to a small range of 342 possible lengths as in CBC mode. Such obfuscation should not be 343 relied upon at higher levels in any case; if the length must be 344 obscured from an outside observer, it should be done by intentionally 345 varying the length of the message to be encrypted. 347 9. IANA Considerations 349 Kerberos encryption and checksum type values used in section 7 were 350 previously reserved in [KCRYPTO] for the mechanisms defined in this 351 document. The registries should be updated to list this document as 352 the reference. 354 10. Acknowledgements 356 Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul 357 Leach, Marcus Watts, Larry Zhu and others for feedback on earlier 358 versions of this document. 360 A. Errata for RFC 2040 section 8 362 (Copied from the RFC Editor's errata web site on July 8, 2004.) 364 Reported By: Bob Baldwin; baldwin@plusfive.com 365 Date: Fri, 26 Mar 2004 06:49:02 -0800 367 In Section 8, Description of RC5-CTS, of the encryption method, it says: 369 1. Exclusive-or Pn-1 with the previous ciphertext 370 block, Cn-2, to create Xn-1. 372 It should say: 374 1. Exclusive-or Pn-1 with the previous ciphertext 375 block, Cn-2, to create Xn-1. For short messages where 376 Cn-2 does not exist, use IV. 378 Reported By: Bob Baldwin; baldwin@plusfive.com 379 Date: Mon, 22 Mar 2004 20:26:40 -0800 381 In Section 8, first paragraph, second sentence says: 383 This mode handles any length of plaintext and produces ciphertext 384 whose length matches the plaintext length. 386 In Section 8, first paragraph, second sentence should read: 388 This mode handles any length of plaintext longer than one 389 block and produces ciphertext whose length matches the 390 plaintext length. 392 In Section 8, step 6 of the decryption method says: 394 6. Decrypt En to create Pn-1. 396 In Section 8, step 6 of the decryption method should read: 398 6. Decrypt En and exclusive-or with Cn-2 to create Pn-1. 399 For short messages where Cn-2 does not exist, use the IV. 401 B. Sample test vectors 403 Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are 404 included below. 406 Iteration count = 1 407 Pass phrase = "password" 408 Salt = "ATHENA.MIT.EDUraeburn" 409 128-bit PBKDF2 output: 410 cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 411 128-bit AES key: 412 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 413 256-bit PBKDF2 output: 414 cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 415 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 416 256-bit AES key: 417 fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b 418 bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61 420 Iteration count = 2 421 Pass phrase = "password" 422 Salt="ATHENA.MIT.EDUraeburn" 423 128-bit PBKDF2 output: 424 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 425 128-bit AES key: 426 c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 427 256-bit PBKDF2 output: 428 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 429 a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 430 256-bit AES key: 431 a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 432 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff 434 Iteration count = 1200 435 Pass phrase = "password" 436 Salt = "ATHENA.MIT.EDUraeburn" 437 128-bit PBKDF2 output: 438 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 439 128-bit AES key: 440 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a 441 256-bit PBKDF2 output: 442 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 443 a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 444 256-bit AES key: 445 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 446 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a 448 Iteration count = 5 449 Pass phrase = "password" 450 Salt=0x1234567878563412 451 128-bit PBKDF2 output: 452 d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 453 128-bit AES key: 454 e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e 455 256-bit PBKDF2 output: 456 d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 457 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee 458 256-bit AES key: 459 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c 460 ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 461 (This test is based on values given in [PECMS].) 462 Iteration count = 1200 463 Pass phrase = (64 characters) 464 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 465 Salt="pass phrase equals block size" 466 128-bit PBKDF2 output: 467 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 468 128-bit AES key: 469 59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed 470 256-bit PBKDF2 output: 471 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 472 c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1 473 256-bit AES key: 474 89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0 475 56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34 477 Iteration count = 1200 478 Pass phrase = (65 characters) 479 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 480 Salt = "pass phrase exceeds block size" 481 128-bit PBKDF2 output: 482 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 483 128-bit AES key: 484 cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d 485 256-bit PBKDF2 output: 486 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 487 1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a 488 256-bit AES key: 489 d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2 490 14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b 492 Iteration count = 50 493 Pass phrase = g-clef (0xf09d849e) 494 Salt = "EXAMPLE.COMpianist" 495 128-bit PBKDF2 output: 496 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 497 128-bit AES key: 498 f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 499 256-bit PBKDF2 output: 500 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 501 e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 502 256-bit AES key: 503 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c 504 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e 506 Some test vectors for CBC with cipher text stealing, using an initial 507 vector of all-zero. 509 AES 128-bit key: 510 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69 512 IV: 513 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 514 Input: 515 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 516 0010: 20 517 Output: 518 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 519 0010: 97 520 Next IV: 521 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 523 IV: 524 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 525 Input: 526 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 527 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 528 Output: 529 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 530 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 531 Next IV: 532 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 534 IV: 535 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 536 Input: 537 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 538 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 539 Output: 540 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 541 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 542 Next IV: 543 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 545 IV: 546 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 547 Input: 548 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 549 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 550 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 551 Output: 552 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 553 0010: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 554 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 555 Next IV: 556 0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 558 IV: 559 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 560 Input: 561 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 562 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 563 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 564 Output: 565 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 566 0010: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 567 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 568 Next IV: 569 0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 571 IV: 572 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 573 Input: 574 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 575 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 576 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 577 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e 578 Output: 579 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 580 0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 581 0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 582 0030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 583 Next IV: 584 0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 586 Normative References 588 [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley 589 and Sons, New York, 1996. 591 [AES] National Institute of Standards and Technology, U.S. Department 592 of Commerce, "Advanced Encryption Standard", Federal Information 593 Processing Standards Publication 197, Washington, DC, November 2001. 595 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 596 Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002. Work in 597 progress. 599 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", RFC 2119, March 1997. 602 [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography 603 Specification Version 2.0", RFC 2898, September 2000. 605 [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 606 RC5-CTS Algorithms", RFC 2040, October 1996. 608 [SHA1] National Institute of Standards and Technology, U.S. 609 Department of Commerce, "Secure Hash Standard", Federal Information 610 Processing Standards Publication 180-1, Washington, DC, April 1995. 612 Informative References 614 [LEACH] Leach, P., email to IETF Kerberos working group mailing list, 615 5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail. 617 [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, 618 December 2001. 620 Author's Address 622 Kenneth Raeburn 623 Massachusetts Institute of Technology 624 77 Massachusetts Avenue 625 Cambridge, MA 02139 626 raeburn@mit.edu 628 IPR notices 630 The IETF takes no position regarding the validity or scope of any 631 intellectual property or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; neither does it represent that it 635 has made any effort to identify any such rights. Information on the 636 IETF's procedures with respect to rights in standards-track and 637 standards-related documentation can be found in BCP-11. Copies of 638 claims of rights made available for publication and any assurances of 639 licenses to be made available, or the result of an attempt made to 640 obtain a general license or permission for the use of such 641 proprietary rights by implementors or users of this specification can 642 be obtained from the IETF Secretariat. 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights which may cover technology that may be required to practice 647 this standard. Please address the information to the IETF Executive 648 Director. 650 Full Copyright Statement 652 Copyright (C) The Internet Society (2004). All Rights Reserved. 654 This document and translations of it may be copied and furnished to 655 others, and derivative works that comment on or otherwise explain it 656 or assist in its implementation may be prepared, copied, published 657 and distributed, in whole or in part, without restriction of any 658 kind, provided that the above copyright notice and this paragraph are 659 included on all such copies and derivative works. However, this 660 document itself may not be modified in any way, such as by removing 661 the copyright notice or references to the Internet Society or other 662 Internet organizations, except as needed for the purpose of 663 developing Internet standards in which case the procedures for 664 copyrights defined in the Internet Standards process must be 665 followed, or as required to translate it into languages other than 666 English. 668 The limited permissions granted above are perpetual and will not be 669 revoked by the Internet Society or its successors or assigns. 671 This document and the information contained herein is provided on an 672 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 673 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 674 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 675 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 676 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 678 Notes to RFC Editor 680 The reference entry for [KCRYPTO] lists the draft name, not the RFC 681 number. This should be replaced with the RFC info when available.