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