idnits 2.17.1 draft-kaliski-pkcs5-v2-04.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: ---------------------------------------------------------------------------- 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.) ** The abstract seems to contain references ([4], [5], [25], [26]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 846: '... keyLength INTEGER (1..MAX) OPTIONAL,...' RFC 2119 keyword, line 1131: '... rc2ParameterVersion INTEGER OPTIONAL,...' RFC 2119 keyword, line 1180: '... iv OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 1242: '... {@algorithm}) OPTIONAL...' RFC 2119 keyword, line 1263: '... keyLength INTEGER (1..MAX) OPTIONAL,...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 134 has weird spacing: '... dkLen leng...' == Line 138 has weird spacing: '... Hash und...' == Line 140 has weird spacing: '... hLen len...' == Line 158 has weird spacing: '... psLen leng...' == Line 170 has weird spacing: '... \xor bit...' == (1 more instance...) -- 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 (May 2000) is 8746 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '25' on line 1498 looks like a reference -- Missing reference section? '4' on line 1429 looks like a reference -- Missing reference section? '5' on line 1434 looks like a reference -- Missing reference section? '26' on line 1501 looks like a reference -- Missing reference section? '24' on line 1495 looks like a reference -- Missing reference section? '8' on line 1443 looks like a reference -- Missing reference section? '27' on line 1505 looks like a reference -- Missing reference section? '17' on line 1473 looks like a reference -- Missing reference section? '6' on line 1437 looks like a reference -- Missing reference section? '19' on line 1479 looks like a reference -- Missing reference section? '18' on line 1476 looks like a reference -- Missing reference section? '15' on line 1467 looks like a reference -- Missing reference section? '21' on line 1486 looks like a reference -- Missing reference section? '16' on line 1470 looks like a reference -- Missing reference section? '3' on line 1425 looks like a reference -- Missing reference section? '9' on line 1446 looks like a reference -- Missing reference section? '10' on line 1449 looks like a reference -- Missing reference section? '11' on line 1453 looks like a reference -- Missing reference section? '12' on line 1456 looks like a reference -- Missing reference section? '13' on line 1460 looks like a reference -- Missing reference section? '14' on line 1463 looks like a reference -- Missing reference section? '7' on line 1440 looks like a reference -- Missing reference section? '1' on line 1418 looks like a reference -- Missing reference section? '20' on line 1482 looks like a reference -- Missing reference section? '2' on line 1422 looks like a reference -- Missing reference section? '22' on line 1489 looks like a reference -- Missing reference section? '23' on line 1492 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT B. Kaliski 3 Expires: November 2000 RSA Laboratories 4 Intended Category: Informational May 2000 6 PKCS #5: Password-Based Cryptography Specification 7 Version 2.0 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 except that the right to 15 produce derivative works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo represents a republication of PKCS #5 v 2.0 from RSA 35 Laboratories' Public-Key Cryptography Standards (PKCS) series, and 36 change control is retained within the PKCS process. The remainder of 37 this text is taken from that specification. 39 This document provides recommendations for the implementation of 40 password-based cryptography, covering key derivation functions, 41 encryption schemes, message-authentication schemes, and ASN.1 syntax 42 identifying the techniques. 44 The recommendations are intended for general application within 45 computer and communications systems, and as such include a fair 46 amount of flexibility. They are particularly intended for the 47 protection of sensitive information such as private keys, as in PKCS 48 #8 [25]. It is expected that application standards and implementation 49 profiles based on these specifications may include additional 50 constraints. 52 Other cryptographic techniques based on passwords, such as password- 53 based key entity authentication and key establishment protocols 54 [4][5][26] are outside the scope of this document. Guidelines for the 55 selection of passwords are also outside the scope. 57 Table of contents 59 1. Introduction ................................................ 3 60 2. Notation .................................................... 3 61 3. Overview .................................................... 4 62 4. Salt and iteration count .................................... 6 63 4.1 Salt .................................................... 6 64 4.2 Iteration count ......................................... 8 65 5. Key derivation functions .................................... 8 66 5.1 PBKDF1 .................................................. 9 67 5.2 PBKDF2 .................................................. 9 68 6. Encryption schemes .......................................... 11 69 6.1 PBES1 ................................................... 12 70 6.1.1 Encryption operation ............................. 12 71 6.1.2 Decryption operation ............................. 13 72 6.2 PBES2 ................................................... 14 73 6.2.1 Encryption operation ............................. 14 74 6.2.2 Decryption operation ............................. 15 75 7. Message authentication schemes .............................. 15 76 7.1 PBMAC1 .................................................. 15 77 7.1.1 MAC generation ................................... 16 78 7.1.2 MAC verification ................................. 16 79 8. Security considerations ..................................... 17 80 9. Author's address............................................. 17 82 Appendices 84 A. ASN.1 syntax ................................................ 18 85 A.1 PBKDF1 .................................................. 18 86 A.2 PBKDF2 .................................................. 18 87 A.3 PBES1 ................................................... 20 88 A.4 PBES2 ................................................... 20 89 A.5 PBMAC1 .................................................. 21 90 B. Supporting techniques ....................................... 22 91 B.1 Pseudorandom functions .................................. 22 92 B.2 Encryption schemes ...................................... 23 93 B.3 Message authentication schemes .......................... 26 94 C. ASN.1 module ................................................ 26 95 D. Intellectual property considerations ........................ 30 96 E. Revision history ............................................ 30 97 F. References .................................................. 31 98 G. Contact information & About PKCS ............................ 33 100 1. Introduction 102 This document provides recommendations for the implementation of 103 password-based cryptography, covering the following aspects: 105 - key derivation functions 106 - encryption schemes 107 - message-authentication schemes 108 - ASN.1 syntax identifying the techniques 110 The recommendations are intended for general application within 111 computer and communications systems, and as such include a fair 112 amount of flexibility. They are particularly intended for the 113 protection of sensitive information such as private keys, as in PKCS 114 #8 [25]. It is expected that application standards and implementation 115 profiles based on these specifications may include additional 116 constraints. 118 Other cryptographic techniques based on passwords, such as password- 119 based key entity authentication and key establishment protocols 120 [4][5][26] are outside the scope of this document. Guidelines for the 121 selection of passwords are also outside the scope. 123 This document supersedes PKCS #5 version 1.5 [24], but includes 124 compatible techniques. 126 2. Notation 128 C ciphertext, an octet string 130 c iteration count, a positive integer 132 DK derived key, an octet string 134 dkLen length in octets of derived key, a positive integer 136 EM encoded message, an octet string 138 Hash underlying hash function 140 hLen length in octets of pseudorandom function output, a positive 141 integer 143 l length in blocks of derived key, a positive integer 145 IV initialization vector, an octet string 146 K encryption key, an octet string 148 KDF key derivation function 150 M message, an octet string 152 P password, an octet string 154 PRF underlying pseudorandom function 156 PS padding string, an octet string 158 psLen length in octets of padding string, a positive integer 160 S salt, an octet string 162 T message authentication code, an octet string 164 T_1, ..., T_l, U_1, ..., U_c 165 intermediate values, octet strings 167 01, 02, ..., 08 168 octets with value 1, 2, ..., 8 170 \xor bit-wise exclusive-or of two octet strings 172 || || octet length operator 174 || concatenation operator 176 substring extraction operator: extracts octets i through j, 177 0 <= i <= j 179 3. Overview 181 In many applications of public-key cryptography, user security is 182 ultimately dependent on one or more secret text values or passwords. 183 Since a password is not directly applicable as a key to any 184 conventional cryptosystem, however, some processing of the password 185 is required to perform cryptographic operations with it. Moreover, as 186 passwords are often chosen from a relatively small space, special 187 care is required in that processing to defend against search attacks. 189 A general approach to password-based cryptography, as described by 190 Morris and Thompson [8] for the protection of password tables, is to 191 combine a password with a salt to produce a key. The salt can be 192 viewed as an index into a large set of keys derived from the 193 password, and need not be kept secret. Although it may be possible 194 for an opponent to construct a table of possible passwords (a so- 195 called "dictionary attack"), constructing a table of possible keys 196 will be difficult, since there will be many possible keys for each 197 password. An opponent will thus be limited to searching through 198 passwords separately for each salt. 200 Another approach to password-based cryptography is to construct key 201 derivation techniques that are relatively expensive, thereby 202 increasing the cost of exhaustive search. One way to do this is to 203 include an iteration count in the key derivation technique, 204 indicating how many times to iterate some underlying function by 205 which keys are derived. A modest number of iterations, say 1000, is 206 not likely to be a burden for legitimate parties when computing a 207 key, but will be a significant burden for opponents. 209 Salt and iteration count formed the basis for password-based 210 encryption in PKCS #5 v1.5, and adopted here as well for the various 211 cryptographic operations. Thus, password-based key derivation as 212 defined here is a function of a password, a salt, and an iteration 213 count, where the latter two quantities need not be kept secret. 215 From a password-based key derivation function, it is straightforward 216 to define password-based encryption and message authentication 217 schemes. As in PKCS #5 v1.5, the password-based encryption schemes 218 here are based on an underlying, conventional encryption scheme, 219 where the key for the conventional scheme is derived from the 220 password. Similarly, the password-based message authentication scheme 221 is based on an underlying conventional scheme. This two- layered 222 approach makes the password-based techniques modular in terms of the 223 underlying techniques they can be based on. 225 It is expected that the password-based key derivation functions may 226 find other applications than just the encryption and message 227 authentication schemes defined here. For instance, one might derive a 228 set of keys with a single application of a key derivation function, 229 rather than derive each key with a separate application of the 230 function. The keys in the set would be obtained as substrings of the 231 output of the key derivation function. This approach might be 232 employed as part of key establishment in a session-oriented protocol. 233 Another application is password checking, where the output of the key 234 derivation function is stored (along with the salt and iteration 235 count) for the purposes of subsequent verification of a password. 237 Throughout this document, a password is considered to be an octet 238 string of arbitrary length whose interpretation as a text string is 239 unspecified. In the interest of interoperability, however, it is 240 recommended that applications follow some common text encoding rules. 241 ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of 242 UTF-8.) 244 Although the selection of passwords is outside the scope of this 245 document, guidelines have been published [17] that may well be taken 246 into account. 248 4. Salt and iteration count 250 Inasmuch as salt and iteration count are central to the techniques 251 defined in this document, some further discussion is warranted. 253 4.1 Salt 255 A salt in password-based cryptography has traditionally served the 256 purpose of producing a large set of keys corresponding to a given 257 password, among which one is selected at random according to the 258 salt. An individual key in the set is selected by applying a key 259 derivation function KDF, as 261 DK = KDF (P, S) 263 where DK is the derived key, P is the password, and S is the salt. 264 This has two benefits: 266 1. It is difficult for an opponent to precompute all the keys 267 corresponding to a dictionary of passwords, or even the 268 most likely keys. If the salt is 64 bits long, for 269 instance, there will be as many as 2^64 keys for each 270 password. An opponent is thus limited to searching for 271 passwords after a password-based operation has been 272 performed and the salt is known. 274 2. It is unlikely that the same key will be selected twice. 275 Again, if the salt is 64 bits long, the chance of 276 "collision" between keys does not become significant until 277 about 2^32 keys have been produced, according to the 278 Birthday Paradox. This addresses some of the concerns about 279 interactions between multiple uses of the same key, which 280 may apply for some encryption and authentication 281 techniques. 283 In password-based encryption, the party encrypting a message can gain 284 assurance that these benefits are realized simply by selecting a 285 large and sufficiently random salt when deriving an encryption key 286 from a password. A party generating a message authentication code can 287 gain such assurance in a similar fashion. 289 The party decrypting a message or verifying a message authentication 290 code, however, cannot be sure that a salt supplied by another party 291 has actually been generated at random. It is possible, for instance, 292 that the salt may have been copied from another password-based 293 operation, in an attempt to exploit interactions between multiple 294 uses of the same key. For instance, suppose two legitimate parties 295 exchange a encrypted message, where the encryption key is an 80-bit 296 key derived from a shared password with some salt. An opponent could 297 take the salt from that encryption and provide it to one of the 298 parties as though it were for a 40-bit key. If the party reveals the 299 result of decryption with the 40-bit key, the opponent may be able to 300 solve for the 40-bit key. In the case that 40-bit key is the first 301 half of the 80-bit key, the opponent can then readily solve for the 302 remaining 40 bits of the 80-bit key. 304 To defend against such attacks, either the interaction between 305 multiple uses of the same key should be carefully analyzed, or the 306 salt should contain data that explicitly distinguishes between 307 different operations. For instance, the salt might have an 308 additional, non-random octet that specifies whether the derived key 309 is for encryption, for message authentication, or for some other 310 operation. 312 Based on this, the following is recommended for salt selection: 314 1. If there is no concern about interactions between multiple 315 uses of the same key (or a prefix of that key) with the 316 password-based encryption and authentication techniques 317 supported for a given password, then the salt may be 318 generated at random and need not be checked for a 319 particular format by the party receiving the salt. It 320 should be at least eight octets (64 bits) long. 322 2. Otherwise, the salt should contain data that explicitly 323 distinguishes between different operations and different 324 key lengths, in addition to a random part that is at least 325 eight octets long, and this data should be checked or 326 regenerated by the party receiving the salt. For instance, 327 the salt could have an additional non-random octet that 328 specifies the purpose of the derived key. Alternatively, 329 it could be the encoding of a structure that specifies 330 detailed information about the derived key, such as the 331 encryption or authentication technique and a sequence 332 number among the different keys derived from the password. 333 The particular format of the additional data is left to the 334 application. 336 Note. If a random number generator or pseudorandom generator is not 337 available, a deterministic alternative for generating the salt (or 338 the random part of it) is to apply a password-based key derivation 339 function to the password and the message M to be processed. For 340 instance, the salt could be computed with a key derivation function 341 as S = KDF (P, M). This approach is not recommended if the message M 342 is known to belong to a small message space (e.g., "Yes" or "No"), 343 however, since then there will only be a small number of possible 344 salts. 346 4.2 Iteration count 348 An iteration count has traditionally served the purpose of increasing 349 the cost of producing keys from a password, thereby also increasing 350 the difficulty of attack. For the methods in this document, a minimum 351 of 1000 iterations is recommended. This will increase the cost of 352 exhaustive search for passwords significantly, without a noticeable 353 impact in the cost of deriving individual keys. 355 5. Key derivation functions 357 A key derivation function produces a derived key from a base key and 358 other parameters. In a password-based key derivation function, the 359 base key is a password and the other parameters are a salt value and 360 an iteration count, as outlined in Section 3. 362 The primary application of the password-based key derivation 363 functions defined here is in the encryption schemes in Section 6 and 364 the message authentication scheme in Section 7. Other applications 365 are certainly possible, hence the independent definition of these 366 functions. 368 Two functions are specified in this section: PBKDF1 and PBKDF2. 369 PBKDF2 is recommended for new applications; PBKDF1 is included only 370 for compatibility with existing applications, and is not recommended 371 for new applications. 373 A typical application of the key derivation functions defined here 374 might include the following steps: 376 1. Select a salt S and an iteration count c, as outlined in 377 Section 4. 379 2. Select a length in octets for the derived key, dkLen. 381 3. Apply the key derivation function to the password, the 382 salt, the iteration count and the key length to produce a 383 derived key. 385 4. Output the derived key. 387 Any number of keys may be derived from a password by varying the 388 salt, as described in Section 3. 390 5.1 PBKDF1 392 PBKDF1 applies a hash function, which shall be MD2 [6], MD5 [19] or 393 SHA-1 [18], to derive keys. The length of the derived key is bounded 394 by the length of the hash function output, which is 16 octets for MD2 395 and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key 396 derivation process in PKCS #5 v1.5. 398 PBKDF1 is recommended only for compatibility with existing 399 applications since the keys it produces may not be large enough for 400 some applications. 402 PBKDF1 (P, S, c, dkLen) 404 Options: Hash underlying hash function 406 Input: P password, an octet string 407 S salt, an eight-octet string 408 c iteration count, a positive integer 409 dkLen intended length in octets of derived key, 410 a positive integer, at most 16 for MD2 or 411 MD5 and 20 for SHA-1 413 Output: DK derived key, a dkLen-octet string 415 Steps: 417 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, 418 output "derived key too long" and stop. 420 2. Apply the underlying hash function Hash for c iterations to 421 the concatenation of the password P and the salt S, then 422 extract the first dkLen octets to produce a derived key DK: 424 T_1 = Hash (P || S) , 425 T_2 = Hash (T_1) , 426 ... 427 T_c = Hash (T_{c-1}) , 428 DK = Tc<0..dkLen-1> 430 3. Output the derived key DK. 432 5.2 PBKDF2 434 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an 435 example) to derive keys. The length of the derived key is essentially 436 unbounded. (However, the maximum effective search space for the 437 derived key may be limited by the structure of the underlying 438 pseudorandom function. See Appendix B.1 for further discussion.) 439 PBKDF2 is recommended for new applications. 441 PBKDF2 (P, S, c, dkLen) 443 Options: PRF underlying pseudorandom function (hLen 444 denotes the length in octets of the 445 pseudorandom function output) 447 Input: P password, an octet string 448 S salt, an octet string 449 c iteration count, a positive integer 450 dkLen intended length in octets of the derived 451 key, a positive integer, at most 452 (2^32 - 1) * hLen 454 Output: DK derived key, a dkLen-octet string 456 Steps: 458 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" 459 and stop. 461 2. Let l be the number of hLen-octet blocks in the derived key, 462 rounding up, and let r be the number of octets in the last 463 block: 465 l = CEIL (dkLen / hLen) , 466 r = dkLen - (l - 1) * hLen . 468 Here, CEIL (x) is the "ceiling" function, i.e. the smallest 469 integer greater than, or equal to, x. 471 3. For each block of the derived key apply the function F 472 defined below to the password P, the salt S, the iteration 473 count c, and the block index to compute the block: 475 T_1 = F (P, S, c, 1) , 476 T_2 = F (P, S, c, 2) , 477 ... 478 T_l = F (P, S, c, l) , 480 where the function F is defined as the exclusive-or sum of 481 the first c iterates of the underlying pseudorandom function 482 PRF applied to the password P and the concatenation of the 483 salt S and the block index i: 485 F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c 487 where 489 U_1 = PRF (P, S || INT (i)) , 490 U_2 = PRF (P, U_1) , 491 ... 492 U_c = PRF (P, U_{c-1}) . 494 Here, INT (i) is a four-octet encoding of the integer i, most 495 significant octet first. 497 4. Concatenate the blocks and extract the first dkLen octets to 498 produce a derived key DK: 500 DK = T_1 || T_2 || ... || T_l<0..r-1> 502 5. Output the derived key DK. 504 Note. The construction of the function F follows a "belt-and- 505 suspenders" approach. The iterates U_i are computed recursively to 506 remove a degree of parallelism from an opponent; they are exclusive- 507 ored together to reduce concerns about the recursion degenerating 508 into a small set of values. 510 6. Encryption schemes 512 An encryption scheme, in the symmetric setting, consists of an 513 encryption operation and a decryption operation, where the encryption 514 operation produces a ciphertext from a message under a key, and the 515 decryption operation recovers the message from the ciphertext under 516 the same key. In a password-based encryption scheme, the key is a 517 password. 519 A typical application of a password-based encryption scheme is a 520 private-key protection method, where the message contains private-key 521 information, as in PKCS #8. The encryption schemes defined here would 522 be suitable encryption algorithms in that context. 524 Two schemes are specified in this section: PBES1 and PBES2. PBES2 is 525 recommended for new applications; PBES1 is included only for 526 compatibility with existing applications, and is not recommended for 527 new applications. 529 6.1 PBES1 531 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying 532 block cipher, which shall be either DES [15] or RC2(tm) [21] in CBC 533 mode [16]. PBES1 is compatible with the encryption scheme in PKCS #5 534 v1.5. 536 PBES1 is recommended only for compatibility with existing 537 applications, since it supports only two underlying encryption 538 schemes, each of which has a key size (56 or 64 bits) that may not be 539 large enough for some applications. 541 6.1.1 Encryption operation 543 The encryption operation for PBES1 consists of the following steps, 544 which encrypt a message M under a password P to produce a ciphertext 545 C: 547 1. Select an eight-octet salt S and an iteration count c, as 548 outlined in Section 4. 550 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 551 password P, the salt S, and the iteration count c to produce 552 at derived key DK of length 16 octets: 554 DK = PBKDF1 (P, S, c, 16) . 556 3. Separate the derived key DK into an encryption key K 557 consisting of the first eight octets of DK and an 558 initialization vector IV consisting of the next eight octets: 560 K = DK<0..7> , 561 IV = DK<8..15> . 563 4. Concatenate M and a padding string PS to form an encoded 564 message EM: 566 EM = M || PS , 568 where the padding string PS consists of 8-(||M|| mod 8) 569 octets each with value 8-(||M|| mod 8). The padding string PS 570 will satisfy one of the following statements: 572 PS = 01, if ||M|| mod 8 = 7 ; 573 PS = 02 02, if ||M|| mod 8 = 6 ; 574 ... 575 PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0. 577 The length in octets of the encoded message will be a 578 multiple of eight and it will be possible to recover the 579 message M unambiguously from the encoded message. (This 580 padding rule is taken from RFC 1423 [3].) 582 5. Encrypt the encoded message EM with the underlying block 583 cipher (DES or RC2) in cipher block chaining mode under the 584 encryption key K with initialization vector IV to produce the 585 ciphertext C. For DES, the key K shall be considered as a 586 64-bit encoding of a 56-bit DES key with parity bits ignored 587 (see [9]). For RC2, the "effective key bits" shall be 64 588 bits. 590 6. Output the ciphertext C. 592 The salt S and the iteration count c may be conveyed to the party 593 performing decryption in an AlgorithmIdentifier value (see Appendix 594 A.3). 596 6.1.2 Decryption operation 598 The decryption operation for PBES1 consists of the following steps, 599 which decrypt a ciphertext C under a password P to recover a message 600 M: 602 1. Obtain the eight-octet salt S and the iteration count c. 604 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 605 password P, the salt S, and the iteration count c to produce 606 a derived key DK of length 16 octets: 608 DK = PBKDF1 (P, S, c, 16) 610 3. Separate the derived key DK into an encryption key K 611 consisting of the first eight octets of DK and an 612 initialization vector IV consisting of the next eight octets: 614 K = DK<0..7> , 615 IV = DK<8..15> . 617 4. Decrypt the ciphertext C with the underlying block cipher 618 (DES or RC2) in cipher block chaining mode under the 619 encryption key K with initialization vector IV to recover an 620 encoded message EM. If the length in octets of the ciphertext 621 C is not a multiple of eight, output "decryption error" and 622 stop. 624 5. Separate the encoded message EM into a message M and a 625 padding string PS: 627 EM = M || PS , 629 where the padding string PS consists of some number psLen 630 octets each with value psLen, where psLen is between 1 and 8. 631 If it is not possible to separate the encoded message EM in 632 this manner, output "decryption error" and stop. 634 6. Output the recovered message M. 636 6.2 PBES2 638 PBES2 combines a password-based key derivation function, which shall 639 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 640 underlying encryption scheme (see Appendix B.2 for examples). The key 641 length and any other parameters for the underlying encryption scheme 642 depend on the scheme. 644 PBES2 is recommended for new applications. 646 6.2.1 Encryption operation 648 The encryption operation for PBES2 consists of the following steps, 649 which encrypt a message M under a password P to produce a ciphertext 650 C, applying a selected key derivation function KDF and a selected 651 underlying encryption scheme: 653 1. Select a salt S and an iteration count c, as outlined in 654 Section 4. 656 2. Select the length in octets, dkLen, for the derived key for 657 the underlying encryption scheme. 659 3. Apply the selected key derivation function to the password P, 660 the salt S, and the iteration count c to produce a derived 661 key DK of length dkLen octets: 663 DK = KDF (P, S, c, dkLen) . 665 4. Encrypt the message M with the underlying encryption scheme 666 under the derived key DK to produce a ciphertext C. (This 667 step may involve selection of parameters such as an 668 initialization vector and padding, depending on the 669 underlying scheme.) 671 5. Output the ciphertext C. 673 The salt S, the iteration count c, the key length dkLen, and 674 identifiers for the key derivation function and the underlying 675 encryption scheme may be conveyed to the party performing decryption 676 in an AlgorithmIdentifier value (see Appendix A.4). 678 6.2.2 Decryption operation 680 The decryption operation for PBES2 consists of the following steps, 681 which decrypt a ciphertext C under a password P to recover a message 682 M: 684 1. Obtain the salt S for the operation. 686 2. Obtain the iteration count c for the key derivation function. 688 3. Obtain the key length in octets, dkLen, for the derived key 689 for the underlying encryption scheme. 691 4. Apply the selected key derivation function to the password P, 692 the salt S, and the iteration count c to produce a derived 693 key DK of length dkLen octets: 695 DK = KDF (P, S, c, dkLen) . 697 5. Decrypt the ciphertext C with the underlying encryption 698 scheme under the derived key DK to recover a message M. If 699 the decryption function outputs "decryption error," then 700 output "decryption error" and stop. 702 6. Output the recovered message M. 704 7. Message authentication schemes 706 A message authentication scheme consists of a MAC (message 707 authentication code) generation operation and a MAC verification 708 operation, where the MAC generation operation produces a message 709 authentication code from a message under a key, and the MAC 710 verification operation verifies the message authentication code under 711 the same key. In a password-based message authentication scheme, the 712 key is a password. 714 One scheme is specified in this section: PBMAC1. 716 7.1 PBMAC1 718 PBMAC1 combines a password-based key derivation function, which shall 719 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 720 underlying message authentication scheme (see Appendix B.3 for an 721 example). The key length and any other parameters for the underlying 722 message authentication scheme depend on the scheme. 724 7.1.1 MAC generation 726 The MAC generation operation for PBMAC1 consists of the following 727 steps, which process a message M under a password P to generate a 728 message authentication code T, applying a selected key derivation 729 function KDF and a selected underlying message authentication scheme: 731 1. Select a salt S and an iteration count c, as outlined in 732 Section 4. 734 2. Select a key length in octets, dkLen, for the derived key for 735 the underlying message authentication function. 737 3. Apply the selected key derivation function to the password P, 738 the salt S, and the iteration count c to produce a derived 739 key DK of length dkLen octets: 741 DK = KDF (P, S, c, dkLen) . 743 4. Process the message M with the underlying message 744 authentication scheme under the derived key DK to generate a 745 message authentication code T. 747 5. Output the message authentication code T. 749 The salt S, the iteration count c, the key length dkLen, and 750 identifiers for the key derivation function and underlying message 751 authentication scheme may be conveyed to the party performing 752 verification in an AlgorithmIdentifier value (see Appendix A.5). 754 7.1.2 MAC verification 756 The MAC verification operation for PBMAC1 consists of the following 757 steps, which process a message M under a password P to verify a 758 message authentication code T: 760 1. Obtain the salt S and the iteration count c. 762 2. Obtain the key length in octets, dkLen, for the derived key 763 for the underlying message authentication scheme. 765 3. Apply the selected key derivation function to the password P, 766 the salt S, and the iteration count c to produce a derived 767 key DK of length dkLen octets: 769 DK = KDF (P, S, c, dkLen) . 771 4. Process the message M with the underlying message 772 authentication scheme under the derived key DK to verify the 773 message authentication code T. 775 5. If the message authentication code verifies, output 776 "correct"; else output "incorrect." 778 8. Security considerations 780 Password-based cryptography is generally limited in the security that 781 it can provide, particularly for methods such as those defined in 782 this document where off-line password search is possible. While the 783 use of salt and iteration count can increase the complexity of attack 784 (see Section 4 for recommendations), it is essential that passwords 785 are selected well, and relevant guidelines (e.g., [17]) should be 786 taken into account. It is also important that passwords be protected 787 well if stored. 789 In general, different keys should be derived from a password for 790 different uses to minimize the possibility of unintended 791 interactions. For password-based encryption with a single algorithm, 792 a random salt is sufficient to ensure that different keys will be 793 produced. In certain other situations, as outlined in Section 4, a 794 structured salt is necessary. The recommendations in Section 4 should 795 thus be taken into account when selecting the salt value. 797 9. Author's address 799 Burt Kaliski 800 RSA Laboratories 801 20 Crosby Drive 802 Bedford, MA 01730 USA 804 Email: bkaliski@rsasecurity.com 806 APPENDICES 808 A. ASN.1 syntax 810 This section defines ASN.1 syntax for the key derivation functions, 811 the encryption schemes, the message authentication scheme, and 812 supporting techniques. The intended application of these definitions 813 includes PKCS #8 and other syntax for key management, encrypted data, 814 and integrity-protected data. (Various aspects of ASN.1 are specified 815 in several ISO/IEC standards [9][10][11][12][13][14].) 817 The object identifier pkcs-5 identifies the arc of the OID tree from 818 which the PKCS #5-specific OIDs in this section are derived: 820 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 821 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 822 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 824 A.1 PBKDF1 826 No object identifier is given for PBKDF1, as the object identifiers 827 for PBES1 are sufficient for existing applications and PBKDF2 is 828 recommended for new applications. 830 A.2 PBKDF2 832 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation 833 function (Section 5.2). 835 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 837 The parameters field associated with this OID in an 838 AlgorithmIdentifier shall have type PBKDF2-params: 840 PBKDF2-params ::= SEQUENCE { 841 salt CHOICE { 842 specified OCTET STRING, 843 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 844 }, 845 iterationCount INTEGER (1..MAX), 846 keyLength INTEGER (1..MAX) OPTIONAL, 847 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 848 algid-hmacWithSHA1 } 850 The fields of type PKDF2-params have the following meanings: 852 - salt specifies the salt value, or the source of the salt value. 853 It shall either be an octet string or an algorithm ID with an OID 854 in the set PBKDF2-SaltSources, which is reserved for future 855 versions of PKCS #5. 857 The salt-source approach is intended to indicate how the salt 858 value is to be generated as a function of parameters in the 859 algorithm ID, application data, or both. For instance, it may 860 indicate that the salt value is produced from the encoding of 861 a structure that specifies detailed information about the derived 862 key as suggested in Section 4.1. Some of the information may be 863 carried elsewhere, e.g., in the encryption algorithm ID. However, 864 such facilities are deferred to a future version of PKCS #5. 866 In this version, an application may achieve the benefits 867 mentioned in Section 4.1 by choosing a particular interpretation 868 of the salt value in the specified alternative. 870 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 872 - iterationCount specifies the iteration count. The maximum 873 iteration count allowed depends on the implementation. It is 874 expected that implementation profiles may further constrain the 875 bounds. 877 - keyLength, an optional field, is the length in octets of the 878 derived key. The maximum key length allowed depends on the 879 implementation; it is expected that implementation profiles may 880 further constrain the bounds. The field is provided for 881 convenience only; the key length is not cryptographically 882 protected. If there is concern about interaction between 883 operations with different key lengths for a given salt (see 884 Section 4.1), the salt should distinguishes among the different 885 key lengths. 887 - prf identifies the underlying pseudorandom function. It shall be 888 an algorithm ID with an OID in the set PBKDF2-PRFs, which for 889 this version of PKCS #5 shall consist of id-hmacWithSHA1 (see 890 Appendix B.1.1) and any other OIDs defined by the application. 892 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= 893 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... } 895 The default pseudorandom function is HMAC-SHA-1: 897 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 898 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 900 A.3 PBES1 902 Different object identifiers identify the PBES1 encryption scheme 903 (Section 6.1) according to the underlying hash function in the key 904 derivation function and the underlying block cipher, as summarized in 905 the following table: 907 Hash Function Block Cipher OID 908 MD2 DES pkcs-5.1 909 MD2 RC2 pkcs-5.4 910 MD5 DES pkcs-5.3 911 MD5 RC2 pkcs-5.6 912 SHA-1 DES pkcs-5.10 913 SHA-1 RC2 pkcs-5.11 915 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 916 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 917 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 918 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 919 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 920 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 922 For each OID, the parameters field associated with the OID in an 923 AlgorithmIdentifier shall have type PBEParameter: 925 PBEParameter ::= SEQUENCE { 926 salt OCTET STRING (SIZE(8)), 927 iterationCount INTEGER } 929 The fields of type PBEParameter have the following meanings: 931 - salt specifies the salt value, an eight-octet string. 933 - iterationCount specifies the iteration count. 935 A.4 PBES2 937 The object identifier id-PBES2 identifies the PBES2 encryption scheme 938 (Section 6.2). 940 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 942 The parameters field associated with this OID in an 943 AlgorithmIdentifier shall have type PBES2-params: 945 PBES2-params ::= SEQUENCE { 946 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 947 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } 949 The fields of type PBES2-params have the following meanings: 951 - keyDerivationFunc identifies the underlying key derivation 952 function. It shall be an algorithm ID with an OID in the set 953 PBES2-KDFs, which for this version of PKCS #5 shall consist of 954 id-PBKDF2 (Appendix A.2). 956 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 957 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 959 - encryptionScheme identifies the underlying encryption scheme. It 960 shall be an algorithm ID with an OID in the set PBES2-Encs, whose 961 definition is left to the application. Example underlying 962 encryption schemes are given in Appendix B.2. 964 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 966 A.5 PBMAC1 968 The object identifier id-PBMAC1 identifies the PBMAC1 message 969 authentication scheme (Section 7.1). 971 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 973 The parameters field associated with this OID in an 974 AlgorithmIdentifier shall have type PBMAC1-params: 976 PBMAC1-params ::= SEQUENCE { 977 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 978 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } 980 The keyDerivationFunc field has the same meaning as the corresponding 981 field of PBES2-params (Appendix A.4) except that the set of OIDs is 982 PBMAC1-KDFs. 984 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 985 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 987 The messageAuthScheme field identifies the underlying message 988 authentication scheme. It shall be an algorithm ID with an OID in the 989 set PBMAC1-MACs, whose definition is left to the application. Example 990 underlying encryption schemes are given in Appendix B.3. 992 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 994 B. Supporting techniques 996 This section gives several examples of underlying functions and 997 schemes supporting the password-based schemes in Sections 5, 6 and 7. 999 While these supporting techniques are appropriate for applications to 1000 implement, none of them is required to be implemented. It is 1001 expected, however, that profiles for PKCS #5 will be developed that 1002 specify particular supporting techniques. 1004 This section also gives object identifiers for the supporting 1005 techniques. The object identifiers digestAlgorithm and 1006 encryptionAlgorithm identify the arcs from which certain algorithm 1007 OIDs referenced in this section are derived: 1009 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1010 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1012 B.1 Pseudorandom functions 1014 An example pseudorandom function for PBKDF2 (Section 5.2) is HMAC- 1015 SHA-1. 1017 B.1.1 HMAC-SHA-1 1019 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC 1020 message authentication code [7] based on the SHA-1 hash function 1021 [18]. The pseudorandom function is the same function by which the 1022 message authentication code is computed, with a full-length output. 1023 (The first argument to the pseudorandom function PRF serves as HMAC's 1024 "key," and the second serves as HMAC's "text." In the case of PBKDF2, 1025 the "key" is thus the password and the "text" is the salt.) HMAC- 1026 SHA-1 has a variable key length and a 20-octet (160-bit) output 1027 value. 1029 Although the length of the key to HMAC-SHA-1 is essentially 1030 unbounded, the effective search space for pseudorandom function 1031 outputs may be limited by the structure of the function. In 1032 particular, when the key is longer than 512 bits, HMAC-SHA-1 will 1033 first hash it to 160 bits. Thus, even if a long derived key 1034 consisting of several pseudorandom function outputs is produced from 1035 a key, the effective search space for the derived key will be at most 1036 160 bits. Although the specific limitation for other key sizes 1037 depends on details of the HMAC construction, one should assume, to be 1038 conservative, that the effective search space is limited to 160 bits 1039 for other key sizes as well. 1041 (The 160-bit limitation should not generally pose a practical 1042 limitation in the case of password-based cryptography, since the 1043 search space for a password is unlikely to be greater than 160 bits.) 1045 The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1 1046 pseudorandom function: 1048 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1050 The parameters field associated with this OID in an 1051 AlgorithmIdentifier shall have type NULL. This object identifier is 1052 employed in the object set PBKDF2-PRFs (Appendix A.2). 1054 Note. Although HMAC-SHA-1 was designed as a message authentication 1055 code, its proof of security is readily modified to accommodate 1056 requirements for a pseudorandom function, under stronger assumptions. 1058 A hash function may also meet the requirements of a pseudorandom 1059 function under certain assumptions. For instance, the direct 1060 application of a hash function to to the concatenation of the "key" 1061 and the "text" may be appropriate, provided that "text" has 1062 appropriate structure to prevent certain attacks. HMAC-SHA-1 is 1063 preferable, however, because it treats "key" and "text" as separate 1064 arguments and does not require "text" to have any structure. 1066 B.2 Encryption schemes 1068 Example pseudorandom functions for PBES2 (Section 6.2) are DES-CBC- 1069 Pad, DES-EDE2-CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad. 1071 The object identifiers given in this section are intended to be 1072 employed in the object set PBES2-Encs (Appendix A.4). 1074 B.2.1 DES-CBC-Pad 1076 DES-CBC-Pad is single-key DES [15] in CBC mode [16] with the RFC 1423 1077 padding operation (see Section 6.1.1). DES-CBC-Pad has an eight-octet 1078 encryption key and an eight-octet initialization vector. The key is 1079 considered as a 64-bit encoding of a 56-bit DES key with parity bits 1080 ignored. 1082 The object identifier desCBC (defined in the NIST/OSI Implementors' 1083 Workshop agreements) identifies the DES-CBC-Pad encryption scheme: 1085 desCBC OBJECT IDENTIFIER ::= 1086 {iso(1) identified-organization(3) oiw(14) secsig(3) 1087 algorithms(2) 7} 1089 The parameters field associated with this OID in an 1090 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1091 specifying the initialization vector for CBC mode. 1093 B.2.2 DES-EDE3-CBC-Pad 1095 DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [1] with the RFC 1096 1423 padding operation. DES-EDE3-CBC-Pad has a 24-octet encryption 1097 key and an eight-octet initialization vector. The key is considered 1098 as the concatenation of three eight-octet keys, each of which is a 1099 64-bit encoding of a 56-bit DES key with parity bits ignored. 1101 The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad 1102 encryption scheme: 1104 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1106 The parameters field associated with this OID in an 1107 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1108 specifying the initialization vector for CBC mode. 1110 Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 1111 [1]; the one given here is preferred since it specifies padding. 1113 B.2.3 RC2-CBC-Pad 1115 RC2-CBC-Pad is the RC2(tm) encryption algorithm [21] in CBC mode with 1116 the RFC 1423 padding operation. RC2-CBC-Pad has a variable key 1117 length, from one to 128 octets, a separate "effective key bits" 1118 parameter from one to 1024 bits that limits the effective search 1119 space independent of the key length, and an eight-octet 1120 initialization vector. 1122 The object identifier rc2CBC identifies the RC2-CBC-Pad encryption 1123 scheme: 1125 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1127 The parameters field associated with OID in an AlgorithmIdentifier 1128 shall have type RC2-CBC-Parameter: 1130 RC2-CBC-Parameter ::= SEQUENCE { 1131 rc2ParameterVersion INTEGER OPTIONAL, 1132 iv OCTET STRING (SIZE(8)) } 1134 The fields of type RC2-CBCParameter have the following meanings: 1136 - rc2ParameterVersion is a proprietary RSA Security Inc. encoding 1137 of the "effective key bits" for RC2. The following encodings are 1138 defined: 1140 Effective Key Bits Encoding 1141 40 160 1142 64 120 1143 128 58 1144 b >= 256 b 1146 If the rc2ParameterVersion field is omitted, the "effective key bits" 1147 defaults to 32. (This is for backward compatibility with certain very 1148 old implementations.) 1150 - iv is the eight-octet initialization vector. 1152 B.2.4 RC5-CBC-Pad 1154 RC5-CBC-Pad is the RC5(tm) encryption algorithm [20] in CBC mode with 1155 a generalization of the RFC 1423 padding operation. This scheme is 1156 fully specified in [2]. RC5-CBC-Pad has a variable key length, from 0 1157 to 256 octets, and supports both a 64-bit block size and a 128-bit 1158 block size. For the former, it has an eight-octet initialization 1159 vector, and for the latter, a 16-octet initialization vector. RC5- 1160 CBC-Pad also has a variable number of "rounds" in the encryption 1161 operation, from 8 to 127. 1163 Note: The generalization of the padding operation is as follows. For 1164 RC5 with a 64-bit block size, the padding string is as defined in RFC 1165 1423. For RC5 with a 128-bit block size, the padding string consists 1166 of 16-(||M|| mod 16) octets each with value 16-(||M|| mod 16). 1168 The object identifier rc5-CBC-PAD [2] identifies RC5-CBC-Pad 1169 encryption scheme: 1171 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1173 The parameters field associated with this OID in an 1174 AlgorithmIdentifier shall have type RC5-CBC-Parameters: 1176 RC5-CBC-Parameters ::= SEQUENCE { 1177 version INTEGER {v1-0(16)} (v1-0), 1178 rounds INTEGER (8..127), 1179 blockSizeInBits INTEGER (64 | 128), 1180 iv OCTET STRING OPTIONAL } 1182 The fields of type RC5-CBC-Parameters have the following meanings: 1184 - version is the version of the algorithm, which shall be v1-0. 1186 - rounds is the number of rounds in the encryption operation, 1187 which shall be between 8 and 127. 1189 - blockSizeInBits is the block size in bits, which shall be 64 or 1190 128. 1192 - iv is the initialization vector, an eight-octet string for 64-bit 1193 RC5 and a 16-octet string for 128-bit RC5. The default is a 1194 string of the appropriate length consisting of zero octets. 1196 B.3 Message authentication schemes 1198 An example message authentication scheme for PBMAC1 (Section 7.1) is 1199 HMAC-SHA-1. 1201 B.3.1 HMAC-SHA-1 1203 HMAC-SHA-1 is the HMAC message authentication scheme [7] based on the 1204 SHA-1 hash function [18]. HMAC-SHA-1 has a variable key length and a 1205 20-octet (160-bit) message authentication code. 1207 The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies 1208 the HMAC-SHA-1 message authentication scheme. (The object identifier 1209 is the same for both the pseudorandom function and the message 1210 authentication scheme; the distinction is to be understood by 1211 context.) This object identifier is intended to be employed in the 1212 object set PBMAC1-Macs (Appendix A.5). 1214 C. ASN.1 module 1216 For reference purposes, the ASN.1 syntax in the preceding sections is 1217 presented as an ASN.1 module here. 1219 -- PKCS #5 v2.0 ASN.1 Module 1220 -- Revised March 25, 1999 1222 -- This module has been checked for conformance with the 1223 -- ASN.1 standard by the OSS ASN.1 Tools 1225 PKCS5v2-0 {iso(1) member-body(2) us(840) rsadsi(113549) 1226 pkcs(1) pkcs-5(5) modules(16) pkcs5v2-0(1)} 1228 DEFINITIONS ::= BEGIN 1230 -- Basic object identifiers 1232 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 1233 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 1234 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 1236 -- Basic types and classes 1238 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= 1239 SEQUENCE { 1240 algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), 1241 parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} 1242 {@algorithm}) OPTIONAL 1243 } 1245 ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER 1247 -- PBKDF2 1249 PBKDF2Algorithms ALGORITHM-IDENTIFIER ::= 1250 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ...} 1252 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 1254 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 1255 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 1257 PBKDF2-params ::= SEQUENCE { 1258 salt CHOICE { 1259 specified OCTET STRING, 1260 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 1261 }, 1262 iterationCount INTEGER (1..MAX), 1263 keyLength INTEGER (1..MAX) OPTIONAL, 1264 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 1265 algid-hmacWithSHA1 1266 } 1268 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 1270 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= 1271 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... } 1273 -- PBES1 1275 PBES1Algorithms ALGORITHM-IDENTIFIER ::= { 1276 {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} | 1277 {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} | 1278 {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} | 1279 {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} | 1280 {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} | 1281 {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC}, 1282 ... 1283 } 1285 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 1286 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 1287 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 1288 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 1289 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 1290 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 1292 PBEParameter ::= SEQUENCE { 1293 salt OCTET STRING (SIZE(8)), 1294 iterationCount INTEGER 1295 } 1297 -- PBES2 1299 PBES2Algorithms ALGORITHM-IDENTIFIER ::= 1300 { {PBES2-params IDENTIFIED BY id-PBES2}, ...} 1302 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 1304 PBES2-params ::= SEQUENCE { 1305 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 1306 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} 1307 } 1309 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 1310 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1312 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1314 -- PBMAC1 1316 PBMAC1Algorithms ALGORITHM-IDENTIFIER ::= 1317 { {PBMAC1-params IDENTIFIED BY id-PBMAC1}, ...} 1319 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1321 PBMAC1-params ::= SEQUENCE { 1322 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1323 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} 1324 } 1326 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 1327 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1329 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1331 -- Supporting techniques 1333 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1334 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1336 SupportingAlgorithms ALGORITHM-IDENTIFIER ::= { 1337 {NULL IDENTIFIED BY id-hmacWithSHA1} | 1338 {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} | 1339 {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} | 1340 {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} | 1341 {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}, 1342 ... 1343 } 1345 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1347 desCBC OBJECT IDENTIFIER ::= 1348 {iso(1) identified-organization(3) oiw(14) secsig(3) 1349 algorithms(2) 7} -- from OIW 1351 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1353 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1355 RC2-CBC-Parameter ::= SEQUENCE { 1356 rc2ParameterVersion INTEGER OPTIONAL, 1357 iv OCTET STRING (SIZE(8)) 1358 } 1360 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1362 RC5-CBC-Parameters ::= SEQUENCE { 1363 version INTEGER {v1-0(16)} (v1-0), 1364 rounds INTEGER (8..127), 1365 blockSizeInBits INTEGER (64 | 128), 1366 iv OCTET STRING OPTIONAL 1367 } 1369 END 1371 D. Intellectual property considerations 1373 RSA Security makes no patent claims on the general constructions 1374 described in this document, although specific underlying techniques 1375 may be covered. Among the underlying techniques, the RC5 encryption 1376 algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 1377 [22] and 5,835,600 [23]. 1379 RC2 and RC5 are trademarks of RSA Security. 1381 License to copy this document is granted provided that it is 1382 identified as RSA Security Inc. Public-Key Cryptography Standards 1383 (PKCS) in all material mentioning or referencing this document. 1385 RSA Security makes no representations regarding intellectual property 1386 claims by other parties. Such determination is the responsibility of 1387 the user. 1389 E. Revision history 1391 Versions 1.0-1.3 1393 Versions 1.0-1.3 were distributed to participants in RSA Data 1394 Security Inc.'s Public-Key Cryptography Standards meetings in 1395 February and March 1991. 1397 Version 1.4 1399 Version 1.4 was part of the June 3, 1991 initial public release of 1400 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1401 document SEC-SIG-91-20. 1403 Version 1.5 1405 Version 1.5 incorporated several editorial changes, including 1406 updates to the references and the addition of a revision history. 1408 Version 2.0 1410 Version 2.0 incorporates major editorial changes in terms of the 1411 document structure, and introduces the PBES2 encryption scheme, 1412 the PBMAC1 message authentication scheme, and independent 1413 password-based key derivation functions. This version continues to 1414 support the encryption process in version 1.5. 1416 F. References 1418 [1] American National Standard X9.52 - 1998, Triple Data Encryption 1419 Algorithm Modes of Operation. Working draft, Accredited Standards 1420 Committee X9, July 27, 1998. 1422 [2] R. Baldwin and R. Rivest. RFC 2040: The RC5, RC5-CBC, RC5-CBC- 1423 Pad, and RC5-CTS Algorithms. IETF, October 1996. 1425 [3] D. Balenson. RFC 1423: Privacy Enhancement for Internet 1426 Electronic Mail: Part III: Algorithms, Modes, and Identifiers. IETF, 1427 February 1993. 1429 [4] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password- 1430 based protocols secure against dictionary attacks. In Proceedings of 1431 the 1992 IEEE Computer Society Conference on Research in Security and 1432 Privacy, pages 72-84, IEEE Computer Society, 1992. 1434 [5] D. Jablon. Strong password-only authenticated key exchange. ACM 1435 Computer Communications Review, October 1996. 1437 [6] B. Kaliski. RFC 1319: The MD2 Message-Digest Algorithm. IETF, 1438 April 1992. 1440 [7] H. Krawczyk, M. Bellare, and R. Canetti. RFC 2104: HMAC: Keyed- 1441 Hashing for Message Authentication. IETF, February 1997. 1443 [8] Robert Morris and Ken Thompson. Password security: A case 1444 history. Communications of the ACM, 22(11):594-597, November 1979. 1446 [9] ISO/IEC 8824-1:1995: Information technology - Abstract Syntax 1447 Notation One (ASN.1) - Specification of basic notation. 1995. 1449 [10] ISO/IEC 8824-1:1995/Amd.1:1995 Information technology - Abstract 1450 Syntax Notation One (ASN.1) - Specification of basic notation - 1451 Amendment 1 - Rules of extensibility. 1995. 1453 [11] ISO/IEC 8824-2:1995 Information technology - Abstract Syntax 1454 Notation One (ASN.1) - Information object specification. 1995. 1456 [12] ISO/IEC 8824-2:1995/Amd.1:1995 Information technology - Abstract 1457 Syntax Notation One (ASN.1) - Information object specification - 1458 Amendment 1 - Rules of extensibility. 1995. 1460 [13] ISO/IEC 8824-3:1995 Information technology - Abstract Syntax 1461 Notation One (ASN.1) - Constraint specification. 1995. 1463 [14] ISO/IEC 8824-4:1995 Information technology - Abstract Syntax 1464 Notation One (ASN.1) - Parameterization of ASN.1 specifications. 1465 1995. 1467 [15] National Institute of Standards and Technology (NIST). FIPS PUB 1468 46-2: Data Encryption Standard. December 30, 1993. 1470 [16] National Institute of Standards and Technology (NIST). FIPS PUB 1471 81: DES Modes of Operation. December 2, 1980. 1473 [17] National Institute of Standards and Technology (NIST). FIPS PUB 1474 112: Password Usage. May 30, 1985. 1476 [18] National Institute of Standards and Technology (NIST). FIPS PUB 1477 180-1: Secure Hash Standard. April 1994. 1479 [19] R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. IETF, 1480 April 1992. 1482 [20] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the 1483 Second International Workshop on Fast Software Encryption, pages 86- 1484 96, Springer-Verlag, 1994. 1486 [21] R. Rivest. RFC 2268: A Description of the RC2(r) Encryption 1487 Algorithm. IETF, March 1998. 1489 [22] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent 1490 Rotations. U.S. Patent No. 5,724,428, March 3, 1998. 1492 [23] R.L. Rivest. Block Encryption Algorithm with Data-Dependent 1493 Rotations. U.S. Patent No. 5,835,600, November 10, 1998. 1495 [24] RSA Laboratories. PKCS #5: Password-Based Encryption Standard. 1496 Version 1.5, November 1993. 1498 [25] RSA Laboratories. PKCS #8: Private-Key Information Syntax 1499 Standard. Version 1.2, November 1993. 1501 [26] T. Wu. The Secure Remote Password protocol. In Proceedings of 1502 the 1998 Internet Society Network and Distributed System Security 1503 Symposium, pages 97-111, Internet Society, 1998. 1505 [27] F. Yergeau. RFC 2279: UTF-8, a Transformation Format of ISO 1506 10646. IETF, January 1998. 1508 G. Contact information & About PKCS 1510 The Public-Key Cryptography Standards are specifications produced by 1511 RSA Laboratories in cooperation with secure systems developers 1512 worldwide for the purpose of accelerating the deployment of public- 1513 key cryptography. First published in 1991 as a result of meetings 1514 with a small group of early adopters of public-key technology, the 1515 PKCS documents have become widely referenced and implemented. 1516 Contributions from the PKCS series have become part of many formal 1517 and de facto standards, including ANSI X9 documents, PKIX, SET, 1518 S/MIME, and SSL. 1520 Further development of PKCS occurs through mailing list discussions 1521 and occasional workshops, and suggestions for improvement are 1522 welcome. For more information, contact: 1524 PKCS Editor 1525 RSA Laboratories 1526 20 Crosby Drive 1527 Bedford, MA 01730 USA 1528 pkcs-editor@rsasecurity.com 1529 http://www.rsalabs.com/pkcs/