idnits 2.17.00 (12 Aug 2021) /tmp/idnits29328/draft-kaliski-pkcs5-v2-03.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages 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 842: '... keyLength INTEGER (1..MAX) OPTIONAL,...' RFC 2119 keyword, line 1127: '... rc2ParameterVersion INTEGER OPTIONAL,...' RFC 2119 keyword, line 1176: '... iv OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 1238: '... {@algorithm}) OPTIONAL...' RFC 2119 keyword, line 1259: '... keyLength INTEGER (1..MAX) OPTIONAL,...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 131 has weird spacing: '... dkLen leng...' == Line 135 has weird spacing: '... Hash und...' == Line 137 has weird spacing: '... hLen len...' == Line 155 has weird spacing: '... psLen leng...' == Line 167 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 (February 2000) is 8130 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 1494 looks like a reference -- Missing reference section? '4' on line 1425 looks like a reference -- Missing reference section? '5' on line 1430 looks like a reference -- Missing reference section? '26' on line 1497 looks like a reference -- Missing reference section? '24' on line 1491 looks like a reference -- Missing reference section? '8' on line 1439 looks like a reference -- Missing reference section? '27' on line 1501 looks like a reference -- Missing reference section? '17' on line 1469 looks like a reference -- Missing reference section? '6' on line 1433 looks like a reference -- Missing reference section? '19' on line 1475 looks like a reference -- Missing reference section? '18' on line 1472 looks like a reference -- Missing reference section? '15' on line 1463 looks like a reference -- Missing reference section? '21' on line 1482 looks like a reference -- Missing reference section? '16' on line 1466 looks like a reference -- Missing reference section? '3' on line 1421 looks like a reference -- Missing reference section? '9' on line 1442 looks like a reference -- Missing reference section? '10' on line 1445 looks like a reference -- Missing reference section? '11' on line 1449 looks like a reference -- Missing reference section? '12' on line 1452 looks like a reference -- Missing reference section? '13' on line 1456 looks like a reference -- Missing reference section? '14' on line 1459 looks like a reference -- Missing reference section? '7' on line 1436 looks like a reference -- Missing reference section? '1' on line 1414 looks like a reference -- Missing reference section? '20' on line 1478 looks like a reference -- Missing reference section? '2' on line 1418 looks like a reference -- Missing reference section? '22' on line 1485 looks like a reference -- Missing reference section? '23' on line 1488 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT B. Kaliski 2 Expires: August 2000 RSA Laboratories 3 Intended Category: Informational February 2000 5 Password-Based Cryptography Specification 6 PKCS #5 v2.0 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 except that the right to 14 produce derivative works is not granted. This document represents a 15 republication of PKCS#5 v 2.0 from RSA Laboratories' Public-Key 16 Cryptography Standards (PKCS) series, and change control is retained 17 within the PKCS process. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document provides recommendations for the implementation of 37 password-based cryptography, covering key derivation functions, 38 encryption schemes, message-authentication schemes, and ASN.1 syntax 39 identifying the techniques. 41 The recommendations are intended for general application within 42 computer and communications systems, and as such include a fair 43 amount of flexibility. They are particularly intended for the 44 protection of sensitive information such as private keys, as in PKCS 45 #8 [25]. It is expected that application standards and implementation 46 profiles based on these specifications may include additional 47 constraints. 49 Other cryptographic techniques based on passwords, such as password- 50 based key entity authentication and key establishment protocols 51 [4][5][26] are outside the scope of this document. Guidelines for the 52 selection of passwords are also outside the scope. 54 Table of Contents 56 1 Introduction ................................................. 3 57 2 Notation ..................................................... 3 58 3 Overview ..................................................... 4 59 4 Salt and Iteration Count ..................................... 6 60 4.1 Salt .................................................... 6 61 4.2 Iteration Count ......................................... 8 62 5 Key Derivation Functions ..................................... 8 63 5.1 PBKDF1 .................................................. 9 64 5.2 PBKDF2 .................................................. 9 65 6 Encryption Schemes ........................................... 11 66 6.1 PBES1 ................................................... 12 67 6.1.1 Encryption Operation ............................. 12 68 6.1.2 Decryption Operation ............................. 13 69 6.2 PBES2 ................................................... 14 70 6.2.1 Encryption Operation ............................. 14 71 6.2.2 Decryption Operation ............................. 15 72 7 Message Authentication Schemes ............................... 15 73 7.1 PBMAC1 .................................................. 15 74 7.1.1 MAC Generation ................................... 16 75 7.1.2 MAC Verification ................................. 16 76 8 Security Considerations ...................................... 17 77 9 Author's Address.............................................. 17 79 Appendices 81 A ASN.1 Syntax ................................................. 18 82 A.1 PBKDF1 .................................................. 18 83 A.2 PBKDF2 .................................................. 18 84 A.3 PBES1 ................................................... 20 85 A.4 PBES2 ................................................... 20 86 A.5 PBMAC1 .................................................. 21 87 B Supporting Techniques ........................................ 22 88 B.1 Pseudorandom Functions .................................. 22 89 B.2 Encryption Schemes ...................................... 23 90 B.3 Message Authentication Schemes .......................... 26 91 C ASN.1 Module ................................................. 26 92 D Intellectual Property Considerations ......................... 30 93 E Revision History ............................................. 30 94 F References ................................................... 31 95 G Contact Information & About PKCS ............................. 33 97 1. Introduction 99 This document provides recommendations for the implementation of 100 password-based cryptography, covering the following aspects: 102 - key derivation functions 103 - encryption schemes 104 - message-authentication schemes 105 - ASN.1 syntax identifying the techniques 107 The recommendations are intended for general application within 108 computer and communications systems, and as such include a fair 109 amount of flexibility. They are particularly intended for the 110 protection of sensitive information such as private keys, as in PKCS 111 #8 [25]. It is expected that application standards and implementation 112 profiles based on these specifications may include additional 113 constraints. 115 Other cryptographic techniques based on passwords, such as password- 116 based key entity authentication and key establishment protocols 117 [4][5][26] are outside the scope of this document. Guidelines for the 118 selection of passwords are also outside the scope. 120 This document supersedes PKCS #5 version 1.5 [24], but includes 121 compatible techniques. 123 2. Notation 125 C ciphertext, an octet string 127 c iteration count, a positive integer 129 DK derived key, an octet string 131 dkLen length in octets of derived key, a positive integer 133 EM encoded message, an octet string 135 Hash underlying hash function 137 hLen length in octets of pseudorandom function output, a positive 138 integer 140 l length in blocks of derived key, a positive integer 142 IV initialization vector, an octet string 144 K encryption key, an octet string 145 KDF key derivation function 147 M message, an octet string 149 P password, an octet string 151 PRF underlying pseudorandom function 153 PS padding string, an octet string 155 psLen length in octets of padding string, a positive integer 157 S salt, an octet string 159 T message authentication code, an octet string 161 T_1, ..., T_l, U_1, ..., U_c 162 intermediate values, octet strings 164 01, 02, ..., 08 165 octets with value 1, 2, ..., 8 167 \xor bit-wise exclusive-or of two octet strings 169 || || octet length operator 171 || concatenation operator 173 substring extraction operator: extracts octets i through j, 174 0 <= i <= j 176 3. Overview 178 In many applications of public-key cryptography, user security is 179 ultimately dependent on one or more secret text values or passwords. 180 Since a password is not directly applicable as a key to any 181 conventional cryptosystem, however, some processing of the password 182 is required to perform cryptographic operations with it. Moreover, as 183 passwords are often chosen from a relatively small space, special 184 care is required in that processing to defend against search attacks. 186 A general approach to password-based cryptography, as described by 187 Morris and Thompson [8] for the protection of password tables, is to 188 combine a password with a salt to produce a key. The salt can be 189 viewed as an index into a large set of keys derived from the 190 password, and need not be kept secret. Although it may be possible 191 for an opponent to construct a table of possible passwords (a so- 192 called "dictionary attack"), constructing a table of possible keys 193 will be difficult, since there will be many possible keys for each 194 password. An opponent will thus be limited to searching through 195 passwords separately for each salt. 197 Another approach to password-based cryptography is to construct key 198 derivation techniques that are relatively expensive, thereby 199 increasing the cost of exhaustive search. One way to do this is to 200 include an iteration count in the key derivation technique, 201 indicating how many times to iterate some underlying function by 202 which keys are derived. A modest number of iterations, say 1000, is 203 not likely to be a burden for legitimate parties when computing a 204 key, but will be a significant burden for opponents. 206 Salt and iteration count formed the basis for password-based 207 encryption in PKCS #5 v1.5, and adopted here as well for the various 208 cryptographic operations. Thus, password-based key derivation as 209 defined here is a function of a password, a salt, and an iteration 210 count, where the latter two quantities need not be kept secret. 212 From a password-based key derivation function, it is straightforward 213 to define password-based encryption and message authentication 214 schemes. As in PKCS #5 v1.5, the password-based encryption schemes 215 here are based on an underlying, conventional encryption scheme, 216 where the key for the conventional scheme is derived from the 217 password. Similarly, the password-based message authentication scheme 218 is based on an underlying conventional scheme. This two- layered 219 approach makes the password-based techniques modular in terms of the 220 underlying techniques they can be based on. 222 It is expected that the password-based key derivation functions may 223 find other applications than just the encryption and message 224 authentication schemes defined here. For instance, one might derive a 225 set of keys with a single application of a key derivation function, 226 rather than derive each key with a separate application of the 227 function. The keys in the set would be obtained as substrings of the 228 output of the key derivation function. This approach might be 229 employed as part of key establishment in a session-oriented protocol. 230 Another application is password checking, where the output of the key 231 derivation function is stored (along with the salt and iteration 232 count) for the purposes of subsequent verification of a password. 234 Throughout this document, a password is considered to be an octet 235 string of arbitrary length whose interpretation as a text string is 236 unspecified. In the interest of interoperability, however, it is 237 recommended that applications follow some common text encoding rules. 238 ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of 239 UTF-8.) 240 Although the selection of passwords is outside the scope of this 241 document, guidelines have been published [17] that may well be taken 242 into account. 244 4. Salt and iteration count 246 Inasmuch as salt and iteration count are central to the techniques 247 defined in this document, some further discussion is warranted. 249 4.1 Salt 251 A salt in password-based cryptography has traditionally served the 252 purpose of producing a large set of keys corresponding to a given 253 password, among which one is selected at random according to the 254 salt. An individual key in the set is selected by applying a key 255 derivation function KDF, as 257 DK = KDF (P, S) 259 where DK is the derived key, P is the password, and S is the salt. 260 This has two benefits: 262 1. It is difficult for an opponent to precompute all the keys 263 corresponding to a dictionary of passwords, or even the 264 most likely keys. If the salt is 64 bits long, for 265 instance, there will be as many as 2^64 keys for each 266 password. An opponent is thus limited to searching for 267 passwords after a password-based operation has been 268 performed and the salt is known. 270 2. It is unlikely that the same key will be selected twice. 271 Again, if the salt is 64 bits long, the chance of 272 "collision" between keys does not become significant until 273 about 2^32 keys have been produced, according to the 274 Birthday Paradox. This addresses some of the concerns about 275 interactions between multiple uses of the same key, which 276 may apply for some encryption and authentication 277 techniques. 279 In password-based encryption, the party encrypting a message can gain 280 assurance that these benefits are realized simply by selecting a 281 large and sufficiently random salt when deriving an encryption key 282 from a password. A party generating a message authentication code can 283 gain such assurance in a similar fashion. 285 The party decrypting a message or verifying a message authentication 286 code, however, cannot be sure that a salt supplied by another party 287 has actually been generated at random. It is possible, for instance, 288 that the salt may have been copied from another password-based 289 operation, in an attempt to exploit interactions between multiple 290 uses of the same key. For instance, suppose two legitimate parties 291 exchange a encrypted message, where the encryption key is an 80-bit 292 key derived from a shared password with some salt. An opponent could 293 take the salt from that encryption and provide it to one of the 294 parties as though it were for a 40-bit key. If the party reveals the 295 result of decryption with the 40-bit key, the opponent may be able to 296 solve for the 40-bit key. In the case that 40-bit key is the first 297 half of the 80-bit key, the opponent can then readily solve for the 298 remaining 40 bits of the 80-bit key. 300 To defend against such attacks, either the interaction between 301 multiple uses of the same key should be carefully analyzed, or the 302 salt should contain data that explicitly distinguishes between 303 different operations. For instance, the salt might have an 304 additional, non-random octet that specifies whether the derived key 305 is for encryption, for message authentication, or for some other 306 operation. 308 Based on this, the following is recommended for salt selection: 310 1. If there is no concern about interactions between multiple 311 uses of the same key (or a prefix of that key) with the 312 password-based encryption and authentication techniques 313 supported for a given password, then the salt may be 314 generated at random and need not be checked for a 315 particular format by the party receiving the salt. It 316 should be at least eight octets (64 bits) long. 318 2. Otherwise, the salt should contain data that explicitly 319 distinguishes between different operations and different 320 key lengths, in addition to a random part that is at least 321 eight octets long, and this data should be checked or 322 regenerated by the party receiving the salt. For instance, 323 the salt could have an additional non-random octet that 324 specifies the purpose of the derived key. Alternatively, 325 it could be the encoding of a structure that specifies 326 detailed information about the derived key, such as the 327 encryption or authentication technique and a sequence 328 number among the different keys derived from the password. 329 The particular format of the additional data is left to the 330 application. 332 Note. If a random number generator or pseudorandom generator is not 333 available, a deterministic alternative for generating the salt (or 334 the random part of it) is to apply a password-based key derivation 335 function to the password and the message M to be processed. For 336 instance, the salt could be computed with a key derivation function 337 as S = KDF (P, M). This approach is not recommended if the message M 338 is known to belong to a small message space (e.g., "Yes" or "No"), 339 however, since then there will only be a small number of possible 340 salts. 342 4.2 Iteration count 344 An iteration count has traditionally served the purpose of increasing 345 the cost of producing keys from a password, thereby also increasing 346 the difficulty of attack. For the methods in this document, a minimum 347 of 1000 iterations is recommended. This will increase the cost of 348 exhaustive search for passwords significantly, without a noticeable 349 impact in the cost of deriving individual keys. 351 5. Key derivation functions 353 A key derivation function produces a derived key from a base key and 354 other parameters. In a password-based key derivation function, the 355 base key is a password and the other parameters are a salt value and 356 an iteration count, as outlined in Section 3. 358 The primary application of the password-based key derivation 359 functions defined here is in the encryption schemes in Section 6 and 360 the message authentication scheme in Section 7. Other applications 361 are certainly possible, hence the independent definition of these 362 functions. 364 Two functions are specified in this section: PBKDF1 and PBKDF2. 365 PBKDF2 is recommended for new applications; PBKDF1 is included only 366 for compatibility with existing applications, and is not recommended 367 for new applications. 369 A typical application of the key derivation functions defined here 370 might include the following steps: 372 1. Select a salt S and an iteration count c, as outlined in 373 Section 4. 375 2. Select a length in octets for the derived key, dkLen. 377 3. Apply the key derivation function to the password, the 378 salt, the iteration count and the key length to produce a 379 derived key. 381 4. Output the derived key. 383 Any number of keys may be derived from a password by varying the 384 salt, as described in Section 3. 386 5.1 PBKDF1 388 PBKDF1 applies a hash function, which shall be MD2 [6], MD5 [19] or 389 SHA-1 [18], to derive keys. The length of the derived key is bounded 390 by the length of the hash function output, which is 16 octets for MD2 391 and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key 392 derivation process in PKCS #5 v1.5. 394 PBKDF1 is recommended only for compatibility with existing 395 applications since the keys it produces may not be large enough for 396 some applications. 398 PBKDF1 (P, S, c, dkLen) 400 Options: Hash underlying hash function 402 Input: P password, an octet string 403 S salt, an eight-octet string 404 c iteration count, a positive integer 405 dkLen intended length in octets of derived key, 406 a positive integer, at most 16 for MD2 or 407 MD5 and 20 for SHA-1 409 Output: DK derived key, a dkLen-octet string 411 Steps: 413 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, 414 output "derived key too long" and stop. 416 2. Apply the underlying hash function Hash for c iterations to 417 the concatenation of the password P and the salt S, then 418 extract the first dkLen octets to produce a derived key DK: 420 T_1 = Hash (P || S) , 421 T_2 = Hash (T_1) , 422 ... 423 T_c = Hash (T_{c-1}) , 424 DK = Tc<0..dkLen-1> 426 3. Output the derived key DK. 428 5.2 PBKDF2 430 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an 431 example) to derive keys. The length of the derived key is essentially 432 unbounded. (However, the maximum effective search space for the 433 derived key may be limited by the structure of the underlying 434 pseudorandom function. See Appendix B.1 for further discussion.) 435 PBKDF2 is recommended for new applications. 437 PBKDF2 (P, S, c, dkLen) 439 Options: PRF underlying pseudorandom function (hLen 440 denotes the length in octets of the 441 pseudorandom function output) 443 Input: P password, an octet string 444 S salt, an octet string 445 c iteration count, a positive integer 446 dkLen intended length in octets of the derived 447 key, a positive integer, at most 448 (2^32 - 1) * hLen 450 Output: DK derived key, a dkLen-octet string 452 Steps: 454 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" 455 and stop. 457 2. Let l be the number of hLen-octet blocks in the derived key, 458 rounding up, and let r be the number of octets in the last 459 block: 461 l = CEIL (dkLen / hLen) , 462 r = dkLen - (l - 1) * hLen . 464 Here, CEIL (x) is the "ceiling" function, i.e. the smallest 465 integer greater than, or equal to, x. 467 3. For each block of the derived key apply the function F 468 defined below to the password P, the salt S, the iteration 469 count c, and the block index to compute the block: 471 T_1 = F (P, S, c, 1) , 472 T_2 = F (P, S, c, 2) , 473 ... 474 T_l = F (P, S, c, l) , 476 where the function F is defined as the exclusive-or sum of 477 the first c iterates of the underlying pseudorandom function 478 PRF applied to the password P and the concatenation of the 479 salt S and the block index i: 481 F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c 483 where 485 U_1 = PRF (P, S || INT (i)) , 486 U_2 = PRF (P, U_1) , 487 ... 488 U_c = PRF (P, U_{c-1}) . 490 Here, INT (i) is a four-octet encoding of the integer i, most 491 significant octet first. 493 4. Concatenate the blocks and extract the first dkLen octets to 494 produce a derived key DK: 496 DK = T_1 || T_2 || ... || T_l<0..r-1> 498 5. Output the derived key DK. 500 Note. The construction of the function F follows a "belt-and- 501 suspenders" approach. The iterates U_i are computed recursively to 502 remove a degree of parallelism from an opponent; they are exclusive- 503 ored together to reduce concerns about the recursion degenerating 504 into a small set of values. 506 6. Encryption schemes 508 An encryption scheme, in the symmetric setting, consists of an 509 encryption operation and a decryption operation, where the encryption 510 operation produces a ciphertext from a message under a key, and the 511 decryption operation recovers the message from the ciphertext under 512 the same key. In a password-based encryption scheme, the key is a 513 password. 515 A typical application of a password-based encryption scheme is a 516 private-key protection method, where the message contains private-key 517 information, as in PKCS #8. The encryption schemes defined here would 518 be suitable encryption algorithms in that context. 520 Two schemes are specified in this section: PBES1 and PBES2. PBES2 is 521 recommended for new applications; PBES1 is included only for 522 compatibility with existing applications, and is not recommended for 523 new applications. 525 6.1 PBES1 527 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying 528 block cipher, which shall be either DES [15] or RC2(tm) [21] in CBC 529 mode [16]. PBES1 is compatible with the encryption scheme in PKCS #5 530 v1.5. 532 PBES1 is recommended only for compatibility with existing 533 applications, since it supports only two underlying encryption 534 schemes, each of which has a key size (56 or 64 bits) that may not be 535 large enough for some applications. 537 6.1.1 Encryption operation 539 The encryption operation for PBES1 consists of the following steps, 540 which encrypt a message M under a password P to produce a ciphertext 541 C: 543 1. Select an eight-octet salt S and an iteration count c, as 544 outlined in Section 4. 546 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 547 password P, the salt S, and the iteration count c to produce 548 at derived key DK of length 16 octets: 550 DK = PBKDF1 (P, S, c, 16) . 552 3. Separate the derived key DK into an encryption key K 553 consisting of the first eight octets of DK and an 554 initialization vector IV consisting of the next eight octets: 556 K = DK<0..7> , 557 IV = DK<8..15> . 559 4. Concatenate M and a padding string PS to form an encoded 560 message EM: 562 EM = M || PS , 564 where the padding string PS consists of 8-(||M|| mod 8) 565 octets each with value 8-(||M|| mod 8). The padding string PS 566 will satisfy one of the following statements: 568 PS = 01, if ||M|| mod 8 = 7 ; 569 PS = 02 02, if ||M|| mod 8 = 6 ; 570 ... 571 PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0. 573 The length in octets of the encoded message will be a 574 multiple of eight and it will be possible to recover the 575 message M unambiguously from the encoded message. (This 576 padding rule is taken from RFC 1423 [3].) 578 5. Encrypt the encoded message EM with the underlying block 579 cipher (DES or RC2) in cipher block chaining mode under the 580 encryption key K with initialization vector IV to produce the 581 ciphertext C. For DES, the key K shall be considered as a 582 64-bit encoding of a 56-bit DES key with parity bits ignored 583 (see [9]). For RC2, the "effective key bits" shall be 64 584 bits. 586 6. Output the ciphertext C. 588 The salt S and the iteration count c may be conveyed to the party 589 performing decryption in an AlgorithmIdentifier value (see Appendix 590 A.3). 592 6.1.2 Decryption operation 594 The decryption operation for PBES1 consists of the following steps, 595 which decrypt a ciphertext C under a password P to recover a message 596 M: 598 1. Obtain the eight-octet salt S and the iteration count c. 600 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 601 password P, the salt S, and the iteration count c to produce 602 a derived key DK of length 16 octets: 604 DK = PBKDF1 (P, S, c, 16) 606 3. Separate the derived key DK into an encryption key K 607 consisting of the first eight octets of DK and an 608 initialization vector IV consisting of the next eight octets: 610 K = DK<0..7> , 611 IV = DK<8..15> . 613 4. Decrypt the ciphertext C with the underlying block cipher 614 (DES or RC2) in cipher block chaining mode under the 615 encryption key K with initialization vector IV to recover an 616 encoded message EM. If the length in octets of the ciphertext 617 C is not a multiple of eight, output "decryption error" and 618 stop. 620 5. Separate the encoded message EM into a message M and a 621 padding string PS: 623 EM = M || PS , 625 where the padding string PS consists of some number psLen 626 octets each with value psLen, where psLen is between 1 and 8. 627 If it is not possible to separate the encoded message EM in 628 this manner, output "decryption error" and stop. 630 6. Output the recovered message M. 632 6.2 PBES2 634 PBES2 combines a password-based key derivation function, which shall 635 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 636 underlying encryption scheme (see Appendix B.2 for examples). The key 637 length and any other parameters for the underlying encryption scheme 638 depend on the scheme. 640 PBES2 is recommended for new applications. 642 6.2.1 Encryption operation 644 The encryption operation for PBES2 consists of the following steps, 645 which encrypt a message M under a password P to produce a ciphertext 646 C, applying a selected key derivation function KDF and a selected 647 underlying encryption scheme: 649 1. Select a salt S and an iteration count c, as outlined in 650 Section 4. 652 2. Select the length in octets, dkLen, for the derived key for 653 the underlying encryption scheme. 655 3. Apply the selected key derivation function to the password P, 656 the salt S, and the iteration count c to produce a derived 657 key DK of length dkLen octets: 659 DK = KDF (P, S, c, dkLen) . 661 4. Encrypt the message M with the underlying encryption scheme 662 under the derived key DK to produce a ciphertext C. (This 663 step may involve selection of parameters such as an 664 initialization vector and padding, depending on the 665 underlying scheme.) 667 5. Output the ciphertext C. 669 The salt S, the iteration count c, the key length dkLen, and 670 identifiers for the key derivation function and the underlying 671 encryption scheme may be conveyed to the party performing decryption 672 in an AlgorithmIdentifier value (see Appendix A.4). 674 6.2.2 Decryption operation 676 The decryption operation for PBES2 consists of the following steps, 677 which decrypt a ciphertext C under a password P to recover a message 678 M: 680 1. Obtain the salt S for the operation. 682 2. Obtain the iteration count c for the key derivation function. 684 3. Obtain the key length in octets, dkLen, for the derived key 685 for the underlying encryption scheme. 687 4. Apply the selected key derivation function to the password P, 688 the salt S, and the iteration count c to produce a derived 689 key DK of length dkLen octets: 691 DK = KDF (P, S, c, dkLen) . 693 5. Decrypt the ciphertext C with the underlying encryption 694 scheme under the derived key DK to recover a message M. If 695 the decryption function outputs "decryption error," then 696 output "decryption error" and stop. 698 6. Output the recovered message M. 700 7. Message authentication schemes 702 A message authentication scheme consists of a MAC (message 703 authentication code) generation operation and a MAC verification 704 operation, where the MAC generation operation produces a message 705 authentication code from a message under a key, and the MAC 706 verification operation verifies the message authentication code under 707 the same key. In a password-based message authentication scheme, the 708 key is a password. 710 One scheme is specified in this section: PBMAC1. 712 7.1 PBMAC1 714 PBMAC1 combines a password-based key derivation function, which shall 715 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 716 underlying message authentication scheme (see Appendix B.3 for an 717 example). The key length and any other parameters for the underlying 718 message authentication scheme depend on the scheme. 720 7.1.1 MAC generation 722 The MAC generation operation for PBMAC1 consists of the following 723 steps, which process a message M under a password P to generate a 724 message authentication code T, applying a selected key derivation 725 function KDF and a selected underlying message authentication scheme: 727 1. Select a salt S and an iteration count c, as outlined in 728 Section 4. 730 2. Select a key length in octets, dkLen, for the derived key for 731 the underlying message authentication function. 733 3. Apply the selected key derivation function to the password P, 734 the salt S, and the iteration count c to produce a derived 735 key DK of length dkLen octets: 737 DK = KDF (P, S, c, dkLen) . 739 4. Process the message M with the underlying message 740 authentication scheme under the derived key DK to generate a 741 message authentication code T. 743 5. Output the message authentication code T. 745 The salt S, the iteration count c, the key length dkLen, and 746 identifiers for the key derivation function and underlying message 747 authentication scheme may be conveyed to the party performing 748 verification in an AlgorithmIdentifier value (see Appendix A.5). 750 7.1.2 MAC verification 752 The MAC verification operation for PBMAC1 consists of the following 753 steps, which process a message M under a password P to verify a 754 message authentication code T: 756 1. Obtain the salt S and the iteration count c. 758 2. Obtain the key length in octets, dkLen, for the derived key 759 for the underlying message authentication scheme. 761 3. Apply the selected key derivation function to the password P, 762 the salt S, and the iteration count c to produce a derived 763 key DK of length dkLen octets: 765 DK = KDF (P, S, c, dkLen) . 767 4. Process the message M with the underlying message 768 authentication scheme under the derived key DK to verify the 769 message authentication code T. 771 5. If the message authentication code verifies, output 772 "correct"; else output "incorrect." 774 8. Security Considerations 776 Password-based cryptography is generally limited in the security that 777 it can provide, particularly for methods such as those defined in 778 this document where off-line password search is possible. While the 779 use of salt and iteration count can increase the complexity of attack 780 (see Section 4 for recommendations), it is essential that passwords 781 are selected well, and relevant guidelines (e.g., [17]) should be 782 taken into account. It is also important that passwords be protected 783 well if stored. 785 In general, different keys should be derived from a password for 786 different uses to minimize the possibility of unintended 787 interactions. For password-based encryption with a single algorithm, 788 a random salt is sufficient to ensure that different keys will be 789 produced. In certain other situations, as outlined in Section 4, a 790 structured salt is necessary. The recommendations in Section 4 should 791 thus be taken into account when selecting the salt value. 793 9. Author's Address 795 Burt Kaliski 796 RSA Laboratories 797 20 Crosby Drive 798 Bedford, MA 01730 USA 800 Email: bkaliski@rsasecurity.com 802 APPENDICES 804 A. ASN.1 syntax 806 This section defines ASN.1 syntax for the key derivation functions, 807 the encryption schemes, the message authentication scheme, and 808 supporting techniques. The intended application of these definitions 809 includes PKCS #8 and other syntax for key management, encrypted data, 810 and integrity-protected data. (Various aspects of ASN.1 are specified 811 in several ISO/IEC standards [9][10][11][12][13][14].) 813 The object identifier pkcs-5 identifies the arc of the OID tree from 814 which the PKCS #5-specific OIDs in this section are derived: 816 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 817 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 818 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 820 A.1 PBKDF1 822 No object identifier is given for PBKDF1, as the object identifiers 823 for PBES1 are sufficient for existing applications and PBKDF2 is 824 recommended for new applications. 826 A.2 PBKDF2 828 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation 829 function (Section 5.2). 831 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 833 The parameters field associated with this OID in an 834 AlgorithmIdentifier shall have type PBKDF2-params: 836 PBKDF2-params ::= SEQUENCE { 837 salt CHOICE { 838 specified OCTET STRING, 839 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 840 }, 841 iterationCount INTEGER (1..MAX), 842 keyLength INTEGER (1..MAX) OPTIONAL, 843 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 844 algid-hmacWithSHA1 } 846 The fields of type PKDF2-params have the following meanings: 848 - salt specifies the salt value, or the source of the salt value. 849 It shall either be an octet string or an algorithm ID with an OID 850 in the set PBKDF2-SaltSources, which is reserved for future 851 versions of PKCS #5. 853 The salt-source approach is intended to indicate how the salt 854 value is to be generated as a function of parameters in the 855 algorithm ID, application data, or both. For instance, it may 856 indicate that the salt value is produced from the encoding of 857 a structure that specifies detailed information about the derived 858 key as suggested in Section 4.1. Some of the information may be 859 carried elsewhere, e.g., in the encryption algorithm ID. However, 860 such facilities are deferred to a future version of PKCS #5. 862 In this version, an application may achieve the benefits 863 mentioned in Section 4.1 by choosing a particular interpretation 864 of the salt value in the specified alternative. 866 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 868 - iterationCount specifies the iteration count. The maximum 869 iteration count allowed depends on the implementation. It is 870 expected that implementation profiles may further constrain the 871 bounds. 873 - keyLength, an optional field, is the length in octets of the 874 derived key. The maximum key length allowed depends on the 875 implementation; it is expected that implementation profiles may 876 further constrain the bounds. The field is provided for 877 convenience only; the key length is not cryptographically 878 protected. If there is concern about interaction between 879 operations with different key lengths for a given salt (see 880 Section 4.1), the salt should distinguishes among the different 881 key lengths. 883 - prf identifies the underlying pseudorandom function. It shall be 884 an algorithm ID with an OID in the set PBKDF2-PRFs, which for 885 this version of PKCS #5 shall consist of id-hmacWithSHA1 (see 886 Appendix B.1.1) and any other OIDs defined by the application. 888 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= 889 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... } 891 The default pseudorandom function is HMAC-SHA-1: 893 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 894 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 896 A.3 PBES1 898 Different object identifiers identify the PBES1 encryption scheme 899 (Section 6.1) according to the underlying hash function in the key 900 derivation function and the underlying block cipher, as summarized in 901 the following table: 903 Hash Function Block Cipher OID 904 MD2 DES pkcs-5.1 905 MD2 RC2 pkcs-5.4 906 MD5 DES pkcs-5.3 907 MD5 RC2 pkcs-5.6 908 SHA-1 DES pkcs-5.10 909 SHA-1 RC2 pkcs-5.11 911 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 912 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 913 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 914 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 915 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 916 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 918 For each OID, the parameters field associated with the OID in an 919 AlgorithmIdentifier shall have type PBEParameter: 921 PBEParameter ::= SEQUENCE { 922 salt OCTET STRING (SIZE(8)), 923 iterationCount INTEGER } 925 The fields of type PBEParameter have the following meanings: 927 - salt specifies the salt value, an eight-octet string. 929 - iterationCount specifies the iteration count. 931 A.4 PBES2 933 The object identifier id-PBES2 identifies the PBES2 encryption scheme 934 (Section 6.2). 936 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 938 The parameters field associated with this OID in an 939 AlgorithmIdentifier shall have type PBES2-params: 941 PBES2-params ::= SEQUENCE { 942 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 943 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } 945 The fields of type PBES2-params have the following meanings: 947 - keyDerivationFunc identifies the underlying key derivation 948 function. It shall be an algorithm ID with an OID in the set 949 PBES2-KDFs, which for this version of PKCS #5 shall consist of 950 id-PBKDF2 (Appendix A.2). 952 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 953 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 955 - encryptionScheme identifies the underlying encryption scheme. It 956 shall be an algorithm ID with an OID in the set PBES2-Encs, whose 957 definition is left to the application. Example underlying 958 encryption schemes are given in Appendix B.2. 960 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 962 A.5 PBMAC1 964 The object identifier id-PBMAC1 identifies the PBMAC1 message 965 authentication scheme (Section 7.1). 967 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 969 The parameters field associated with this OID in an 970 AlgorithmIdentifier shall have type PBMAC1-params: 972 PBMAC1-params ::= SEQUENCE { 973 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 974 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } 976 The keyDerivationFunc field has the same meaning as the corresponding 977 field of PBES2-params (Appendix A.4) except that the set of OIDs is 978 PBMAC1-KDFs. 980 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 981 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 983 The messageAuthScheme field identifies the underlying message 984 authentication scheme. It shall be an algorithm ID with an OID in the 985 set PBMAC1-MACs, whose definition is left to the application. Example 986 underlying encryption schemes are given in Appendix B.3. 988 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 990 B. Supporting techniques 992 This section gives several examples of underlying functions and 993 schemes supporting the password-based schemes in Sections 5, 6 and 7. 995 While these supporting techniques are appropriate for applications to 996 implement, none of them is required to be implemented. It is 997 expected, however, that profiles for PKCS #5 will be developed that 998 specify particular supporting techniques. 1000 This section also gives object identifiers for the supporting 1001 techniques. The object identifiers digestAlgorithm and 1002 encryptionAlgorithm identify the arcs from which certain algorithm 1003 OIDs referenced in this section are derived: 1005 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1006 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1008 B.1 Pseudorandom functions 1010 An example pseudorandom function for PBKDF2 (Section 5.2) is HMAC- 1011 SHA-1. 1013 B.1.1 HMAC-SHA-1 1015 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC 1016 message authentication code [7] based on the SHA-1 hash function 1017 [18]. The pseudorandom function is the same function by which the 1018 message authentication code is computed, with a full-length output. 1019 (The first argument to the pseudorandom function PRF serves as HMAC's 1020 "key," and the second serves as HMAC's "text." In the case of PBKDF2, 1021 the "key" is thus the password and the "text" is the salt.) HMAC- 1022 SHA-1 has a variable key length and a 20-octet (160-bit) output 1023 value. 1025 Although the length of the key to HMAC-SHA-1 is essentially 1026 unbounded, the effective search space for pseudorandom function 1027 outputs may be limited by the structure of the function. In 1028 particular, when the key is longer than 512 bits, HMAC-SHA-1 will 1029 first hash it to 160 bits. Thus, even if a long derived key 1030 consisting of several pseudorandom function outputs is produced from 1031 a key, the effective search space for the derived key will be at most 1032 160 bits. Although the specific limitation for other key sizes 1033 depends on details of the HMAC construction, one should assume, to be 1034 conservative, that the effective search space is limited to 160 bits 1035 for other key sizes as well. 1037 (The 160-bit limitation should not generally pose a practical 1038 limitation in the case of password-based cryptography, since the 1039 search space for a password is unlikely to be greater than 160 bits.) 1041 The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1 1042 pseudorandom function: 1044 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1046 The parameters field associated with this OID in an 1047 AlgorithmIdentifier shall have type NULL. This object identifier is 1048 employed in the object set PBKDF2-PRFs (Appendix A.2). 1050 Note. Although HMAC-SHA-1 was designed as a message authentication 1051 code, its proof of security is readily modified to accommodate 1052 requirements for a pseudorandom function, under stronger assumptions. 1054 A hash function may also meet the requirements of a pseudorandom 1055 function under certain assumptions. For instance, the direct 1056 application of a hash function to to the concatenation of the "key" 1057 and the "text" may be appropriate, provided that "text" has 1058 appropriate structure to prevent certain attacks. HMAC-SHA-1 is 1059 preferable, however, because it treats "key" and "text" as separate 1060 arguments and does not require "text" to have any structure. 1062 B.2 Encryption schemes 1064 Example pseudorandom functions for PBES2 (Section 6.2) are DES-CBC- 1065 Pad, DES-EDE2-CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad. 1067 The object identifiers given in this section are intended to be 1068 employed in the object set PBES2-Encs (Appendix A.4). 1070 B.2.1 DES-CBC-Pad 1072 DES-CBC-Pad is single-key DES [15] in CBC mode [16] with the RFC 1423 1073 padding operation (see Section 6.1.1). DES-CBC-Pad has an eight-octet 1074 encryption key and an eight-octet initialization vector. The key is 1075 considered as a 64-bit encoding of a 56-bit DES key with parity bits 1076 ignored. 1078 The object identifier desCBC (defined in the NIST/OSI Implementors' 1079 Workshop agreements) identifies the DES-CBC-Pad encryption scheme: 1081 desCBC OBJECT IDENTIFIER ::= 1082 {iso(1) identified-organization(3) oiw(14) secsig(3) 1083 algorithms(2) 7} 1085 The parameters field associated with this OID in an 1086 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1087 specifying the initialization vector for CBC mode. 1089 B.2.2 DES-EDE3-CBC-Pad 1091 DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [1] with the RFC 1092 1423 padding operation. DES-EDE3-CBC-Pad has a 24-octet encryption 1093 key and an eight-octet initialization vector. The key is considered 1094 as the concatenation of three eight-octet keys, each of which is a 1095 64-bit encoding of a 56-bit DES key with parity bits ignored. 1097 The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad 1098 encryption scheme: 1100 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1102 The parameters field associated with this OID in an 1103 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1104 specifying the initialization vector for CBC mode. 1106 Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 1107 [1]; the one given here is preferred since it specifies padding. 1109 B.2.3 RC2-CBC-Pad 1111 RC2-CBC-Pad is the RC2(tm) encryption algorithm [21] in CBC mode with 1112 the RFC 1423 padding operation. RC2-CBC-Pad has a variable key 1113 length, from one to 128 octets, a separate "effective key bits" 1114 parameter from one to 1024 bits that limits the effective search 1115 space independent of the key length, and an eight-octet 1116 initialization vector. 1118 The object identifier rc2CBC identifies the RC2-CBC-Pad encryption 1119 scheme: 1121 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1123 The parameters field associated with OID in an AlgorithmIdentifier 1124 shall have type RC2-CBC-Parameter: 1126 RC2-CBC-Parameter ::= SEQUENCE { 1127 rc2ParameterVersion INTEGER OPTIONAL, 1128 iv OCTET STRING (SIZE(8)) } 1130 The fields of type RC2-CBCParameter have the following meanings: 1132 - rc2ParameterVersion is a proprietary RSA Security Inc. encoding 1133 of the "effective key bits" for RC2. The following encodings are 1134 defined: 1136 Effective Key Bits Encoding 1137 40 160 1138 64 120 1139 128 58 1140 b >= 256 b 1142 If the rc2ParameterVersion field is omitted, the "effective key bits" 1143 defaults to 32. (This is for backward compatibility with certain very 1144 old implementations.) 1146 - iv is the eight-octet initialization vector. 1148 B.2.4 RC5-CBC-Pad 1150 RC5-CBC-Pad is the RC5(tm) encryption algorithm [20] in CBC mode with 1151 a generalization of the RFC 1423 padding operation. This scheme is 1152 fully specified in [2]. RC5-CBC-Pad has a variable key length, from 0 1153 to 256 octets, and supports both a 64-bit block size and a 128-bit 1154 block size. For the former, it has an eight-octet initialization 1155 vector, and for the latter, a 16-octet initialization vector. RC5- 1156 CBC-Pad also has a variable number of "rounds" in the encryption 1157 operation, from 8 to 127. 1159 Note: The generalization of the padding operation is as follows. For 1160 RC5 with a 64-bit block size, the padding string is as defined in RFC 1161 1423. For RC5 with a 128-bit block size, the padding string consists 1162 of 16-(||M|| mod 16) octets each with value 16-(||M|| mod 16). 1164 The object identifier rc5-CBC-PAD [2] identifies RC5-CBC-Pad 1165 encryption scheme: 1167 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1169 The parameters field associated with this OID in an 1170 AlgorithmIdentifier shall have type RC5-CBC-Parameters: 1172 RC5-CBC-Parameters ::= SEQUENCE { 1173 version INTEGER {v1-0(16)} (v1-0), 1174 rounds INTEGER (8..127), 1175 blockSizeInBits INTEGER (64 | 128), 1176 iv OCTET STRING OPTIONAL } 1178 The fields of type RC5-CBC-Parameters have the following meanings: 1180 - version is the version of the algorithm, which shall be v1-0. 1182 - rounds is the number of rounds in the encryption operation, 1183 which shall be between 8 and 127. 1185 - blockSizeInBits is the block size in bits, which shall be 64 or 1186 128. 1188 - iv is the initialization vector, an eight-octet string for 64-bit 1189 RC5 and a 16-octet string for 128-bit RC5. The default is a 1190 string of the appropriate length consisting of zero octets. 1192 B.3 Message authentication schemes 1194 An example message authentication scheme for PBMAC1 (Section 7.1) is 1195 HMAC-SHA-1. 1197 B.3.1 HMAC-SHA-1 1199 HMAC-SHA-1 is the HMAC message authentication scheme [7] based on the 1200 SHA-1 hash function [18]. HMAC-SHA-1 has a variable key length and a 1201 20-octet (160-bit) message authentication code. 1203 The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies 1204 the HMAC-SHA-1 message authentication scheme. (The object identifier 1205 is the same for both the pseudorandom function and the message 1206 authentication scheme; the distinction is to be understood by 1207 context.) This object identifier is intended to be employed in the 1208 object set PBMAC1-Macs (Appendix A.5). 1210 C. ASN.1 module 1212 For reference purposes, the ASN.1 syntax in the preceding sections is 1213 presented as an ASN.1 module here. 1215 -- PKCS #5 v2.0 ASN.1 Module 1216 -- Revised March 25, 1999 1218 -- This module has been checked for conformance with the 1219 -- ASN.1 standard by the OSS ASN.1 Tools 1221 PKCS5v2-0 {iso(1) member-body(2) us(840) rsadsi(113549) 1222 pkcs(1) pkcs-5(5) modules(16) pkcs5v2-0(1)} 1224 DEFINITIONS ::= BEGIN 1226 -- Basic object identifiers 1228 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 1229 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 1230 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 1232 -- Basic types and classes 1234 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= 1235 SEQUENCE { 1236 algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), 1237 parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} 1238 {@algorithm}) OPTIONAL 1239 } 1241 ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER 1243 -- PBKDF2 1245 PBKDF2Algorithms ALGORITHM-IDENTIFIER ::= 1246 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ...} 1248 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 1250 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 1251 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 1253 PBKDF2-params ::= SEQUENCE { 1254 salt CHOICE { 1255 specified OCTET STRING, 1256 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 1257 }, 1258 iterationCount INTEGER (1..MAX), 1259 keyLength INTEGER (1..MAX) OPTIONAL, 1260 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 1261 algid-hmacWithSHA1 1262 } 1264 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 1266 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= 1267 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... } 1269 -- PBES1 1271 PBES1Algorithms ALGORITHM-IDENTIFIER ::= { 1272 {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} | 1273 {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} | 1274 {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} | 1275 {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} | 1276 {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} | 1277 {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC}, 1278 ... 1279 } 1281 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 1282 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 1283 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 1284 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 1285 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 1286 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 1288 PBEParameter ::= SEQUENCE { 1289 salt OCTET STRING (SIZE(8)), 1290 iterationCount INTEGER 1291 } 1293 -- PBES2 1295 PBES2Algorithms ALGORITHM-IDENTIFIER ::= 1296 { {PBES2-params IDENTIFIED BY id-PBES2}, ...} 1298 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 1300 PBES2-params ::= SEQUENCE { 1301 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 1302 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} 1303 } 1305 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 1306 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1308 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1310 -- PBMAC1 1312 PBMAC1Algorithms ALGORITHM-IDENTIFIER ::= 1313 { {PBMAC1-params IDENTIFIED BY id-PBMAC1}, ...} 1315 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1317 PBMAC1-params ::= SEQUENCE { 1318 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1319 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} 1320 } 1322 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 1323 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1325 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1327 -- Supporting techniques 1329 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1330 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1332 SupportingAlgorithms ALGORITHM-IDENTIFIER ::= { 1333 {NULL IDENTIFIED BY id-hmacWithSHA1} | 1334 {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} | 1335 {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} | 1336 {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} | 1337 {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}, 1338 ... 1339 } 1341 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1343 desCBC OBJECT IDENTIFIER ::= 1344 {iso(1) identified-organization(3) oiw(14) secsig(3) 1345 algorithms(2) 7} -- from OIW 1347 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1349 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1351 RC2-CBC-Parameter ::= SEQUENCE { 1352 rc2ParameterVersion INTEGER OPTIONAL, 1353 iv OCTET STRING (SIZE(8)) 1354 } 1356 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1358 RC5-CBC-Parameters ::= SEQUENCE { 1359 version INTEGER {v1-0(16)} (v1-0), 1360 rounds INTEGER (8..127), 1361 blockSizeInBits INTEGER (64 | 128), 1362 iv OCTET STRING OPTIONAL 1363 } 1365 END 1367 D. Intellectual property considerations 1369 RSA Security makes no patent claims on the general constructions 1370 described in this document, although specific underlying techniques 1371 may be covered. Among the underlying techniques, the RC5 encryption 1372 algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 1373 [22] and 5,835,600 [23]. 1375 RC2 and RC5 are trademarks of RSA Security. 1377 License to copy this document is granted provided that it is 1378 identified as RSA Security Inc. Public-Key Cryptography Standards 1379 (PKCS) in all material mentioning or referencing this document. 1381 RSA Security makes no representations regarding intellectual property 1382 claims by other parties. Such determination is the responsibility of 1383 the user. 1385 E. Revision history 1387 Versions 1.0-1.3 1389 Versions 1.0-1.3 were distributed to participants in RSA Data 1390 Security Inc.'s Public-Key Cryptography Standards meetings in 1391 February and March 1991. 1393 Version 1.4 1395 Version 1.4 was part of the June 3, 1991 initial public release of 1396 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1397 document SEC-SIG-91-20. 1399 Version 1.5 1401 Version 1.5 incorporated several editorial changes, including 1402 updates to the references and the addition of a revision history. 1404 Version 2.0 1406 Version 2.0 incorporates major editorial changes in terms of the 1407 document structure, and introduces the PBES2 encryption scheme, 1408 the PBMAC1 message authentication scheme, and independent 1409 password-based key derivation functions. This version continues to 1410 support the encryption process in version 1.5. 1412 F. References 1414 [1] American National Standard X9.52 - 1998, Triple Data Encryption 1415 Algorithm Modes of Operation. Working draft, Accredited Standards 1416 Committee X9, July 27, 1998. 1418 [2] R. Baldwin and R. Rivest. RFC 2040: The RC5, RC5-CBC, RC5-CBC- 1419 Pad, and RC5-CTS Algorithms. IETF, October 1996. 1421 [3] D. Balenson. RFC 1423: Privacy Enhancement for Internet 1422 Electronic Mail: Part III: Algorithms, Modes, and Identifiers. IETF, 1423 February 1993. 1425 [4] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password- 1426 based protocols secure against dictionary attacks. In Proceedings of 1427 the 1992 IEEE Computer Society Conference on Research in Security and 1428 Privacy, pages 72-84, IEEE Computer Society, 1992. 1430 [5] D. Jablon. Strong password-only authenticated key exchange. ACM 1431 Computer Communications Review, October 1996. 1433 [6] B. Kaliski. RFC 1319: The MD2 Message-Digest Algorithm. IETF, 1434 April 1992. 1436 [7] H. Krawczyk, M. Bellare, and R. Canetti. RFC 2104: HMAC: Keyed- 1437 Hashing for Message Authentication. IETF, February 1997. 1439 [8] Robert Morris and Ken Thompson. Password security: A case 1440 history. Communications of the ACM, 22(11):594-597, November 1979. 1442 [9] ISO/IEC 8824-1:1995: Information technology - Abstract Syntax 1443 Notation One (ASN.1) - Specification of basic notation. 1995. 1445 [10] ISO/IEC 8824-1:1995/Amd.1:1995 Information technology - Abstract 1446 Syntax Notation One (ASN.1) - Specification of basic notation - 1447 Amendment 1 - Rules of extensibility. 1995. 1449 [11] ISO/IEC 8824-2:1995 Information technology - Abstract Syntax 1450 Notation One (ASN.1) - Information object specification. 1995. 1452 [12] ISO/IEC 8824-2:1995/Amd.1:1995 Information technology - Abstract 1453 Syntax Notation One (ASN.1) - Information object specification - 1454 Amendment 1 - Rules of extensibility. 1995. 1456 [13] ISO/IEC 8824-3:1995 Information technology - Abstract Syntax 1457 Notation One (ASN.1) - Constraint specification. 1995. 1459 [14] ISO/IEC 8824-4:1995 Information technology - Abstract Syntax 1460 Notation One (ASN.1) - Parameterization of ASN.1 specifications. 1461 1995. 1463 [15] National Institute of Standards and Technology (NIST). FIPS PUB 1464 46-2: Data Encryption Standard. December 30, 1993. 1466 [16] National Institute of Standards and Technology (NIST). FIPS PUB 1467 81: DES Modes of Operation. December 2, 1980. 1469 [17] National Institute of Standards and Technology (NIST). FIPS PUB 1470 112: Password Usage. May 30, 1985. 1472 [18] National Institute of Standards and Technology (NIST). FIPS PUB 1473 180-1: Secure Hash Standard. April 1994. 1475 [19] R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. IETF, 1476 April 1992. 1478 [20] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the 1479 Second International Workshop on Fast Software Encryption, pages 86- 1480 96, Springer-Verlag, 1994. 1482 [21] R. Rivest. RFC 2268: A Description of the RC2(r) Encryption 1483 Algorithm. IETF, March 1998. 1485 [22] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent 1486 Rotations. U.S. Patent No. 5,724,428, March 3, 1998. 1488 [23] R.L. Rivest. Block Encryption Algorithm with Data-Dependent 1489 Rotations. U.S. Patent No. 5,835,600, November 10, 1998. 1491 [24] RSA Laboratories. PKCS #5: Password-Based Encryption Standard. 1492 Version 1.5, November 1993. 1494 [25] RSA Laboratories. PKCS #8: Private-Key Information Syntax 1495 Standard. Version 1.2, November 1993. 1497 [26] T. Wu. The Secure Remote Password protocol. In Proceedings of 1498 the 1998 Internet Society Network and Distributed System Security 1499 Symposium, pages 97-111, Internet Society, 1998. 1501 [27] F. Yergeau. RFC 2279: UTF-8, a Transformation Format of ISO 1502 10646. IETF, January 1998. 1504 G. Contact Information & About PKCS 1506 The Public-Key Cryptography Standards are specifications produced by 1507 RSA Laboratories in cooperation with secure systems developers 1508 worldwide for the purpose of accelerating the deployment of public- 1509 key cryptography. First published in 1991 as a result of meetings 1510 with a small group of early adopters of public-key technology, the 1511 PKCS documents have become widely referenced and implemented. 1512 Contributions from the PKCS series have become part of many formal 1513 and de facto standards, including ANSI X9 documents, PKIX, SET, 1514 S/MIME, and SSL. 1516 Further development of PKCS occurs through mailing list discussions 1517 and occasional workshops, and suggestions for improvement are 1518 welcome. For more information, contact: 1520 PKCS Editor 1521 RSA Laboratories 1522 20 Crosby Drive 1523 Bedford, MA 01730 USA 1524 pkcs-editor@rsasecurity.com 1525 http://www.rsalabs.com/pkcs/