idnits 2.17.00 (12 Aug 2021) /tmp/idnits29852/draft-kaliski-pkcs5-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 document seems to lack an Authors' Addresses Section. ** 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 820: '... keyLength INTEGER (1..MAX) OPTIONAL,...' RFC 2119 keyword, line 1105: '... rc2ParameterVersion INTEGER OPTIONAL,...' RFC 2119 keyword, line 1149: '... iv OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 1212: '... {@algorithm}) OPTIONAL }...' RFC 2119 keyword, line 1232: '... keyLength INTEGER (1..MAX) OPTIONAL,...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 141 has weird spacing: '... dkLen leng...' == Line 144 has weird spacing: '... Hash und...' == Line 146 has weird spacing: '... hLen len...' == Line 165 has weird spacing: '... psLen leng...' == Line 177 has weird spacing: '... \xor bit...' -- 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 (June 1999) is 8375 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '25' on line 1457 looks like a reference -- Missing reference section? '4' on line 1388 looks like a reference -- Missing reference section? '5' on line 1393 looks like a reference -- Missing reference section? '26' on line 1460 looks like a reference -- Missing reference section? '24' on line 1454 looks like a reference -- Missing reference section? '8' on line 1402 looks like a reference -- Missing reference section? '27' on line 1464 looks like a reference -- Missing reference section? '17' on line 1432 looks like a reference -- Missing reference section? '6' on line 1396 looks like a reference -- Missing reference section? '19' on line 1438 looks like a reference -- Missing reference section? '18' on line 1435 looks like a reference -- Missing reference section? '15' on line 1426 looks like a reference -- Missing reference section? '21' on line 1445 looks like a reference -- Missing reference section? '16' on line 1429 looks like a reference -- Missing reference section? '3' on line 1384 looks like a reference -- Missing reference section? '9' on line 1405 looks like a reference -- Missing reference section? '10' on line 1408 looks like a reference -- Missing reference section? '11' on line 1412 looks like a reference -- Missing reference section? '12' on line 1415 looks like a reference -- Missing reference section? '13' on line 1419 looks like a reference -- Missing reference section? '14' on line 1422 looks like a reference -- Missing reference section? '7' on line 1399 looks like a reference -- Missing reference section? '1' on line 1377 looks like a reference -- Missing reference section? '20' on line 1441 looks like a reference -- Missing reference section? '2' on line 1381 looks like a reference -- Missing reference section? '22' on line 1448 looks like a reference -- Missing reference section? '23' on line 1451 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RSA Laboratories B. Kaliski 2 Internet Draft Security Dynamics 3 Expires December 1999 June 1999 5 Password-Based Cryptography Standard 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 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute 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 Status of this Memo .............................................. 1 53 Abstract ......................................................... 1 54 Table of Contents ................................................ 2 55 1 Introduction ................................................. 3 56 2 Notation ..................................................... 3 57 3 Overview ..................................................... 4 58 4 Salt and Iteration Count ..................................... 6 59 4.1 Salt .................................................... 6 60 4.2 Iteration Count ......................................... 8 61 5 Key Derivation Functions ..................................... 8 62 5.1 PBKDF1 .................................................. 9 63 5.2 PBKDF2 .................................................. 10 64 6 Encryption Schemes ........................................... 11 65 6.1 PBES1 ................................................... 11 66 6.1.1 Encryption Operation ............................. 12 67 6.1.2 Decryption Operation ............................. 13 68 6.2 PBES2 ................................................... 14 69 6.2.1 Encryption Operation ............................. 14 70 6.2.2 Decryption Operation ............................. 14 71 7 Message Authentication Schemes ............................... 15 72 7.1 PBMAC1 .................................................. 15 73 7.1.1 MAC Generation ................................... 15 74 7.1.2 MAC Verification ................................. 16 76 Appendices 78 A ASN.1 Syntax ................................................. 17 79 A.1 PBKDF1 .................................................. 17 80 A.2 PBKDF2 .................................................. 17 81 A.3 PBES1 ................................................... 19 82 A.4 PBES2 ................................................... 19 83 A.5 PBMAC1 .................................................. 20 84 B Supporting Techniques ........................................ 20 85 B.1 Pseudorandom Functions .................................. 21 86 B.1.1 HMAC-SHA-1 ....................................... 21 87 B.2 Encryption Schemes ...................................... 22 88 B.2.1 DES-CBC-Pad ...................................... 22 89 B.2.2 DES-EDE3-CBC-Pad ................................. 22 90 B.2.3 RC2-CBC-Pad ...................................... 23 91 B.2.4 RC5-CBC-Pad ...................................... 24 92 B.3 Message Authentication Schemes .......................... 24 93 B.3.1 HMAC-SHA-1 ....................................... 25 94 C ASN.1 Module ................................................. 25 95 D Intellectual Property Considerations ......................... 28 97 Table of Contents 99 E Revision History ............................................. 28 100 E.1 Versions 1.0-1.3 ........................................ 28 101 E.2 Version 1.4 ............................................. 28 102 E.3 Version 1.5 ............................................. 28 103 E.4 Version 2.0 ............................................. 29 104 F References ................................................... 29 105 G About PKCS ................................................... 31 107 1. Introduction 109 This document provides recommendations for the implementation of 110 password-based cryptography, covering the following aspects: 112 - key derivation functions 113 - encryption schemes 114 - message-authentication schemes 115 - ASN.1 syntax identifying the techniques 117 The recommendations are intended for general application within 118 computer and communications systems, and as such include a fair 119 amount of flexibility. They are particularly intended for the 120 protection of sensitive information such as private keys, as in PKCS 121 #8 [25]. It is expected that application standards and implementation 122 profiles based on these specifications may include additional 123 constraints. 125 Other cryptographic techniques based on passwords, such as 126 password-based key entity authentication and key establishment 127 protocols [4][5][26] are outside the scope of this document. 128 Guidelines for the selection of passwords are also outside the scope. 130 This document supersedes PKCS #5 version 1.5 [24], but includes 131 compatible techniques. 133 2. Notation 135 C ciphertext, an octet string 137 c iteration count, a positive integer 139 DK derived key, an octet string 141 dkLen length in octets of derived key, a positive integer 143 EM encoded message, an octet string 144 Hash underlying hash function 146 hLen length in octets of pseudorandom function output, a positive 147 integer 149 l length in blocks of derived key, a positive integer 151 IV initialization vector, an octet string 153 K encryption key, an octet string 155 KDF key derivation function 157 M message, an octet string 159 P password, an octet string 161 PRF underlying pseudorandom function 163 PS padding string, an octet string 165 psLen length in octets of padding string, a positive integer 167 S salt, an octet string 169 T message authentication code, an octet string 171 T1, ..., Tl, U1, ..., Uc 172 intermediate values, octet strings 174 01, 02, ..., 08 175 octets with value 1, 2, ..., 8 177 \xor bit-wise exclusive-or of two octet strings 179 || || octet length operator 181 || concatenation operator 183 substring extraction operator: extracts octets i through j, 184 0 <= i <= j 186 3. Overview 188 In many applications of public-key cryptography, user security is 189 ultimately dependent on one or more secret text values or passwords. 190 Since a password is not directly applicable as a key to any 191 conventional cryptosystem, however, some processing of the password 192 is required to perform cryptographic operations with it. Moreover, as 193 passwords are often chosen from a relatively small space, special 194 care is required in that processing to defend against search attacks. 196 A general approach to password-based cryptography, as described by 197 Morris and Thompson [8] for the protection of password tables, is to 198 combine a password with a salt to produce a key. The salt can be 199 viewed as an index into a large set of keys derived from the 200 password, and need not be kept secret. Although it may be possible 201 for an opponent to construct a table of possible passwords (a 202 so-called "dictionary attack"), constructing a table of possible keys 203 will be difficult, since there will be many possible keys for each 204 password. An opponent will thus be limited to searching through 205 passwords separately for each salt. 207 Another approach to password-based cryptography is to construct key 208 derivation techniques that are relatively expensive, thereby 209 increasing the cost of exhaustive search. One way to do this is to 210 include an iteration count in the key derivation technique, 211 indicating how many times to iterate some underlying function by 212 which keys are derived. A modest number of iterations, say 1000, is 213 not likely to be a burden for legitimate parties when computing a 214 key, but will be a significant burden for opponents. 216 Salt and iteration count formed the basis for password-based 217 encryption in PKCS #5 v1.5, and adopted here as well for the various 218 cryptographic operations. Thus, password-based key derivation as 219 defined here is a function of a password, a salt, and an iteration 220 count, where the latter two quantities need not be kept secret. 222 From a password-based key derivation function, it is straightforward 223 to define password-based encryption and message authentication 224 schemes. As in PKCS #5 v1.5, the password-based encryption schemes 225 here are based on an underlying, conventional encryption scheme, 226 where the key for the conventional scheme is derived from the 227 password. Similarly, the password-based message authentication 228 scheme is based on an underlying conventional scheme. This two- 229 layered approach makes the password-based techniques modular in terms 230 of the underlying techniques they can be based on. 232 It is expected that the password-based key derivation functions may 233 find other applications than just the encryption and message 234 authentication schemes defined here. For instance, one might derive 235 a set of keys with a single application of a key derivation function, 236 rather than derive each key with a separate application of the 237 function. The keys in the set would be obtained as substrings of the 238 output of the key derivation function. This approach might be 239 employed as part of key establishment in a session-oriented protocol. 240 Another application is password checking, where the output of the key 241 derivation function is stored (along with the salt and iteration 242 count) for the purposes of subsequent verification of a password. 244 Throughout this document, a password is considered to be an octet 245 string of arbitrary length whose interpretation as a text string is 246 unspecified. In the interest of interoperability, however, it is 247 recommended that applications follow some common text encoding rules. 248 ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of 249 UTF-8.) 251 Although the selection of passwords is outside the scope of this 252 document, guidelines have been published [17] that may well be taken 253 into account. 255 4. Salt and iteration count 257 Inasmuch as salt and iteration count are central to the techniques 258 defined in this document, some further discussion is warranted. 260 4.1 Salt 262 A salt in password-based cryptography has traditionally served the 263 purpose of producing a large set of keys corresponding to a given 264 password, among which one is selected at random according to the 265 salt. An individual key in the set is selected by applying a key 266 derivation function KDF, as 268 DK = KDF (P, S) 270 where DK is the derived key, P is the password, and S is the salt. 271 This has two benefits: 273 1. It is difficult for an opponent to precompute all the keys 274 corresponding to a dictionary of passwords, or even the 275 most likely keys. If the salt is 64 bits long, for 276 instance, there will be as many as 2^64 keys for each 277 password. An opponent is thus limited to searching for 278 passwords after a password-based operation has been 279 performed and the salt is known. 281 2. It is unlikely that the same key will be selected twice. 282 Again, if the salt is 64 bits long, the chance of 283 "collision" between keys does not become significant until 284 about 2^32 keys have been produced, according to the 285 Birthday Paradox. This addresses some of the concerns about 286 interactions between multiple uses of the same key, which 287 may apply for some encryption and authentication 288 techniques. 290 In password-based encryption, the party encrypting a message can gain 291 assurance that these benefits are realized simply by selecting a 292 large and sufficiently random salt when deriving an encryption key 293 from a password. A party generating a message authentication code 294 can gain such assurance in a similar fashion. 296 The party decrypting a message or verifying a message authentication 297 code, however, cannot be sure that a salt supplied by another party 298 has actually been generated at random. It is possible, for instance, 299 that the salt may have been copied from another password-based 300 operation, in an attempt to exploit interactions between multiple 301 uses of the same key. For instance, suppose two legitimate parties 302 exchange a encrypted message, where the encryption key is an 80-bit 303 key derived from a shared password with some salt. An opponent could 304 take the salt from that encryption and provide it to one of the 305 parties as though it were for a 40-bit key. If the party reveals the 306 result of decryption with the 40-bit key, the opponent may be able to 307 solve for the 40-bit key. In the case that 40-bit key is the first 308 half of the 80-bit key, the opponent can then readily solve for the 309 remaining 40 bits of the 80-bit key. 311 To defend against such attacks, either the interaction between 312 multiple uses of the same key should be carefully analyzed, or the 313 salt should contain data that explicitly distinguishes between 314 different operations. For instance, the salt might have an 315 additional, non-random octet that specifies whether the derived key 316 is for encryption, for message authentication, or for some other 317 operation. 319 Based on this, the following is recommended for salt selection: 321 1. If there is no concern about interactions between multiple 322 uses of the same key (or a prefix of that key) with the 323 password-based encryption and authentication techniques 324 supported for a given password, then the salt may be 325 generated at random and need not be checked for a 326 particular format by the party receiving the salt. It 327 should be at least eight octets (64 bits) long. 329 2. Otherwise, the salt should contain data that explicitly 330 distinguishes between different operations and different 331 key lengths, in addition to a random part that is at least 332 eight octets long, and this data should be checked or 333 regenerated by the party receiving the salt. For instance, 334 the salt could have an additional non-random octet that 335 specifies the purpose of the derived key. Alternatively, 336 it could be the encoding of a structure that specifies 337 detailed information about the derived key, such as the 338 encryption or authentication technique and a sequence 339 number among the different keys derived from the password. 340 The particular format of the additional data is left to the 341 application. 343 Note. If a random number generator or pseudorandom generator is not 344 available, a deterministic alternative for generating the salt (or 345 the random part of it) is to apply a password-based key derivation 346 function to the password and the message M to be processed. For 347 instance, the salt could be computed with a key derivation function 348 as S = KDF (P, M). This approach is not recommended if the message M 349 is known to belong to a small message space (e.g., "Yes" or "No"), 350 however, since then there will only be a small number of possible 351 salts. 353 4.2 Iteration count 355 An iteration count has traditionally served the purpose of increasing 356 the cost of producing keys from a password, thereby also increasing 357 the difficulty of attack. For the methods in this document, a minimum 358 of 1000 iterations is recommended. This will increase the cost of 359 exhaustive search for passwords significantly, without a noticeable 360 impact in the cost of deriving individual keys. 362 5. Key derivation functions 364 A key derivation function produces a derived key from a base key and 365 other parameters. In a password-based key derivation function, the 366 base key is a password and the other parameters are a salt value and 367 an iteration count, as outlined in Section 3. 369 The primary application of the password-based key derivation 370 functions defined here is in the encryption schemes in Section 6 and 371 the message authentication scheme in Section 7. Other applications 372 are certainly possible, hence the independent definition of these 373 functions. 375 Two functions are specified in this section: PBKDF1 and PBKDF2. 376 PBKDF2 is recommended for new applications; PBKDF1 is included only 377 for compatibility with existing applications, and is not recommended 378 for new applications. 380 A typical application of the key derivation functions defined here 381 might include the following steps: 383 1. Select a salt S and an iteration count c, as outlined in 384 Section 4. 386 2. Select a length in octets for the derived key, dkLen. 388 3. Apply the key derivation function to the password, the 389 salt, the iteration count and the key length to produce a 390 derived key. 392 4. Output the derived key. 394 Any number of keys may be derived from a password by varying the 395 salt, as described in Section 3. 397 5.1 PBKDF1 399 PBKDF1 applies a hash function, which shall be MD2 [6], MD5 [19] or 400 SHA-1 [18], to derive keys. The length of the derived key is bounded 401 by the length of the hash function output, which is 16 octets for MD2 402 and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key 403 derivation process in PKCS #5 v1.5. 405 PBKDF1 is recommended only for compatibility with existing 406 applications since the keys it produces may not be large enough for 407 some applications. 409 PBKDF1 (P, S, c, dkLen) 411 Options: Hash underlying hash function 413 Input: P password, an octet string 414 S salt, an eight-octet string 415 c iteration count, a positive integer 416 dkLen intended length in octets of derived key, a 417 positive integer, at most 16 for MD2 or MD5 418 and 20 for SHA-1 420 Output: DK derived key, a dkLen-octet string 422 Steps: 424 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output 425 "derived key too long" and stop. 427 2. Apply the underlying hash function Hash for c iterations to 428 the concatenation of the password P and the salt S, then 429 extract the first dkLen octets to produce a derived key DK: 431 T1 = Hash (P || S) , 432 T2 = Hash (T1) , 433 ... 434 Tc = Hash (Tc-1) , 435 DK = Tc<0..dkLen-1> 437 3. Output the derived key DK. 439 5.2 PBKDF2 441 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an 442 example) to derive keys. The length of the derived key is essentially 443 unbounded. (However, the maximum effective search space for the 444 derived key may be limited by the structure of the underlying 445 pseudorandom function. See Appendix B.1 for further discussion.) 446 PBKDF2 is recommended for new applications. 448 PBKDF2 (P, S, c, dkLen) 450 Options: PRF underlying pseudorandom function (hLen 451 denotes the length in octets of the 452 pseudorandom function output) 454 Input: P password, an octet string 455 S salt, an octet string 456 c iteration count, a positive integer 457 dkLen intended length in octets of the derived key, 458 a positive integer, at most 459 (2^32 - 1) * hLen 461 Output: DK derived key, a dkLen-octet string 463 Steps: 465 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" 466 and stop. 468 2. Let l be the number of hLen-octet blocks in the derived key, 469 rounding up, and let r be the number of octets in the last 470 block: 472 l = [dkLen / hLen] , 473 r = dkLen - (l - 1) * hLen . 475 3. For each block of the derived key apply the function F defined 476 below to the password P, the salt S, the iteration count c, 477 and the block index to compute the block: 479 T1 = F (P, S, c, 1) , 480 T2 = F (P, S, c, 2) , 481 ... 482 Tl = F (P, S, c, l) , 484 where the function F is defined as the exclusive-or sum of the 485 first c iterates of the underlying pseudorandom function PRF 486 applied to the password P and the concatenation of the salt S 487 and the block index i: 489 F (P, S, c, i) = U1 \xor U2 \xor ... \xor Uc 491 where 493 U1 = PRF (P, S || INT (i)) , 494 U2 = PRF (P, U1) , 495 ... 496 Uc = PRF (P, Uc-1) . 498 Here, INT (i) is a four-octet encoding of the integer i, most 499 significant octet first. 501 4. Concatenate the blocks and extract the first dkLen octets to 502 produce a derived key DK: 504 DK = T1 || T2 || ... || Tl<0..r-1> 506 5. Output the derived key DK. 508 Note. The construction of the function F follows a "belt-and- 509 suspenders" approach. The iterates Ui are computed recursively to 510 remove a degree of parallelism from an opponent; they are 511 exclusive-ored together to reduce concerns about the recursion 512 degenerating into a small set of values. 514 6. Encryption schemes 516 An encryption scheme, in the symmetric setting, consists of an 517 encryption operation and a decryption operation, where the encryption 518 operation produces a ciphertext from a message under a key, and the 519 decryption operation recovers the message from the ciphertext under 520 the same key. In a password-based encryption scheme, the key is a 521 password. 523 A typical application of a password-based encryption scheme is a 524 private-key protection method, where the message contains private-key 525 information, as in PKCS #8. The encryption schemes defined here would 526 be suitable encryption algorithms in that context. 528 Two schemes are specified in this section: PBES1 and PBES2. PBES2 is 529 recommended for new applications; PBES1 is included only for 530 compatibility with existing applications, and is not recommended 531 for new applications. 533 6.1 PBES1 535 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying 536 block cipher, which shall be either DES [15] or RC2TM [21] in CBC 537 mode [16]. PBES1 is compatible with the encryption scheme in PKCS #5 538 v1.5. 540 PBES1 is recommended only for compatibility with existing 541 applications, since it supports only two underlying encryption 542 schemes, each of which has a key size (56 or 64 bits) that may not be 543 large enough for some applications. 545 6.1.1 Encryption operation 547 The encryption operation for PBES1 consists of the following steps, 548 which encrypt a message M under a password P to produce a ciphertext 549 C: 551 1. Select an eight-octet salt S and an iteration count c, as 552 outlined in Section 4. 554 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 555 password P, the salt S, and the iteration count c to produce a 556 derived key DK of length 16 octets: 558 DK = PBKDF1 (P, S, c, 16) . 560 3. Separate the derived key DK into an encryption key K 561 consisting of the first eight octets of DK and an 562 initialization vector IV consisting of the next eight octets: 564 K = DK<0..7> , 565 IV = DK<8..15> . 567 4. Concatenate M and a padding string PS to form an encoded 568 message EM: 570 EM = M || PS , 572 where the padding string PS consists of 8-(||M|| mod 8) 573 octets each with value 8-(||M|| mod 8). The padding string PS 574 will satisfy one of the following statements: 576 PS = 01, if ||M|| mod 8 = 7 ; 577 PS = 02 02, if ||M|| mod 8 = 6 ; 578 ... 579 PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0. 581 The length in octets of the encoded message will be a multiple 582 of eight and it will be possible to recover the message M 583 unambiguously from the encoded message. (This padding rule is 584 taken from RFC 1423 [3].) 586 5. Encrypt the encoded message EM with the underlying block 587 cipher (DES or RC2) in cipher block chaining mode under the 588 encryption key K with initialization vector IV to produce the 589 ciphertext C. For DES, the key K shall be considered as a 590 64-bit encoding of a 56-bit DES key with parity bits ignored 591 (see [9]). For RC2, the "effective key bits" shall be 64 bits. 593 6. Output the ciphertext C. 595 The salt S and the iteration count c may be conveyed to the party 596 performing decryption in an AlgorithmIdentifier value (see Appendix 597 A.3). 599 6.1.2 Decryption operation 601 The decryption operation for PBES1 consists of the following steps, 602 which decrypt a ciphertext C under a password P to recover a message 603 M: 605 1. Obtain the eight-octet salt S and the iteration count c. 606 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 607 password P, the salt S, and the iteration count c to produce a 608 derived key DK of length 16 octets: 610 DK = PBKDF1 (P, S, c, 16) 612 3. Separate the derived key DK into an encryption key K 613 consisting of the first eight octets of DK and an 614 initialization vector IV consisting of the next eight octets: 616 K = DK<0..7> , 617 IV = DK<8..15> . 619 4. Decrypt the ciphertext C with the underlying block cipher (DES 620 or RC2) in cipher block chaining mode under the encryption key 621 K with initialization vector IV to recover an encoded message 622 EM. If the length in octets of the ciphertext C is not a 623 multiple of eight, output "decryption error" and stop. 625 5. Separate the encoded message EM into a message M and a padding 626 string PS: 628 EM = M || PS , 630 where the padding string PS consists of some number psLen 631 octets each with value psLen, where psLen is between 1 and 8. 632 If it is not possible to separate the encoded message EM in 633 this manner, output "decryption error" and stop. 635 6. Output the recovered message M. 637 6.2 PBES2 639 PBES2 combines a password-based key derivation function, which shall 640 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 641 underlying encryption scheme (see Appendix B.2 for examples). The key 642 length and any other parameters for the underlying encryption scheme 643 depend on the scheme. 645 PBES2 is recommended for new applications. 647 6.2.1 Encryption operation 649 The encryption operation for PBES2 consists of the following steps, 650 which encrypt a message M under a password P to produce a ciphertext 651 C, applying a selected key derivation function KDF and a selected 652 underlying encryption scheme: 654 1. Select a salt S and an iteration count c, as outlined in 655 Section 4. 657 2. Select the length in octets, dkLen, for the derived key for 658 the underlying encryption scheme. 660 3. Apply the selected key derivation function to the password P, 661 the salt S, and the iteration count c to produce a derived key 662 DK of length dkLen octets: 664 DK = KDF (P, S, c, dkLen) . 666 4. Encrypt the message M with the underlying encryption scheme 667 under the derived key DK to produce a ciphertext C. (This 668 step may involve selection of parameters such as an 669 initialization vector and padding, depending on the underlying 670 scheme.) 672 5. Output the ciphertext C. 674 The salt S, the iteration count c, the key length dkLen, and 675 identifiers for the key derivation function and the underlying 676 encryption scheme may be conveyed to the party performing decryption 677 in an AlgorithmIdentifier value (see Appendix A.4). 679 6.2.2 Decryption operation 681 The decryption operation for PBES2 consists of the following steps, 682 which decrypt a ciphertext C under a password P to recover a message 683 M: 685 1. Obtain the salt S for the operation. 687 2. Obtain the iteration count c for the key derivation function. 689 3. Obtain the key length in octets, dkLen, for the derived key 690 for the underlying encryption scheme. 692 4. Apply the selected key derivation function to the password P, 693 the salt S, and the iteration count c to produce a derived key 694 DK of length dkLen octets: 696 DK = KDF (P, S, c, dkLen) . 698 5. Decrypt the ciphertext C with the underlying encryption scheme 699 under the derived key DK to recover a message M. If the 700 decryption function outputs "decryption error," then output 701 "decryption error" and stop. 703 6. Output the recovered message M. 705 7. Message authentication schemes 707 A message authentication scheme consists of a MAC (message 708 authentication code) generation operation and a MAC verification 709 operation, where the MAC generation operation produces a message 710 authentication code from a message under a key, and the MAC 711 verification operation verifies the message authentication code 712 under the same key. In a password-based message authentication 713 scheme, the key is a password. 715 One scheme is specified in this section: PBMAC1. 717 7.1 PBMAC1 719 PBMAC1 combines a password-based key derivation function, which 720 shall be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 721 underlying message authentication scheme (see Appendix B.3 for an 722 example). The key length and any other parameters for the underlying 723 message authentication scheme depend on the scheme. 725 7.1.1 MAC generation 727 The MAC generation operation for PBMAC1 consists of the following 728 steps, which process a message M under a password P to generate a 729 message authentication code T, applying a selected key derivation 730 function KDF and a selected underlying message authentication scheme: 732 1. Select a salt S and an iteration count c, as outlined in 733 Section 4. 735 2. Select a key length in octets, dkLen, for the derived key for 736 the underlying message authentication function. 738 3. Apply the selected key derivation function to the password P, 739 the salt S, and the iteration count c to produce a derived key 740 DK of length dkLen octets: 742 DK = KDF (P, S, c, dkLen) . 744 4. Process the message M with the underlying message 745 authentication scheme under the derived key DK to generate a 746 message authentication code T. 748 5. Output the message authentication code T. 750 The salt S, the iteration count c, the key length dkLen, and 751 identifiers for the key derivation function and underlying message 752 authentication scheme may be conveyed to the party performing 753 verification in an AlgorithmIdentifier value (see Appendix A.5). 755 7.1.2 MAC verification 757 The MAC verification operation for PBMAC1 consists of the following 758 steps, which process a message M under a password P to verify a 759 message authentication code T: 761 1. Obtain the salt S and the iteration count c. 763 2. Obtain the key length in octets, dkLen, for the derived key 764 for the underlying message authentication scheme. 766 3. Apply the selected key derivation function to the password P, 767 the salt S, and the iteration count c to produce a derived key 768 DK of length dkLen octets: 770 DK = KDF (P, S, c, dkLen) . 772 4. Process the message M with the underlying message 773 authentication scheme under the derived key DK to verify the 774 message authentication code T. 776 5. If the message authentication code verifies, output "correct"; 777 else output "incorrect." 779 APPENDICES 781 A. ASN.1 syntax 783 This section defines ASN.1 syntax for the key derivation functions, 784 the encryption schemes, the message authentication scheme, and 785 supporting techniques. The intended application of these definitions 786 includes PKCS #8 and other syntax for key management, encrypted data, 787 and integrity-protected data. (Various aspects of ASN.1 are specified 788 in several ISO/IEC standards [9][10][11][12][13][14].) 790 The object identifier pkcs-5 identifies the arc of the OID tree from 791 which the PKCS #5-specific OIDs in this section are derived: 793 rsadsi OBJECT IDENTIFIER ::= 794 {iso(1) member-body(2) us(840) 113549} 795 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 796 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 798 A.1 PBKDF1 800 No object identifier is given for PBKDF1, as the object identifiers 801 for PBES1 are sufficient for existing applications and PBKDF2 is 802 recommended for new applications. 804 A.2 PBKDF2 806 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation 807 function (Section 5.2). 809 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 811 The parameters field associated with this OID in an 812 AlgorithmIdentifier shall have type PBKDF2-params: 814 PBKDF2-params ::= SEQUENCE { 815 salt CHOICE { 816 specified OCTET STRING, 817 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 818 }, 819 iterationCount INTEGER (1..MAX), 820 keyLength INTEGER (1..MAX) OPTIONAL, 821 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 822 algid-hmacWithSHA1 } 824 The fields of type PKDF2-params have the following meanings: 826 - salt specifies the salt value, or the source of the salt value. 827 It shall either be an octet string or an algorithm ID with an OID 828 in the set PBKDF2-SaltSources, which is reserved for future 829 versions of PKCS #5. 831 The salt-source approach is intended to indicate how the salt 832 value is to be generated as a function of parameters in the 833 algorithm ID, application data, or both. For instance, it may 834 indicate that the salt value is produced from the encoding of 835 a structure that specifies detailed information about the derived 836 key as suggested in Section 4.1. Some of the information may be 837 carried elsewhere, e.g., in the encryption algorithm ID. However, 838 such facilities are deferred to a future version of PKCS #5. 840 In this version, an application may achieve the benefits 841 mentioned in Section 4.1 by choosing a particular interpretation 842 of the salt value in the specified alternative. 844 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 846 - iterationCount specifies the iteration count. The maximum 847 iteration count allowed depends on the implementation. It is 848 expected that implementation profiles may further constrain the 849 bounds. 851 - keyLength, an optional field, is the length in octets of the 852 derived key. The maximum key length allowed depends on the 853 implementation; it is expected that implementation profiles may 854 further constrain the bounds. The field is provided for 855 convenience only; the key length is not cryptographically 856 protected. If there is concern about interaction between 857 operations with different key lengths for a given salt (see 858 Section 4.1), the salt should distinguishes among the different 859 key lengths. 861 - prf identifies the underlying pseudorandom function. It shall be 862 an algorithm ID with an OID in the set PBKDF2-PRFs, which for 863 this version of PKCS #5 shall consist of id-hmacWithSHA1 (see 864 Appendix B.1.1) and any other OIDs defined by the application. 866 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= 867 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... } 869 The default pseudorandom function is HMAC-SHA-1: 871 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 872 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 874 A.3 PBES1 876 Different object identifiers identify the PBES1 encryption scheme 877 (Section 6.1) according to the underlying hash function in the key 878 derivation function and the underlying block cipher, as summarized 879 in the following table: 881 Hash Function Block Cipher OID 882 MD2 DES pkcs-5.1 883 MD2 RC2 pkcs-5.4 884 MD5 DES pkcs-5.3 885 MD5 RC2 pkcs-5.6 886 SHA-1 DES pkcs-5.10 887 SHA-1 RC2 pkcs-5.11 889 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 890 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 891 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 892 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 893 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 894 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 896 For each OID, the parameters field associated with the OID in an 897 AlgorithmIdentifier shall have type PBEParameter: 899 PBEParameter ::= SEQUENCE { 900 salt OCTET STRING (SIZE(8)), 901 iterationCount INTEGER } 903 The fields of type PBEParameter have the following meanings: 905 - salt specifies the salt value, an eight-octet string. 907 - iterationCount specifies the iteration count. 909 A.4 PBES2 911 The object identifier id-PBES2 identifies the PBES2 encryption 912 scheme (Section 6.2). 914 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 916 The parameters field associated with this OID in an 917 AlgorithmIdentifier shall have type PBES2-params: 919 PBES2-params ::= SEQUENCE { 920 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 921 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } 922 The fields of type PBES2-params have the following meanings: 924 - keyDerivationFunc identifies the underlying key derivation 925 function. It shall be an algorithm ID with an OID in the set 926 PBES2-KDFs, which for this version of PKCS #5 shall consist of 927 id-PBKDF2 (Appendix A.2). 929 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 930 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 932 - encryptionScheme identifies the underlying encryption scheme. It 933 shall be an algorithm ID with an OID in the set PBES2-Encs, whose 934 definition is left to the application. Example underlying 935 encryption schemes are given in Appendix B.2. 937 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 939 A.5 PBMAC1 941 The object identifier id-PBMAC1 identifies the PBMAC1 message 942 authentication scheme (Section 7.1). 944 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 946 The parameters field associated with this OID in an 947 AlgorithmIdentifier shall have type PBMAC1-params: 949 PBMAC1-params ::= SEQUENCE { 950 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 951 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } 953 The keyDerivationFunc field has the same meaning as the corresponding 954 field of PBES2-params (Appendix A.4) except that the set of OIDs is 955 PBMAC1-KDFs. 957 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 958 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 960 The messageAuthScheme field identifies the underlying message 961 authentication scheme. It shall be an algorithm ID with an OID in the 962 set PBMAC1-MACs, whose definition is left to the application. Example 963 underlying encryption schemes are given in Appendix B.3. 965 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 967 B. Supporting techniques 969 This section gives several examples of underlying functions and 970 schemes supporting the password-based schemes in Sections 5, 6 and 7. 972 While these supporting techniques are appropriate for applications to 973 implement, none of them is required to be implemented. It is 974 expected, however, that profiles for PKCS #5 will be developed that 975 specify particular supporting techniques. 977 This section also gives object identifiers for the supporting 978 techniques. The object identifiers digestAlgorithm and 979 encryptionAlgorithm identify the arcs from which certain algorithm 980 OIDs referenced in this section are derived: 982 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 983 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 985 B.1 Pseudorandom functions 987 An example pseudorandom function for PBKDF2 (Section 5.2) is 988 HMAC-SHA-1. 990 B.1.1 HMAC-SHA-1 992 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC 993 message authentication code [7] based on the SHA-1 hash function 994 [18]. The pseudorandom function is the same function by which the 995 message authentication code is computed, with a full-length output. 996 (The first argument to the pseudorandom function PRF serves as HMACÆs 997 "key," and the second serves as HMACÆs "text." In the case of PBKDF2, 998 the "key" is thus the password and the "text" is the salt.) 999 HMAC-SHA-1 has a variable key length and a 20-octet (160-bit) output 1000 value. 1002 Although the length of the key to HMAC-SHA-1 is essentially 1003 unbounded, the effective search space for pseudorandom function 1004 outputs may be limited by the structure of the function. In 1005 particular, when the key is longer than 512 bits, HMAC-SHA-1 will 1006 first hash it to 160 bits. Thus, even if a long derived key 1007 consisting of several pseudorandom function outputs is produced from 1008 a key, the effective search space for the derived key will be at most 1009 160 bits. Although the specific limitation for other key sizes 1010 depends on details of the HMAC construction, one should assume, to be 1011 conservative, that the effective search space is limited to 160 bits 1012 for other key sizes as well. 1014 (The 160-bit limitation should not generally pose a practical 1015 limitation in the case of password-based cryptography, since the 1016 search space for a password is unlikely to be greater than 160 bits.) 1018 The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1 1019 pseudorandom function: 1021 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1023 The parameters field associated with this OID in an 1024 AlgorithmIdentifier shall have type NULL. This object identifier is 1025 employed in the object set PBKDF2-PRFs (Appendix A.2). 1027 Note. Although HMAC-SHA-1 was designed as a message authentication 1028 code, its proof of security is readily modified to accommodate 1029 requirements for a pseudorandom function, under stronger assumptions. 1031 A hash function may also meet the requirements of a pseudorandom 1032 function under certain assumptions. For instance, the direct 1033 application of a hash function to to the concatenation of the "key" 1034 and the "text" may be appropriate, provided that "text" has 1035 appropriate structure to prevent certain attacks. HMAC-SHA-1 is 1036 preferable, however, because it treats "key" and "text" as separate 1037 arguments and does not require "text" to have any structure. 1039 B.2 Encryption schemes 1041 Example pseudorandom functions for PBES2 (Section 6.2) are 1042 DES-CBC-Pad, DES-EDE2-CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad. 1044 The object identifiers given in this section are intended to be 1045 employed in the object set PBES2-Encs (Appendix A.4). 1047 B.2.1 DES-CBC-Pad 1049 DES-CBC-Pad is single-key DES [15] in CBC mode [16] with the RFC 1423 1050 padding operation (see Section 6.1.1). DES-CBC-Pad has an 1051 eight-octet encryption key and an eight-octet initialization vector. 1052 The key is considered as a 64-bit encoding of a 56-bit DES key with 1053 parity bits ignored. 1055 The object identifier desCBC (defined in the NIST/OSI ImplementorsÆ 1056 Workshop agreements) identifies the DES-CBC-Pad encryption scheme: 1058 desCBC OBJECT IDENTIFIER ::= 1059 {iso(1) identified-organization(3) oiw(14) secsig(3) 1060 algorithms(2) 7} 1062 The parameters field associated with this OID in an 1063 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1064 specifying the initialization vector for CBC mode. 1066 B.2.2 DES-EDE3-CBC-Pad 1068 DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [1] with the 1069 RFC 1423 padding operation. DES-EDE3-CBC-Pad has a 24-octet 1070 encryption key and an eight-octet initialization vector. The key is 1071 considered as the concatenation of three eight-octet keys, each of 1072 which is a 64-bit encoding of a 56-bit DES key with parity bits 1073 ignored. 1075 The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad 1076 encryption scheme: 1078 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1080 The parameters field associated with this OID in an 1081 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1082 specifying the initialization vector for CBC mode. 1084 Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 1085 [1]; the one given here is preferred since it specifies padding. 1087 B.2.3 RC2-CBC-Pad 1089 RC2-CBC-Pad is the RC2TM encryption algorithm [21] in CBC mode with 1090 the RFC 1423 padding operation. RC2-CBC-Pad has a variable key 1091 length, from one to 128 octets, a separate "effective key bits" 1092 parameter from one to 1024 bits that limits the effective search 1093 space independent of the key length, and an eight-octet 1094 initialization vector. 1096 The object identifier rc2CBC identifies the RC2-CBC-Pad encryption 1097 scheme: 1099 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1101 The parameters field associated with OID in an AlgorithmIdentifier 1102 shall have type RC2-CBC-Parameter: 1104 RC2-CBC-Parameter ::= SEQUENCE { 1105 rc2ParameterVersion INTEGER OPTIONAL, 1106 iv OCTET STRING (SIZE(8)) } 1108 The fields of type RC2-CBCParameter have the following meanings: 1110 - rc2ParameterVersion is a proprietary RSA Data Security, Inc. 1111 encoding of the "effective key bits" for RC2. The following 1112 encodings are defined: 1114 Effective Key Bits Encoding 1115 40 160 1116 64 120 1117 128 58 1118 b >= 256 b 1120 If the rc2ParameterVersion field is omitted, the "effective key bits" 1121 defaults to 32. (This is for backward compatibility with certain very 1122 old implementations.) 1124 - iv is the eight-octet initialization vector. 1126 B.2.4 RC5-CBC-Pad 1128 RC5-CBC-Pad is the RC5TM encryption algorithm [20] in CBC mode with a 1129 generalization of the RFC 1423 padding operation . This scheme is 1130 fully specified in [2]. RC5-CBC-Pad has a variable key length, from 0 1131 to 256 octets, and supports both a 64-bit block size and a 128-bit 1132 block size. For the former, it has an eight-octet initialization 1133 vector, and for the latter, a 16-octet initialization vector. 1134 RC5-CBC-Pad also has a variable number of "rounds" in the encryption 1135 operation, from 8 to 127. 1137 The object identifier rc5-CBC-PAD [2] identifies RC5-CBC-Pad 1138 encryption scheme: 1140 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1142 The parameters field associated with this OID in an 1143 AlgorithmIdentifier shall have type RC5-CBC-Parameters: 1145 RC5-CBC-Parameters ::= SEQUENCE { 1146 version INTEGER {v1-0(16)} (v1-0), 1147 rounds INTEGER (8..127), 1148 blockSizeInBits INTEGER (64 | 128), 1149 iv OCTET STRING OPTIONAL } 1151 The fields of type RC5-CBC-Parameters have the following meanings: 1153 - version is the version of the algorithm, which shall be v1-0. 1155 - rounds is the number of rounds in the encryption operation, 1156 which shall be between 8 and 127. 1158 - blockSizeInBits is the block size in bits, which shall be 64 or 1159 128. 1161 - iv is the initialization vector, an eight-octet string for 64-bit 1162 RC5 and a 16-octet string for 128-bit RC5. The default is a 1163 string of the appropriate length consisting of zero octets. 1165 B.3 Message authentication schemes 1167 An example message authentication scheme for PBMAC1 (Section 7.1) is 1168 HMAC-SHA-1. 1170 B.3.1 HMAC-SHA-1 1172 HMAC-SHA-1 is the HMAC message authentication scheme [7] based on the 1173 SHA-1 hash function [18]. HMAC-SHA-1 has a variable key length and a 1174 20-octet (160-bit) message authentication code. 1176 The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies 1177 the HMAC-SHA-1 message authentication scheme. (The object identifier 1178 is the same for both the pseudorandom function and the message 1179 authentication scheme; the distinction is to be understood by 1180 context.) This object identifier is intended to be employed in the 1181 object set PBMAC1-Macs (Appendix A.5). 1183 C. ASN.1 module 1185 For reference purposes, the ASN.1 syntax in the preceding sections 1186 is presented as an ASN.1 module here. 1188 -- PKCS #5 v2.0 ASN.1 Module 1189 -- Revised March 25, 1999 1191 -- This module has been checked for conformance with the 1192 -- ASN.1 standard by the OSS ASN.1 Tools 1194 PKCS5v2-0 {iso(1) member-body(2) us(840) rsadsi(113549) 1195 pkcs(1) pkcs-5(5) modules(16) pkcs5v2-0(1)} 1197 DEFINITIONS ::= BEGIN 1199 -- Basic object identifiers 1201 rsadsi OBJECT IDENTIFIER ::= 1202 {iso(1) member-body(2) us(840) 113549} 1203 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 1204 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 1206 -- Basic types and classes 1208 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= 1209 SEQUENCE { 1210 algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), 1211 parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} 1212 {@algorithm}) OPTIONAL } 1214 ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER 1216 -- PBKDF2 1218 PBKDF2Algorithms ALGORITHM-IDENTIFIER ::= 1219 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ...} 1221 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 1223 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 1224 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 1226 PBKDF2-params ::= SEQUENCE { 1227 salt CHOICE { 1228 specified OCTET STRING, 1229 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 1230 }, 1231 iterationCount INTEGER (1..MAX), 1232 keyLength INTEGER (1..MAX) OPTIONAL, 1233 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 1234 algid-hmacWithSHA1 } 1236 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 1238 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= 1239 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... } 1241 -- PBES1 1243 PBES1Algorithms ALGORITHM-IDENTIFIER ::= 1244 { {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} | 1245 {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} | 1246 {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} | 1247 {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} | 1248 {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} | 1249 {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC}, ...} 1251 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 1252 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 1253 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 1254 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 1255 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 1256 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 1258 PBEParameter ::= SEQUENCE { 1259 salt OCTET STRING (SIZE(8)), 1260 iterationCount INTEGER } 1262 -- PBES2 1264 PBES2Algorithms ALGORITHM-IDENTIFIER ::= 1265 { {PBES2-params IDENTIFIED BY id-PBES2}, ...} 1267 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 1268 PBES2-params ::= SEQUENCE { 1269 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 1270 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } 1272 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 1273 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1275 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1277 -- PBMAC1 1279 PBMAC1Algorithms ALGORITHM-IDENTIFIER ::= 1280 { {PBMAC1-params IDENTIFIED BY id-PBMAC1}, ...} 1282 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1284 PBMAC1-params ::= SEQUENCE { 1285 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1286 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } 1288 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 1289 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1291 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1293 -- Supporting techniques 1295 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1296 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1298 SupportingAlgorithms ALGORITHM-IDENTIFIER ::= 1299 { {NULL IDENTIFIED BY id-hmacWithSHA1} | 1300 {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} | 1301 {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} | 1302 {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} | 1303 {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}, ... } 1305 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1307 desCBC OBJECT IDENTIFIER ::= 1308 {iso(1) identified-organization(3) oiw(14) secsig(3) 1309 algorithms(2) 7} -- from OIW 1311 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1313 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1315 RC2-CBC-Parameter ::= SEQUENCE { 1316 rc2ParameterVersion INTEGER OPTIONAL, 1317 iv OCTET STRING (SIZE(8)) } 1319 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1321 RC5-CBC-Parameters ::= SEQUENCE { 1322 version INTEGER {v1-0(16)} (v1-0), 1323 rounds INTEGER (8..127), 1324 blockSizeInBits INTEGER (64 | 128), 1325 iv OCTET STRING OPTIONAL } 1327 END 1329 D. Intellectual property considerations 1331 RSA Data Security makes no patent claims on the general constructions 1332 described in this document, although specific underlying techniques 1333 may be covered. Among the underlying techniques, the RC5 encryption 1334 algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 1335 [22] and 5,835,600 [23]. 1337 RC2 and RC5 are trademarks of RSA Data Security. 1339 License to copy this document is granted provided that it is 1340 identified as ôRSA Data Security, Inc. Public-Key Cryptography 1341 Standards (PKCS)ö in all material mentioning or referencing this 1342 document. 1344 RSA Data Security makes no representations regarding intellectual 1345 property claims by other parties. Such determination is the 1346 responsibility of the user. 1348 E. Revision history 1350 Versions 1.0-1.3 1352 Versions 1.0-1.3 were distributed to participants in RSA Data 1353 Security, Inc.Æs Public-Key Cryptography Standards meetings in 1354 February and March 1991. 1356 Version 1.4 1358 Version 1.4 was part of the June 3, 1991 initial public release of 1359 PKCS. Version 1.4 was published as NIST/OSI ImplementorsÆ Workshop 1360 document SEC-SIG-91-20. 1362 Version 1.5 1364 Version 1.5 incorporated several editorial changes, including updates 1365 to the references and the addition of a revision history. 1367 Version 2.0 1369 Version 2.0 incorporates major editorial changes in terms of the 1370 document structure, and introduces the PBES2 encryption scheme, the 1371 PBMAC1 message authentication scheme, and independent password-based 1372 key derivation functions. This version continues to support the 1373 encryption process in version 1.5. 1375 F. References 1377 [1] American National Standard X9.52 - 1998, Triple Data Encryption 1378 Algorithm Modes of Operation. Working draft, Accredited Standards 1379 Committee X9, July 27, 1998. 1381 [2] R. Baldwin and R. Rivest. RFC 2040: The RC5, RC5-CBC, RC5-CBC-Pad, 1382 and RC5-CTS Algorithms. IETF, October 1996. 1384 [3] D. Balenson. RFC 1423: Privacy Enhancement for Internet Electronic 1385 Mail: Part III: Algorithms, Modes, and Identifiers. IETF, February 1386 1993. 1388 [4] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password-based 1389 protocols secure against dictionary attacks. In Proceedings of the 1390 1992 IEEE Computer Society Conference on Research in Security and 1391 Privacy, pages 72-84, IEEE Computer Society, 1992. 1393 [5] D. Jablon. Strong password-only authenticated key exchange. ACM 1394 Computer Communications Review, October 1996. 1396 [6] B. Kaliski. RFC 1319: The MD2 Message-Digest Algorithm. IETF, April 1397 1992. 1399 [7] H. Krawczyk, M. Bellare, and R. Canetti. RFC 2104: HMAC: 1400 Keyed-Hashing for Message Authentication. IETF, February 1997. 1402 [8] Robert Morris and Ken Thompson. Password security: A case history. 1403 Communications of the ACM, 22(11):594-597, November 1979. 1405 [9] ISO/IEC 8824-1:1995: Information technology - Abstract Syntax 1406 Notation One (ASN.1) - Specification of basic notation. 1995. 1408 [10] ISO/IEC 8824-1:1995/Amd.1:1995 Information technology - Abstract 1409 Syntax Notation One (ASN.1) - Specification of basic notation - 1410 Amendment 1 - Rules of extensibility. 1995. 1412 [11] ISO/IEC 8824-2:1995 Information technology - Abstract Syntax 1413 Notation One (ASN.1) - Information object specification. 1995. 1415 [12] ISO/IEC 8824-2:1995/Amd.1:1995 Information technology - Abstract 1416 Syntax Notation One (ASN.1) - Information object specification - 1417 Amendment 1 - Rules of extensibility. 1995. 1419 [13] ISO/IEC 8824-3:1995 Information technology - Abstract Syntax 1420 Notation One (ASN.1) - Constraint specification. 1995. 1422 [14] ISO/IEC 8824-4:1995 Information technology - Abstract Syntax 1423 Notation One (ASN.1) - Parameterization of ASN.1 specifications. 1424 1995. 1426 [15] National Institute of Standards and Technology (NIST). FIPS PUB 1427 46-2: Data Encryption Standard. December 30, 1993. 1429 [16] National Institute of Standards and Technology (NIST). FIPS PUB 1430 81: DES Modes of Operation. December 2, 1980. 1432 [17] National Institute of Standards and Technology (NIST). FIPS PUB 1433 112: Password Usage. May 30, 1985. 1435 [18] National Institute of Standards and Technology (NIST). FIPS PUB 1436 180-1: Secure Hash Standard. April 1994. 1438 [19] R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. IETF, April 1439 1992. 1441 [20] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the 1442 Second International Workshop on Fast Software Encryption, pages 1443 86-96, Springer-Verlag, 1994. 1445 [21] R. Rivest. RFC 2268: A Description of the RC2(r) Encryption 1446 Algorithm. IETF, March 1998. 1448 [22] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent 1449 Rotations. U.S. Patent No. 5,724,428, March 3, 1998. 1451 [23] R.L. Rivest. Block Encryption Algorithm with Data-Dependent 1452 Rotations. U.S. Patent No. 5,835,600, November 10, 1998. 1454 [24] RSA Laboratories. PKCS #5: Password-Based Encryption Standard. 1455 Version 1.5, November 1993. 1457 [25] RSA Laboratories. PKCS #8: Private-Key Information Syntax Standard. 1458 Version 1.2, November 1993. 1460 [26] T. Wu. The Secure Remote Password protocol. In Proceedings of the 1461 1998 Internet Society Network and Distributed System Security 1462 Symposium, pages 97-111, Internet Society, 1998. 1464 [27] F. Yergeau. RFC 2279: UTF-8, a Transformation Format of ISO 10646. 1465 IETF, January 1998. 1467 G. About PKCS 1469 The Public-Key Cryptography Standards are specifications produced by 1470 RSA Laboratories in cooperation with secure systems developers 1471 worldwide for the purpose of accelerating the deployment of 1472 public-key cryptography. First published in 1991 as a result of 1473 meetings with a small group of early adopters of public-key 1474 technology, the PKCS documents have become widely referenced and 1475 implemented. Contributions from the PKCS series have become part of 1476 many formal and de facto standards, including ANSI X9 documents, 1477 PKIX, SET, S/MIME, and SSL. 1479 Further development of PKCS occurs through mailing list discussions 1480 and occasional workshops, and suggestions for improvement are 1481 welcome. For more information, contact: 1483 PKCS Editor 1484 RSA Laboratories 1485 20 Crosby Drive 1486 Bedford, MA 01730 USA 1487 pkcs-editor@rsa.com 1488 http://www.rsa.com/rsalabs/pubs/PKCS 1490 Expires December 1999