idnits 2.17.00 (12 Aug 2021) /tmp/idnits33206/draft-moriarty-pkcs5-v2dot1-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1828 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 870: '... keyLength INTEGER (1..MAX) OPTIONAL,...' RFC 2119 keyword, line 1201: '... rc2ParameterVersion INTEGER OPTIONAL,...' RFC 2119 keyword, line 1251: '... iv OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 1366: '... {@algorithm}) OPTIONAL...' RFC 2119 keyword, line 1391: '... keyLength INTEGER (1..MAX) OPTIONAL,...' (2 more instances...) -- The draft header indicates that this document obsoletes RFC2898, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 157 has weird spacing: '... dkLen leng...' == Line 161 has weird spacing: '... Hash und...' == Line 163 has weird spacing: '... hLen len...' == Line 182 has weird spacing: '... psLen leng...' == Line 371 has weird spacing: '...eration count...' == (8 more instances...) -- The document date (April 8, 2016) is 2233 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? 'PKCS8' on line 1679 looks like a reference -- Missing reference section? 'RFC5958' on line 1742 looks like a reference -- Missing reference section? 'BELLOV' on line 1605 looks like a reference -- Missing reference section? 'JABLON' on line 1635 looks like a reference -- Missing reference section? 'WU' on line 1770 looks like a reference -- Missing reference section? 'RFC2898' on line 1732 looks like a reference -- Missing reference section? 'MORRIS' on line 1639 looks like a reference -- Missing reference section? 'RFC2279' on line 1727 looks like a reference -- Missing reference section? 'NISTSP63' on line 1665 looks like a reference -- Missing reference section? 'NISTSP132' on line 1670 looks like a reference -- Missing reference section? 'RFC1319' on line 1696 looks like a reference -- Missing reference section? 'RFC1321' on line 1701 looks like a reference -- Missing reference section? 'NIST180' on line 1652 looks like a reference -- Missing reference section? 'NIST46' on line 1644 looks like a reference -- Missing reference section? 'RFC2268' on line 1722 looks like a reference -- Missing reference section? 'NIST81' on line 1648 looks like a reference -- Missing reference section? 'RFC1423' on line 1706 looks like a reference -- Missing reference section? 'RFC6149' on line 1746 looks like a reference -- Missing reference section? 'RFC6151' on line 1751 looks like a reference -- Missing reference section? 'RFC6194' on line 1757 looks like a reference -- Missing reference section? 'ISO8824-1' on line 1618 looks like a reference -- Missing reference section? 'ISO8824-2' on line 1622 looks like a reference -- Missing reference section? 'ISO8824-3' on line 1626 looks like a reference -- Missing reference section? 'ISO8824-4' on line 1630 looks like a reference -- Missing reference section? 'RFC2104' on line 1717 looks like a reference -- Missing reference section? 'WANG' on line 1763 looks like a reference -- Missing reference section? 'COCHRAN' on line 1612 looks like a reference -- Missing reference section? 'NIST198' on line 1660 looks like a reference -- Missing reference section? 'ANSIX952' on line 1600 looks like a reference -- Missing reference section? 'RC5' on line 1691 looks like a reference -- Missing reference section? 'RFC5652' on line 1737 looks like a reference -- Missing reference section? 'RFC2040' on line 1712 looks like a reference -- Missing reference section? 'NIST197' on line 1656 looks like a reference -- Missing reference section? 'RBLOCK1' on line 1683 looks like a reference -- Missing reference section? 'RBLOCK2' on line 1687 looks like a reference Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 38 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT K. Moriarty, Ed. 2 Intended Status: Informational EMC 3 Obsoletes: 2898 (once approved) B. Kaliski 4 Expires: October 9, 2016 Verisign 5 A. Rusch 6 RSA 7 April 8, 2016 9 PKCS #5: Password-Based Cryptography Specification 10 Version 2.1 11 draft-moriarty-pkcs5-v2dot1-01 13 Abstract 15 This document provides recommendations for the implementation of 16 password-based cryptography, covering key derivation functions, 17 encryption schemes, message-authentication schemes, and ASN.1 syntax 18 identifying the techniques. 20 The recommendations are intended for general application within 21 computer and communications systems, and as such include a fair 22 amount of flexibility. They are particularly intended for the 23 protection of sensitive information such as private keys, as in PKCS 24 #8. It is expected that application standards and implementation 25 profiles based on these specifications may include additional 26 constraints. 28 Other cryptographic techniques based on passwords, such as password- 29 based-key entity authentication and key establishment protocols are 30 outside the scope of this document. Guidelines for the selection of 31 passwords are also outside the scope. 33 This document represents a republication of PKCS #5 v2.1 from RSA 34 Laboratories' Public-Key Cryptography Standards (PKCS) series. By 35 publishing this RFC, change control is transferred to the IETF. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/1id-abstracts.html 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 Copyright and License Notice 60 Copyright (c) 2015 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Salt and Iteration Count . . . . . . . . . . . . . . . . . . . 6 79 4.1. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.2. Iteration Count . . . . . . . . . . . . . . . . . . . . . . 8 81 5. Key Derivation Functions . . . . . . . . . . . . . . . . . . . 8 82 5.1. PBKDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 5.2. PBKDFs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 6. Encryption Schemes . . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. PBES1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 6.1.1. PBES Encryption Operation . . . . . . . . . . . . . . . 12 87 6.1.2. PBES1 Decryption Operation . . . . . . . . . . . . . . 13 88 6.2. PBES2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 6.2.1. PBES2 Encryption Operation . . . . . . . . . . . . . . 14 90 6.2.2. PBES2 Decryption Operation . . . . . . . . . . . . . . 15 91 7. Message Authentication Schemes . . . . . . . . . . . . . . . . 16 92 7.1. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.1.1 PBMAC1 Generation Operation . . . . . . . . . . . . . . 16 94 7.1.2. PBMAC1 Verification Operation . . . . . . . . . . . . . 17 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 97 A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 A.1. PBKDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 A.2. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 A.3. PBES1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 A.4. PBES2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 A.5. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 B. Supporting Techniques . . . . . . . . . . . . . . . . . . . . . 22 104 B.1. Pseudorandom functions . . . . . . . . . . . . . . . . . . 22 105 B.1.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . . 22 106 B.1.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . . 23 107 B.2. Encryption Schemes . . . . . . . . . . . . . . . . . . . . 24 108 B.2.1. DES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 24 109 B.2.2. DES-EDE3-CBC-Pad . . . . . . . . . . . . . . . . . . . 25 110 B.2.3. RC2-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 25 111 B.2.4. RC5-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 26 112 B.2.5. AES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 27 113 B.3. Message Authentication Schemes . . . . . . . . . . . . . . 27 114 B.3.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . . 27 115 B.3.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . . 28 116 C. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 28 117 D. Intellectual Property Considerations . . . . . . . . . . . . . 32 118 E. Revision History . . . . . . . . . . . . . . . . . . . . . . . 32 119 F. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 120 F.1 Normative References . . . . . . . . . . . . . . . . . . . 34 121 G. About PKCS . . . . . . . . . . . . . . . . . . . . . . . . . . 36 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 124 1. Introduction 126 This document provides recommendations for the implementation of 127 password-based cryptography, covering the following aspects: 129 - key derivation functions 130 - encryption schemes 131 - message-authentication schemes 132 - ASN.1 syntax identifying the techniques 134 The recommendations are intended for general application within 135 computer and communications systems, and as such include a fair 136 amount of flexibility. They are particularly intended for the 137 protection of sensitive information such as private keys as in PKCS 138 #8 [PKCS8][RFC5958]. It is expected that application standards and 139 implementation profiles based on these specifications may include 140 additional constraints. 142 Other cryptographic techniques based on passwords, such as password- 143 based key entity authentication and key establishment protocols 144 [BELLOV][JABLON][WU] are outside the scope of this document. 145 Guidelines for the selection of passwords are also outside the scope. 146 This document supersedes PKCS #5 version 2.0 [RFC2898], but includes 147 compatibletechniques. 149 2. Notation 151 C ciphertext, an octet string 153 c iteration count, a positive integer 155 DK derived key, an octet string 157 dkLen length in octets of derived key, a positive integer 159 EM encoded message, an octet string 161 Hash underlying hash function 163 hLen length in octets of pseudorandom function output, a positive 164 integer 166 l length in blocks of derived key, a positive integer 168 IV initialization vector, an octet string 170 K encryption key, an octet string 172 KDF key derivation function 174 M message, an octet string 176 P password, an octet string 178 PRF underlying pseudorandom function 180 PS padding string, an octet string 182 psLen length in octets of padding string, a positive integer 184 S salt, an octet string 186 T message authentication code, an octet string 188 T_1, ..., T_l, U_1, ..., U_c 189 intermediate values, octet strings 191 01, 02, ..., 08 192 octets with value 1, 2, ..., 8 194 bit-wise exclusive-or of two octet strings 196 || || octet length operator 198 || concatenation operator 200 substring extraction operator: extracts octets i through j, 201 0 <= i <= j 203 3. Overview 205 In many applications of public-key cryptography, user security is 206 ultimately dependent on one or more secret text values or passwords. 207 Since a password is not directly applicable as a key to any 208 conventional cryptosystem, however, some processing of the password 209 is required to perform cryptographic operations with it. Moreover, as 210 passwords are often chosen from a relatively small space, special 211 care is required in that processing to defend against search attacks. 213 A general approach to password-based cryptography, as described by 214 Morris and Thompson [MORRIS] for the protection of password tables, 215 is to combine a password with a salt to produce a key. The salt can 216 be viewed as an index into a large set of keys derived from the 217 password, and need not be kept secret. Although it may be possible 218 for an opponent to construct a table of possible passwords (a so- 219 called "dictionary attack"), constructing a table of possible keys 220 will be difficult, since there will be many possible keys for each 221 password. An opponent will thus be limited to searching through 222 passwords separately for each salt. 224 Another approach to password-based cryptography is to construct key 225 derivation techniques that are relatively expensive, thereby 226 increasing the cost of exhaustive search. One way to do this is to 227 include an iteration count in the key derivation technique, 228 indicating how many times to iterate some underlying function by 229 which keys are derived. A modest number of iterations, say 1000, is 230 not likely to be a burden for legitimate parties when computing a 231 key, but will be a significant burden for opponents. 233 Salt and iteration count formed the basis for password-based 234 encryption in PKCS #5 v2.0, and adopted here as well for the various 235 cryptographic operations. Thus, password-based key derivation as 236 defined here is a function of a password, a salt, and an iteration 237 count, where the latter two quantities need not be kept secret. 239 From a password-based key derivation function, it is straightforward 240 to define password-based encryption and message authentication 241 schemes. As in PKCS #5 v2.0, the password-based encryption schemes 242 here are based on an underlying, conventional encryption scheme, 243 where the key for the conventional scheme is derived from the 244 password. Similarly, the password-based message authentication scheme 245 is based on an underlying conventional scheme. This two-layered 246 approach makes the password-based techniques modular in terms of the 247 underlying techniques they can be based on. 249 It is expected that the password-based key derivation functions may 250 find other applications than just the encryption and message 251 authentication schemes defined here. For instance, one might derive a 252 set of keys with a single application of a key derivation function, 253 rather than derive each key with a separate application of the 254 function. The keys in the set would be obtained as substrings of the 255 output of the key derivation function. This approach might be 256 employed as part of key establishment in a session-oriented protocol. 257 Another application is password checking, where the output of the key 258 derivation function is stored (along with the salt and iteration 259 count) for the purposes of subsequent verification of a password. 261 Throughout this document, a password is considered to be an octet 262 string of arbitrary length whose interpretation as a text string is 263 unspecified. In the interest of interoperability, however, it is 264 recommended that applications follow some common text encoding rules. 265 ASCII and UTF-8 [RFC2279] are two possibilities. (ASCII is a subset 266 of UTF-8.) 268 Although the selection of passwords is outside the scope of this 269 document, guidelines have been published [NISTSP63] that may well be 270 taken into account. 272 4. Salt and Iteration Count 274 Inasmuch as salt and iteration count are central to the techniques 275 defined in this document, some further discussion is warranted. 277 4.1. Salt 279 A salt in password-based cryptography has traditionally served the 280 purpose of producing a large set of keys corresponding to a given 281 password, among which one is selected at random according to the 282 salt. An individual key in the set is selected by applying a key 283 derivation function KDF, as 285 DK = KDF (P, S) 287 where DK is the derived key, P is the password, and S is the salt. 288 This has two benefits: 290 1. It is difficult for an opponent to precompute all the keys 291 corresponding to a dictionary of passwords, or even the most 292 likely keys. If the salt is 64 bits long, for instance, there 293 will be as many as 2^64 keys for each password. An opponent is 294 thus limited to searching for passwords after a password-based 295 operation has been performed and the salt is known. 297 2. It is unlikely that the same key will be selected twice. Again, 298 if the salt is 64 bits long, the chance of "collision" between 299 keys does not become significant until about 2^32 keys have 300 been produced, according to the Birthday Paradox. This 301 addresses some of the concerns about interactions between 302 multiple uses of the same key, which may apply for some 303 encryption and authentication techniques. 305 In password-based encryption, the party encrypting a message can gain 306 assurance that these benefits are realized simply by selecting a 307 large and sufficiently random salt when deriving an encryption key 308 from a password. A party generating a message authentication code can 309 gain such assurance in a similar fashion. 311 The party decrypting a message or verifying a message authentication 312 code, however, cannot be sure that a salt supplied by another party 313 has actually been generated at random. It is possible, for instance, 314 that the salt may have been copied from another password-based 315 operation, in an attempt to exploit interactions between multiple 316 uses of the same key. For instance, suppose two legitimate parties 317 exchange a encrypted message, where the encryption key is an 80-bit 318 key derived from a shared password with some salt. An opponent could 319 take the salt from that encryption and provide it to one of the 320 parties as though it were for a 40-bit key. If the party reveals the 321 result of decryption with the 40-bit key, the opponent may be able to 322 solve for the 40-bit key. In the case that 40-bit key is the first 323 half of the 80-bit key, the opponent can then readily solve for the 324 remaining 40 bits of the 80-bit key. 326 To defend against such attacks, either the interaction between 327 multiple uses of the same key should be carefully analyzed, or the 328 salt should contain data that explicitly distinguishes between 329 different operations. For instance, the salt might have an 330 additional, non-random octet that specifies whether the derived key 331 is for encryption, for message authentication, or for some other 332 operation. 334 Based on this, the following is recommended for salt selection: 336 1. If there is no concern about interactions between multiple uses 337 of the same key (or a prefix of that key) with the password- 338 based encryption and authentication techniques supported for a 339 given password, then the salt may be generated at random and 340 need not be checked for a particular format by the party 341 receiving the salt. It should be at least eight octets (64 342 bits) long. 344 2. Otherwise, the salt should contain data that explicitly 345 distinguishes between different operations and different key 346 lengths, in addition to a random part that is at least eight 347 octets long, and this data should be checked or regenerated by 348 the party receiving the salt. For instance, the salt could have 349 an additional non-random octet that specifies the purpose of 350 the derived key. Alternatively, it could be the encoding of a 351 structure that specifies detailed information about the derived 352 key, such as the encryption or authentication technique and a 353 sequence number among the different keys derived from the 354 password. The particular format of the additional data is left 355 to the application. 357 Note. If a random number generator or pseudorandom generator is not 358 available, a deterministic alternative for generating the salt (or 359 the random part of it) is to apply a password-based key derivation 360 function to the password and the message M to be processed. For 361 instance, the salt could be computed with a key derivation function 362 as S = KDF (P, M). This approach is not recommended if the message M 363 is known to belong to a small message space (e.g., "Yes" or "No"), 364 however, since then there will only be a small number of possible 365 salts. 367 4.2. Iteration Count 369 An iteration count has traditionally served the purpose of increasing 370 the cost of producing keys from a password, thereby also increasing 371 the difficulty of attack. Mathematically, an iteration count of c 372 will increase the security strength of a password by log2(c) 373 bits against trial based attacks like brute force or dictionary 374 attacks. 376 Choosing a reasonable value for the iteration count depends on 377 environment and circumstances, and varies from application to 378 application. This document follows the recommendations made in FIPS 379 Special Publication 800-132 [NISTSP132], which says "The iteration 380 count shall be selected as large as possible, as long as the time 381 required to generate the key using the entered password is acceptable 382 for the users. [...] A minimum iteration count of 1,000 is 383 recommended. For especially critical keys, or for very powerful 384 systems or systems where user-perceived performance is not critical, 385 an iteration count of 10,000,000 may be appropriate". 387 5. Key Derivation Functions 389 A key derivation function produces a derived key from a base key and 390 other parameters. In a password-based key derivation function, the 391 base key is a password and the other parameters are a salt value and 392 an iteration count, as outlined in Section 3. 394 The primary application of the password-based key derivation 395 functions defined here is in the encryption schemes in Section 6 and 396 the message authentication scheme in Section 7. Other applications 397 are certainly possible, hence the independent definition of these 398 functions. 400 Two functions are specified in this section: PBKDF1 and PBKDF2. 401 PBKDF2 is recommended for new applications; PBKDF1 is included only 402 for compatibility with existing applications, and is not recommended 403 for new applications. 405 A typical application of the key derivation functions defined here 406 might include the following steps: 408 1. Select a salt S and an iteration count c, as outlined in 409 Section 4. 411 2. Select a length in octets for the derived key, dkLen. 413 3. Apply the key derivation function to the password, the salt, 414 the iteration count and the key length to produce a derived 415 key. 417 4. Output the derived key. 419 Any number of keys may be derived from a password by varying the 420 salt, as described in Section 3. 422 5.1. PBKDF1 424 PBKDF1 applies a hash function, which shall be MD2 [RFC1319], MD5 425 [RFC1321] or SHA-1 [NIST180], to derive keys. The length of the 426 derived key is bounded by the length of the hash function output, 427 which is 16 octets for MD2 and MD5 and 20 octets for SHA-1. PBKDF1 is 428 compatible with the key derivation process in PKCS #5 v1.5 429 [PKCS5_15]. 431 PBKDF1 is recommended only for compatibility with existing 432 applications since the keys it produces may not be large enough for 433 some applications. 435 PBKDF1 (P, S, c, dkLen) 437 Options: Hash underlying hash function 439 Input: P password, an octet string 440 S salt, an eight-octet string 441 c iteration count, a positive integer 442 dkLen intended length in octets of derived key, 443 a positive integer, at most 16 for MD2 or 444 MD5 and 20 for SHA-1 445 Output: DK derived key, a dkLen-octet string 447 Steps: 449 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output 450 "derived key too long" and stop. 452 2. Apply the underlying hash function Hash for c iterations to the 453 concatenation of the password P and the salt S, then extract 454 the first dkLen octets to produce a derived key DK: 456 T_1 = Hash (P || S) , 457 T_2 = Hash (T_1) , 458 ... 459 T_c = Hash (T_{c-1}) , 460 DK = Tc<0..dkLen-1> 462 3. Output the derived key DK. 464 5.2. PBKDFs 466 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an 467 example) to derive keys. The length of the derived key is essentially 468 unbounded. (However, the maximum effective search space for the 469 derived key may be limited by the structure of the underlying 470 pseudorandom function. See Appendix B.1 for further discussion.) 471 PBKDF2 is recommended for new applications. 473 PBKDF2 (P, S, c, dkLen) 475 Options: PRF underlying pseudorandom function (hLen 476 denotes the length in octets of the 477 pseudorandom function output) 479 Input: P password, an octet string 480 S salt, an octet string 481 c iteration count, a positive integer 482 dkLen intended length in octets of the derived 483 key, a positive integer, at most 484 (2^32 - 1) * hLen 486 Output: DK derived key, a dkLen-octet string 488 Steps: 490 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" and 491 stop. 493 2. Let l be the number of hLen-octet blocks in the derived key, 494 rounding up, and let r be the number of octets in the last 495 block: 497 l = CEIL (dkLen / hLen) , 498 r = dkLen - (l - 1) * hLen . 500 Here, CEIL (x) is the "ceiling" function, i.e. the smallest 501 integer greater than, or equal to, x. 503 3. For each block of the derived key apply the function F defined 504 below to the password P, the salt S, the iteration count c, and 505 the block index to compute the block: 507 T_1 = F (P, S, c, 1) , 508 T_2 = F (P, S, c, 2) , 509 ... 510 T_l = F (P, S, c, l) , 512 where the function F is defined as the exclusive-or sum of the 513 first c iterates of the underlying pseudorandom function PRF 514 applied to the password P and the concatenation of the salt S 515 and the block index i: 517 where 518 U_1 = PRF (P, S || INT (i)) , 519 U_2 = PRF (P, U_1) , 520 ... 521 U_c = PRF (P, U_{c-1}) . 523 Here, INT (i) is a four-octet encoding of the integer i, most 524 significant octet first. 526 4. Concatenate the blocks and extract the first dkLen octets to 527 produce a derived key DK: 529 DK = T_1 || T_2 || ... || T_l<0..r-1> 531 5. Output the derived key DK. 533 Note. The construction of the function F follows a "belt-and- 534 suspenders" approach. The iterates U_i are computed recursively to 535 remove a degree of parallelism from an opponent; they are exclusive- 536 ored together to reduce concerns about the recursion degenerating 537 into a small set of values. 539 6. Encryption Schemes 541 An encryption scheme, in the symmetric setting, consists of an 542 encryption operation and a decryption operation, where the encryption 543 operation produces a ciphertext from a message under a key, and the 544 decryption operation recovers the message from the ciphertext under 545 the same key. In a password-based encryption scheme, the key is a 546 password. 548 A typical application of a password-based encryption scheme is a 549 private-key protection method, where the message contains private-key 550 information, as in PKCS #8. The encryption schemes defined here would 551 be suitable encryption algorithms in that context. 553 Two schemes are specified in this section: PBES1 and PBES2. PBES2 is 554 recommended for new applications; PBES1 is included only for 555 compatibility with existing applications, and is not recommended for 556 new applications. 558 6.1. PBES1 560 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying 561 block cipher, which shall be either DES [NIST46] or RC2(tm) [RFC2268] 562 in CBC mode [NIST81]. PBES1 is compatible with the encryption scheme 563 in PKCS #5 v1.5 [PKCS5_15]. 565 PBES1 is recommended only for compatibility with existing 566 applications, since it supports only two underlying encryption 567 schemes, each of which has a key size (56 or 64 bits) that may not be 568 large enough for some applications. 570 6.1.1. PBES Encryption Operation 572 The encryption operation for PBES1 consists of the following steps, 573 which encrypt a message M under a password P to produce a ciphertext 574 C: 576 1. Select an eight-octet salt S and an iteration count c, as 577 outlined in Section 4. 579 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 580 password P, the salt S, and the iteration count c to produce at 581 derived key DK of length 16 octets: 583 DK = PBKDF1 (P, S, c, 16) . 585 3. Separate the derived key DK into an encryption key K consisting 586 of the first eight octets of DK and an initialization vector IV 587 consisting of the next eight octets: 589 K = DK<0..7> , 590 IV = DK<8..15> . 592 4. Concatenate M and a padding string PS to form an encoded 593 message EM: 595 EM = M || PS , 597 where the padding string PS consists of 8-(||M|| mod 8) octets 598 each with value 8-(||M|| mod 8). The padding string PS will 599 satisfy one of the following statements: 601 PS = 01, if ||M|| mod 8 = 7 ; 602 PS = 02 02, if ||M|| mod 8 = 6 ; 603 ... 604 PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0. 606 The length in octets of the encoded message will be a multiple 607 of eight and it will be possible to recover the message M 608 unambiguously from the encoded message. (This padding rule is 609 taken from RFC 1423 [RFC1423].) 611 5. Encrypt the encoded message EM with the underlying block cipher 612 (DES or RC2) in cipher block chaining mode under the encryption 613 key K with initialization vector IV to produce the ciphertext 614 C. For DES, the key K shall be considered as a 64-bit encoding 615 of a 56-bit DES key with parity bits ignored (see [NIST46]). 616 For RC2, the "effective key bits" shall be 64 bits. 618 6. Output the ciphertext C. 620 The salt S and the iteration count c may be conveyed to the party 621 performing decryption in an AlgorithmIdentifier value (see Appendix 622 A.3). 624 6.1.2. PBES1 Decryption Operation 626 The decryption operation for PBES1 consists of the following steps, 627 which decrypt a ciphertext C under a password P to recover a message 628 M: 630 1. Obtain the eight-octet salt S and the iteration count c. 632 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 633 password P, the salt S, and the iteration count c to produce a 634 derived key DK of length 16 octets: 636 DK = PBKDF1 (P, S, c, 16) 638 3. Separate the derived key DK into an encryption key K consisting 639 of the first eight octets of DK and an initialization vector IV 640 consisting of the next eight octets: 642 K = DK<0..7> , 643 IV = DK<8..15> . 645 4. Decrypt the ciphertext C with the underlying block cipher (DES 646 or RC2) in cipher block chaining mode under the encryption key 647 K with initialization vector IV to recover an encoded message 648 EM. If the length in octets of the ciphertext C is not a 649 multiple of eight, output "decryption error" and stop. 651 5. Separate the encoded message EM into a message M and a padding 652 string PS: 654 EM = M || PS , 656 where the padding string PS consists of some number psLen 657 octets each with value psLen, where psLen is between 1 and 8. 658 If it is not possible to separate the encoded message EM in 659 this manner, output "decryption error" and stop. 661 6. Output the recovered message M. 663 6.2. PBES2 665 PBES2 combines a password-based key derivation function, which shall 666 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 667 underlying encryption scheme (see Appendix B.2 for examples). The key 668 length and any other parameters for the underlying encryption scheme 669 depend on the scheme. 671 PBES2 is recommended for new applications. 673 6.2.1. PBES2 Encryption Operation 675 The encryption operation for PBES2 consists of the following steps, 676 which encrypt a message M under a password P to produce a ciphertext 677 C, applying a selected key derivation function KDF and a selected 678 underlying encryption scheme: 680 1. Select a salt S and an iteration count c, as outlined in 681 Section 4. 683 2. Select the length in octets, dkLen, for the derived key for the 684 underlying encryption scheme. 686 3. Apply the selected key derivation function to the password P, 687 the salt S, and the iteration count c to produce a derived key 688 DK of length dkLen octets: 690 DK = KDF (P, S, c, dkLen) . 692 4. Encrypt the message M with the underlying encryption scheme 693 under the derived key DK to produce a ciphertext C. (This step 694 may involve selection of parameters such as an initialization 695 vector and padding, depending on the underlying scheme.) 697 5. Output the ciphertext C. 699 The salt S, the iteration count c, the key length dkLen, and 700 identifiers for the key derivation function and the underlying 701 encryption scheme may be conveyed to the party performing decryption 702 in an AlgorithmIdentifier value (see Appendix A.4). 704 6.2.2. PBES2 Decryption Operation 706 The decryption operation for PBES2 consists of the following steps, 707 which decrypt a ciphertext C under a password P to recover a message 708 M: 710 1. Obtain the salt S for the operation. 712 2. Obtain the iteration count c for the key derivation function. 714 3. Obtain the key length in octets, dkLen, for the derived key for 715 the underlying encryption scheme. 717 4. Apply the selected key derivation function to the password P, 718 the salt S, and the iteration count c to produce a derived key 719 DK of length dkLen octets: 721 DK = KDF (P, S, c, dkLen) . 723 5. Decrypt the ciphertext C with the underlying encryption scheme 724 under the derived key DK to recover a message M. If the 725 decryption function outputs "decryption error," then output 726 "decryption error" and stop. 728 6. Output the recovered message M. 730 7. Message Authentication Schemes 732 A message authentication scheme consists of a MAC (message 733 authentication code) generation operation and a MAC verification 734 operation, where the MAC generation operation produces a message 735 authentication code from a message under a key, and the MAC 736 verification operation verifies the message authentication code under 737 the same key. In a password-based message authentication scheme, the 738 key is a password. 740 One scheme is specified in this section: PBMAC1. 742 7.1. PBMAC1 744 PBMAC1 combines a password-based key derivation function, which shall 745 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 746 underlying message authentication scheme (see Appendix B.3 for an 747 example). The key length and any other parameters for the underlying 748 message authentication scheme depend on the scheme. 750 7.1.1 PBMAC1 Generation Operation 752 The MAC generation operation for PBMAC1 consists of the following 753 steps, which process a message M under a password P to generate a 754 message authentication code T, applying a selected key derivation 755 function KDF and a selected underlying message authentication scheme: 757 1. Select a salt S and an iteration count c, as outlined in 758 Section 4. 760 2. Select a key length in octets, dkLen, for the derived key for 761 the underlying message authentication function. 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 key 765 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 generate a 771 message authentication code T. 773 5. Output the message authentication code T. 775 The salt S, the iteration count c, the key length dkLen, and 776 identifiers for the key derivation function and underlying message 777 authentication scheme may be conveyed to the party performing 778 verification in an AlgorithmIdentifier value (see Appendix A.5). 780 7.1.2. PBMAC1 Verification Operation 782 The MAC verification operation for PBMAC1 consists of the following 783 steps, which process a message M under a password P to verify a 784 message authentication code T: 786 1. Obtain the salt S and the iteration count c. 788 2. Obtain the key length in octets, dkLen, for the derived key for 789 the underlying message authentication scheme. 791 3. Apply the selected key derivation function to the password P, 792 the salt S, and the iteration count c to produce a derived key 793 DK of length dkLen octets: 795 DK = KDF (P, S, c, dkLen) . 797 4. Process the message M with the underlying message 798 authentication scheme under the derived key DK to verify the 799 message authentication code T. 801 5. If the message authentication code verifies, output "correct"; 802 else output "incorrect." 804 8. Security Considerations 806 Password-based cryptography is generally limited in the security that 807 it can provide, particularly for methods such as those defined in 808 this document where off-line password search is possible. While the 809 use of salt and iteration count can increase the complexity of attack 810 (see Section 4 for recommendations), it is essential that passwords 811 are selected well, and relevant guidelines (e.g., [NISTSP63]) should 812 be taken into account. It is also important that passwords be 813 protected well if stored. 815 In general, different keys should be derived from a password for 816 different uses to minimize the possibility of unintended 817 interactions. For password-based encryption with a single algorithm, 818 a random salt is sufficient to ensure that different keys will be 819 produced. In certain other situations, as outlined in Section 4, a 820 structured salt is necessary. The recommendations in Section 4 should 821 thus be taken into account when selecting the salt value. 823 For information on security considerations for MD2 [RFC1319] see 824 [RFC6149], for MD5 [RFC1321] see [RFC6151], for SHA-1 [NIST180] see 825 [RFC6194]. 827 9. IANA Considerations 829 None. 831 A. ASN.1 Syntax 833 This section defines ASN.1 syntax for the key derivation functions, 834 the encryption schemes, the message authentication scheme, and 835 supporting techniques. The intended application of these definitions 836 includes PKCS #8 and other syntax for key management, encrypted data, 837 and integrity-protected data. (Various aspects of ASN.1 are specified 838 in several ISO/IEC standards [ISO8824-1][ISO8824-2][ISO8824-3] 839 [ISO8824-4].) 841 The object identifier pkcs-5 identifies the arc of the OID tree from 842 which the PKCS #5-specific OIDs in this section are derived: 844 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 845 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 846 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 848 A.1. PBKDF1 850 No object identifier is given for PBKDF1, as the object identifiers 851 for PBES1 are sufficient for existing applications and PBKDF2 is 852 recommended for new applications. 854 A.2. PBKDF2 856 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation 857 function (Section 5.2). 859 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 861 The parameters field associated with this OID in an 862 AlgorithmIdentifier shall have type PBKDF2-params: 864 PBKDF2-params ::= SEQUENCE { 865 salt CHOICE { 866 specified OCTET STRING, 867 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 868 }, 869 iterationCount INTEGER (1..MAX), 870 keyLength INTEGER (1..MAX) OPTIONAL, 871 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 872 algid-hmacWithSHA1 } 874 The fields of type PBKDF2-params have the following meanings: 876 - salt specifies the salt value, or the source of the salt value. 877 It shall either be an octet string or an algorithm ID with an 878 OID in the set PBKDF2-SaltSources, which is reserved for future 879 versions of PKCS #5. 881 The salt-source approach is intended to indicate how the salt 882 value is to be generated as a function of parameters in the 883 algorithm ID, application data, or both. For instance, it may 884 indicate that the salt value is produced from the encoding of a 885 structure that specifies detailed information about the derived 886 key as suggested in Section 4.1. Some of the information may be 887 carried elsewhere, e.g., in the encryption algorithm ID. 888 However, such facilities are deferred to a future version of 889 PKCS #5. 891 In this version, an application may achieve the benefits 892 mentioned in Section 4.1 by choosing a particular 893 interpretation of the salt value in the specified alternative. 895 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 897 - iterationCount specifies the iteration count. The maximum 898 iteration count allowed depends on the implementation. It is 899 expected that implementation profiles may further constrain the 900 bounds. 902 - keyLength, an optional field, is the length in octets of the 903 derived key. The maximum key length allowed depends on the 904 implementation; it is expected that implementation profiles may 905 further constrain the bounds. The field is provided for 906 convenience only; the key length is not cryptographically 907 protected. If there is concern about interaction between 908 operations with different key lengths for a given salt (see 909 Section 4.1), the salt should distinguish among the different 910 key lengths. 912 - prf identifies the underlying pseudorandom function. It shall 913 be an algorithm ID with an OID in the set PBKDF2-PRFs, which 914 for this version of PKCS #5 shall consist of id-hmacWithSHA1 915 (see Appendix B.1.1) and any other OIDs defined by the 916 application. 918 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { 919 {NULL IDENTIFIED BY id-hmacWithSHA1}, 920 {NULL IDENTIFIED BY id-hmacWithSHA224}, 921 {NULL IDENTIFIED BY id-hmacWithSHA256}, 922 {NULL IDENTIFIED BY id-hmacWithSHA384}, 923 {NULL IDENTIFIED BY id-hmacWithSHA512}, 924 {NULL IDENTIFIED BY id-hmacWithSHA512-224}, 925 {NULL IDENTIFIED BY id-hmacWithSHA512-256}, 926 ... 927 } 929 The default pseudorandom function is HMAC-SHA-1: 931 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 932 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 934 A.3. PBES1 936 Different object identifiers identify the PBES1 encryption scheme 937 (Section 6.1) according to the underlying hash function in the key 938 derivation function and the underlying block cipher, as summarized in 939 the following table: 941 Hash Function Block Cipher OID 942 MD2 DES pkcs-5.1 943 MD2 RC2 pkcs-5.4 944 MD5 DES pkcs-5.3 945 MD5 RC2 pkcs-5.6 946 SHA-1 DES pkcs-5.10 947 SHA-1 RC2 pkcs-5.11 949 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 950 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 951 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 952 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 953 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 954 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 956 For each OID, the parameters field associated with the OID in an 957 AlgorithmIdentifier shall have type PBEParameter: 959 PBEParameter ::= SEQUENCE { 960 salt OCTET STRING (SIZE(8)), 961 iterationCount INTEGER } 963 The fields of type PBEParameter have the following meanings: 965 - salt specifies the salt value, an eight-octet string. 967 - iterationCount specifies the iteration count. 969 A.4. PBES2 971 The object identifier id-PBES2 identifies the PBES2 encryption scheme 972 (Section 6.2). 974 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 976 The parameters field associated with this OID in an 977 AlgorithmIdentifier shall have type PBES2-params: 979 PBES2-params ::= SEQUENCE { 980 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 981 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } 983 The fields of type PBES2-params have the following meanings: 985 - keyDerivationFunc identifies the underlying key derivation 986 function. It shall be an algorithm ID with an OID in the set 987 PBES2-KDFs, which for this version of PKCS #5 shall consist of 988 id-PBKDF2 (Appendix A.2). 990 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 991 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 993 - encryptionScheme identifies the underlying encryption scheme. 994 It shall be an algorithm ID with an OID in the set PBES2-Encs, 995 whose definition is left to the application. Example underlying 996 encryption schemes are given in Appendix B.2. 998 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1000 A.5. PBMAC1 1002 The object identifier id-PBMAC1 identifies the PBMAC1 message 1003 authentication scheme (Section 7.1). 1005 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1007 The parameters field associated with this OID in an 1008 AlgorithmIdentifier shall have type PBMAC1-params: 1010 PBMAC1-params ::= SEQUENCE { 1011 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1012 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } 1014 The keyDerivationFunc field has the same meaning as the corresponding 1015 field of PBES2-params (Appendix A.4) except that the set of OIDs is 1016 PBMAC1-KDFs. 1018 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 1019 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1021 The messageAuthScheme field identifies the underlying message 1022 authentication scheme. It shall be an algorithm ID with an OID in the 1023 set PBMAC1-MACs, whose definition is left to the application. Example 1024 underlying encryption schemes are given in Appendix B.3. 1026 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1028 B. Supporting Techniques 1030 This section gives several examples of underlying functions and 1031 schemes supporting the password-based schemes in Sections 5, 6 and 7. 1033 While these supporting techniques are appropriate for applications to 1034 implement, none of them is required to be implemented. It is 1035 expected, however, that profiles for PKCS #5 will be developed that 1036 specify particular supporting techniques. 1038 This section also gives object identifiers for the supporting 1039 techniques. The object identifiers digestAlgorithm and 1040 encryptionAlgorithm identify the arcs from which certain algorithm 1041 OIDs referenced in this section are derived: 1043 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1044 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1046 B.1. Pseudorandom functions 1048 Examples of pseudorandom function for PBKDF2 (Section 5.2) include 1049 HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and 1050 SHA512/256. Applications may employ other schemes as well. 1052 B.1.1. HMAC-SHA-1 1054 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC 1055 message authentication code [RFC2104] based on the SHA-1 hash 1056 function [NIST180]. The pseudorandom function is the same function 1057 by which the message authentication code is computed, with a full- 1058 length output. (The first argument to the pseudorandom function PRF 1059 serves as HMAC's "key," and the second serves as HMAC's "text." In 1060 the case of PBKDF2, the "key" is thus the password and the "text" is 1061 the salt.) HMAC-SHA-1 has a variable key length and a 20-octet 1062 (160-bit) output value. 1064 Although the length of the key to HMAC-SHA-1 is essentially 1065 unbounded, the effective search space for pseudorandom function 1066 outputs may be limited by the structure of the function. In 1067 particular, when the key is longer than 512 bits, HMAC-SHA-1 will 1068 first hash it to 160 bits. Thus, even if a long derived key 1069 consisting of several pseudorandom function outputs is produced from 1070 a key, the effective search space for the derived key will be at most 1071 160 bits. Although the specific limitation for other key sizes 1072 depends on details of the HMAC construction, one should assume, to be 1073 conservative, that the effective search space is limited to 160 bits 1074 for other key sizes as well. 1076 (The 160-bit limitation should not generally pose a practical 1077 limitation in the case of password-based cryptography, since the 1078 search space for a password is unlikely to be greater than 160 bits.) 1080 The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1 1081 pseudorandom function: 1083 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1085 The parameters field associated with this OID in an 1086 AlgorithmIdentifier shall have type NULL. This object identifier is 1087 employed in the object set PBKDF2-PRFs (Appendix A.2). 1089 Note. Although HMAC-SHA-1 was designed as a message authentication 1090 code, its proof of security is readily modified to accommodate 1091 requirements for a pseudorandom function, under stronger assumptions. 1092 A hash function may also meet the requirements of a pseudorandom 1093 function under certain assumptions. For instance, the direct 1094 application of a hash function to to the concatenation of the "key" 1095 and the "text" may be appropriate, provided that "text" has 1096 appropriate structure to prevent certain attacks. HMAC-SHA-1 is 1097 preferable, however, because it treats "key" and "text" as separate 1098 arguments and does not require "text" to have any structure. 1100 During 2004 and 2005 there were a number of attacks on SHA-1 that 1101 reduced its perceived effective strength against collision attacks to 1102 62 bits instead of the expected 80 bits (e.g. Wang et al. [WANG], 1103 confirmed by M. Cochran [COCHRAN]). However, since these attacks 1104 centered on finding collisions between values they are not a direct 1105 security consideration here because the collision-resistant property 1106 is not required by the HMAC authentication scheme. 1108 B.1.2. HMAC-SHA-2 1110 HMAC-SHA-2 refers to the set of pseudo-random functions corresponding 1111 to the HMAC message authentication code (now a FIPS standard 1112 [NIST198]) based on the new SHA-2 functions (FIPS 180-4 [NIST180]). 1113 HMAC-SHA-2 has a variable key length and variable output value 1114 depending on the hash function chosen (SHA-224, SHA-256, SHA-384, 1115 SHA-512, SHA -512/224, or SHA-512/256), that is 28, 32, 48, or 64 1116 octets. 1118 Using the new hash functions extends the search space for the 1119 produced keys. Where SHA-1 limits the search space to 20 octets, 1120 SHA-2 sets new limits of 28, 32, 48 and 64 octets. 1122 Object identifiers for HMAC are defined as follows: 1124 id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} 1125 id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} 1126 id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} 1127 id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} 1128 id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} 1129 id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} 1131 B.2. Encryption Schemes 1133 An example encryption scheme for PBES2 (Section 6.2) is AES-CBC-Pad. 1134 The schemes defined in PKCS #5 v2.0 [RFC2898], DES-CBC-Pad, DES-EDE3- 1135 CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad, are still supported, but 1136 DES-CBC-Pad, DES-EDE3-CBC-Pad, RC2-CBC-Pad are now considered legacy 1137 and should only be used for backwards compatibility reasons. 1139 The object identifiers given in this section are intended to be 1140 employed in the object set PBES2-Encs (Appendix A.4). 1142 B.2.1. DES-CBC-Pad 1144 DES-CBC-Pad is single-key DES [NIST46] in CBC mode [NIST81] with the 1145 RFC 1423 [RFC1423] padding operation (see Section 6.1.1). DES-CBC-Pad 1146 has an eight- octet encryption key and an eight-octet initialization 1147 vector. The key is considered as a 64-bit encoding of a 56-bit DES 1148 key with parity bits ignored. 1150 The object identifier desCBC (defined in the NIST/OSI Implementors' 1151 Workshop agreements) identifies the DES-CBC-Pad encryption scheme: 1153 desCBC OBJECT IDENTIFIER ::= 1154 {iso(1) identified-organization(3) oiw(14) secsig(3) 1155 algorithms(2) 7} 1157 The parameters field associated with this OID in an 1158 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1159 specifying the initialization vector for CBC mode. 1161 B.2.2. DES-EDE3-CBC-Pad 1163 DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [ANSIX952] with 1164 the RFC 1423 [RFC1423] padding operation. DES-EDE3-CBC-Pad has a 1165 24-octet encryption key and an eight-octet initialization vector. The 1166 key is considered as the concatenation of three eight-octet keys, 1167 each of which is a 64-bit encoding of a 56-bit DES key with parity 1168 bits ignored. 1170 The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad 1171 encryption scheme: 1173 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1175 The parameters field associated with this OID in an 1176 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1177 specifying the initialization vector for CBC mode. 1179 Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 1180 [ANSIX952]; the one given here is preferred since it specifies 1181 padding. 1183 B.2.3. RC2-CBC-Pad 1185 RC2-CBC-Pad is the RC2(tm) encryption algorithm [RFC2268] in CBC mode 1186 with the RFC 1423 [RFC1423] padding operation. RC2-CBC-Pad has a 1187 variable key length, from one to 128 octets, a separate "effective 1188 key bits" parameter from one to 1024 bits that limits the effective 1189 search space independent of the key length, and an eight-octet 1190 initialization vector. 1192 The object identifier rc2CBC identifies the RC2-CBC-Pad encryption 1193 scheme: 1195 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1197 The parameters field associated with OID in an AlgorithmIdentifier 1198 shall have type RC2-CBC-Parameter: 1200 RC2-CBC-Parameter ::= SEQUENCE { 1201 rc2ParameterVersion INTEGER OPTIONAL, 1202 iv OCTET STRING (SIZE(8)) } 1204 The fields of type RC2-CBCParameter have the following meanings: 1206 - rc2ParameterVersion is a proprietary RSA Security Inc. encoding 1207 of the "effective key bits" for RC2. The following encodings 1208 are defined: 1210 Effective Key Bits Encoding 1211 40 160 1212 64 120 1213 128 58 1214 b >= 256 b 1216 If the rc2ParameterVersion field is omitted, the "effective key bits" 1217 defaults to 32. (This is for backward compatibility with certain very 1218 old implementations.) 1220 - iv is the eight-octet initialization vector. 1222 B.2.4. RC5-CBC-Pad 1224 RC5-CBC-Pad is the RC5(tm) encryption algorithm [RC5] in CBC mode 1225 with RFC 5652 [RFC5652] padding operation, which is a generalization 1226 of the RFC 1423 [RFC1423] padding operation. The scheme is fully 1227 specified in [RFC2040]. RC5-CBC-Pad has a variable key length, from 0 1228 to 256 octets, and supports both a 64-bit block size and a 128-bit 1229 block size. For the former, it has an eight-octet initialization 1230 vector, and for the latter, a 16-octet initialization vector. 1231 RC5-CBC-Pad also has a variable number of "rounds" in the encryption 1232 operation, from 8 to 127. 1234 Note: For RC5 with a 64-bit block size, the padding string is as 1235 defined in RFC 1423 [RFC1423]. For RC5 with a 128-bit block size, the 1236 padding string consists of 16-(||M|| mod 16) octets each with value 1237 16-(||M|| mod 16). 1239 The object identifier rc5-CBC-PAD [RFC2040] identifies RC5-CBC-Pad 1240 encryption scheme: 1242 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1244 The parameters field associated with this OID in an 1245 AlgorithmIdentifier shall have type RC5-CBC-Parameters: 1247 RC5-CBC-Parameters ::= SEQUENCE { 1248 version INTEGER {v1-0(16)} (v1-0), 1249 rounds INTEGER (8..127), 1250 blockSizeInBits INTEGER (64 | 128), 1251 iv OCTET STRING OPTIONAL } 1253 The fields of type RC5-CBC-Parameters have the following meanings: 1255 - version is the version of the algorithm, which shall be v1-0. 1257 - rounds is the number of rounds in the encryption operation, 1258 which shall be between 8 and 127. 1260 - blockSizeInBits is the block size in bits, which shall be 64 or 1261 128. 1263 - iv is the initialization vector, an eight-octet string for 1264 64-bit RC5 and a 16-octet string for 128-bit RC5. The default 1265 is a string of the appropriate length consisting of zero 1266 octets. 1268 B.2.5. AES-CBC-Pad 1270 AES-CBC-Pad is the AES encryption algorithm [NIST197] in CBC mode 1271 with RFC 5652 [RFC5652] padding operation. AES-CBC-Pad has a variable 1272 key length of 16, 24, or 32 octets and has a 16-octet block size. It 1273 has a 16-octet initialization vector. 1275 Note: For AES, the padding string consists of 16-(||M|| mod 16) 1276 octets each with value 16-(||M|| mod 16). 1278 For AES, object identifiers are defined depending on key size and 1279 operation mode. For example, the 16-octet (128 bit) key AES 1280 encryption scheme in CBC mode would be aes128-CBC-Pad identifying the 1281 AES-CBC-PAD encryption scheme using a 16-octet key: 1283 aes128-CBC-PAD OBJECT IDENTIFIER ::= {aes 2} 1285 The AES object identifier is defined in Appendix C. 1287 The parameters field associated with this OID in an 1288 AlgorithmIdentifier shall have type OCTET STRING (SIZE(16)), 1289 specifying the initialization vector for CBC mode. 1291 B.3. Message Authentication Schemes 1293 An example message authentication scheme for PBMAC1 (Section 7.1) is 1294 HMAC-SHA-1. 1296 B.3.1. HMAC-SHA-1 1298 HMAC-SHA-1 is the HMAC message authentication scheme [RFC2104] based 1299 on the SHA-1 hash function [NIST180]. HMAC-SHA-1 has a variable key 1300 length and a 20-octet (160-bit) message authentication code. 1302 The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies 1303 the HMAC-SHA-1 message authentication scheme. (The object identifier 1304 is the same for both the pseudorandom function and the message 1305 authentication scheme; the distinction is to be understood by 1306 context.) This object identifier is intended to be employed in the 1307 object set PBMAC1-Macs (Appendix A.5). 1309 B.3.2. HMAC-SHA-2 1311 HMAC-SHA-2 refers to the set of HMAC message authentication schemes 1312 [NIST198] based on the SHA-2 functions [NIST180]. HMAC-SHA-2 has a 1313 variable key length and a message authentication code whose length 1314 is based on the hash function chosen (SHA-224, SHA-256, SHA-384, 1315 SHA-512, SHA-512/224, or SHA-512/256giving 28, 32, 48 or 64 octets). 1317 The object identifiers id-hmacWithSHA224, id-hmacWithSHA256, id- 1318 hmacWithSHA384, id-hmacWithSHA512, id-hmacWithSHA512-224,and id- 1319 hmacWithSHA512-256 (see Appendix B.1.2) identify the HMAC-SHA-2 1320 schemes. The object identifiers are the same for both the 1321 pseudo-random functions and the message authentication schemes; the 1322 distinction is to be understood by context. These object identifiers 1323 are intended to be employed in the object set PBMAC1-Macs (Appendix 1324 A.5) 1326 C. ASN.1 Module 1328 For reference purposes, the ASN.1 syntax in the preceding sections is 1329 presented as an ASN.1 module here. 1331 -- PKCS #5 v2.1 ASN.1 Module 1332 -- Revised October 27, 2012 1334 -- This module has been checked for conformance with the 1335 -- ASN.1 standard by the OSS ASN.1 Tools 1337 PKCS5v2-1 { 1338 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 1339 modules(16) pkcs5v2-1(2) 1340 } 1342 DEFINITIONS EXPLICIT TAGS ::= 1344 BEGIN 1346 -- ======================== 1347 -- Basic object identifiers 1348 -- ======================== 1350 nistAlgorithms OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) country(16) 1351 us(840) organization(1) 1352 gov(101) csor(3) 4} 1353 oiw OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) 14} 1354 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 1355 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 1356 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 1358 -- ======================= 1359 -- Basic types and classes 1360 -- ======================= 1362 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= 1363 SEQUENCE { 1364 algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), 1365 parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} 1366 {@algorithm}) OPTIONAL 1367 } 1369 ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER 1371 -- ====== 1372 -- PBKDF2 1373 -- ====== 1375 PBKDF2Algorithms ALGORITHM-IDENTIFIER ::= { 1376 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1377 ... 1378 } 1380 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 1382 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 1383 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 1385 PBKDF2-params ::= SEQUENCE { 1386 salt CHOICE { 1387 specified OCTET STRING, 1388 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 1389 }, 1390 iterationCount INTEGER (1..MAX), 1391 keyLength INTEGER (1..MAX) OPTIONAL, 1392 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 1393 algid-hmacWithSHA1 1394 } 1396 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 1398 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { 1399 {NULL IDENTIFIED BY id-hmacWithSHA1}, 1400 {NULL IDENTIFIED BY id-hmacWithSHA224}, 1401 {NULL IDENTIFIED BY id-hmacWithSHA256}, 1402 {NULL IDENTIFIED BY id-hmacWithSHA384}, 1403 {NULL IDENTIFIED BY id-hmacWithSHA512}, 1404 {NULL IDENTIFIED BY id-hmacWithSHA512-224}, 1405 {NULL IDENTIFIED BY id-hmacWithSHA512-256}, 1406 ... 1407 } 1409 -- ===== 1410 -- PBES1 1411 -- ===== 1413 PBES1Algorithms ALGORITHM-IDENTIFIER ::= { 1414 {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} | 1415 {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} | 1416 {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} | 1417 {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} | 1418 {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} | 1419 {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC}, 1420 ... 1421 } 1423 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 1424 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 1425 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 1426 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 1427 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 1428 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 1430 PBEParameter ::= SEQUENCE { 1431 salt OCTET STRING (SIZE(8)), 1432 iterationCount INTEGER 1433 } 1435 -- ===== 1436 -- PBES2 1437 -- ===== 1439 PBES2Algorithms ALGORITHM-IDENTIFIER ::= { 1440 {PBES2-params IDENTIFIED BY id-PBES2}, 1441 ... 1442 } 1444 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 1446 PBES2-params ::= SEQUENCE { 1447 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 1448 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} 1449 } 1451 PBES2-KDFs ALGORITHM-IDENTIFIER ::= { 1452 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1453 ... 1454 } 1456 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1458 -- ====== 1459 -- PBMAC1 1460 -- ====== 1462 PBMAC1Algorithms ALGORITHM-IDENTIFIER ::= { 1463 {PBMAC1-params IDENTIFIED BY id-PBMAC1}, 1464 ... 1465 } 1467 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1469 PBMAC1-params ::= SEQUENCE { 1470 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1471 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} 1472 } 1474 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= { 1475 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1476 ... 1477 } 1479 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1481 -- ===================== 1482 -- Supporting techniques 1483 -- ===================== 1485 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1486 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1488 SupportingAlgorithms ALGORITHM-IDENTIFIER ::= { 1489 {NULL IDENTIFIED BY id-hmacWithSHA1} | 1490 {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} | 1491 {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} | 1492 {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} | 1493 {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}, | 1494 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes128-CBC-PAD} | 1495 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes192-CBC-PAD} | 1496 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes256-CBC-PAD}, 1497 ... 1498 } 1500 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1501 id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} 1502 id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} 1503 id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} 1504 id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} 1505 id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} 1506 id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} 1508 desCBC OBJECT IDENTIFIER ::= {oiw secsig(3) algorithms(2) 7} 1510 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1512 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1514 RC2-CBC-Parameter ::= SEQUENCE { 1515 rc2ParameterVersion INTEGER OPTIONAL, 1516 iv OCTET STRING (SIZE(8)) 1517 } 1519 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1521 RC5-CBC-Parameters ::= SEQUENCE { 1522 version INTEGER {v1-0(16)} (v1-0), 1523 rounds INTEGER (8..127), 1524 blockSizeInBits INTEGER (64 | 128), 1525 iv OCTET STRING OPTIONAL 1526 } 1528 aes OBJECT IDENTIFIER ::= { nistAlgorithms 1 } 1529 aes128-CBC-PAD OBJECT IDENTIFIER ::= { aes 2 } 1530 aes192-CBC-PAD OBJECT IDENTIFIER ::= { aes 22 } 1531 aes256-CBC-PAD OBJECT IDENTIFIER ::= { aes 42 } 1533 END 1535 D. Intellectual Property Considerations 1537 EMC Corporation makes no patent claims on the general constructions 1538 described in this document, although specific underlying techniques 1539 may be covered. Among the underlying techniques, the RC5 encryption 1540 algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 1541 [RBLOCK1] and 5,835,600 [RBLOCK2]. 1543 RC2 and RC5 are trademarks of EMC Corporation. 1545 EMC Corporation makes no representation regarding intellectual 1546 property claims by other parties. Such determination is the 1547 responsibility of the user. 1549 E. Revision History 1551 Versions 1.0-1.3 1553 Versions 1.0-1.3 were distributed to participants in RSA Data 1554 Security Inc.'s Public-Key Cryptography Standards meetings in 1555 February and March 1991. 1557 Version 1.4 1559 Version 1.4 was part of the June 3, 1991 initial public release of 1560 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1561 document SEC-SIG-91-20. 1563 Version 1.5 1565 Version 1.5 incorporated several editorial changes, including 1566 updates to the references and the addition of a revision history. 1568 Version 2.0 1570 Version 2.0 incorporates major editorial changes in terms of the 1571 document structure, and introduces the PBES2 encryption scheme, 1572 the PBMAC1 message authentication scheme, and independent 1573 password-based key derivation functions. This version continues to 1574 support the encryption process in version 1.5. 1576 Version 2.1 1578 This document transfers PKCS #5 into the IETF and includes some 1579 minor changes from the authors for this submission. 1581 o Introduces AES/CBC as an encryption scheme for PBES2 and HMAC 1582 with the hash functions SHA-224, SHA-256, SHA-384, SHA-512, 1583 SHA-512/224, and SHA512/256 as pseudo-random functions for PBKDF2 1584 and message authentication schemes for PBMAC1. 1586 o Replacement of RSA with EMC in the "Intellectual Property 1587 Considerations". 1589 o Changes references to PKCS #5 and PKCS #8 to RSA 2898 and RFC 1590 5208/5898. 1592 o Incorporates two editorial errata reported on PKCS #5 [RFC2898]. 1594 o Added security considerations for MD2, MD5, and SHA-1. 1596 F. References 1598 F.1 Normative References 1600 [ANSIX952] 1601 American National Standard X9.52 - 1998, Triple Data Encryption 1602 Algorithm Modes of Operation. Working draft, Accredited 1603 Standards Committee X9, July 27, 1998. 1605 [BELLOV] 1606 S.M. Bellovin and M. Merritt. Encrypted key exchange: Password- 1607 based protocols secure against dictionary attacks. In 1608 Proceedings of the 1992 IEEE Computer Society Conference on 1609 Research in Security and Privacy, pages 72-84, IEEE Computer 1610 Society, 1992. 1612 [COCHRAN] 1613 M. Cochran. Notes on the Wang et al. 2^63 SHA-1 Differential 1614 Path. International Association for Cryptologic Research, ePrint 1615 Archive. August 2008. Available from 1616 1618 [ISO8824-1] 1619 ISO/IEC 8824-1: 2008: Information technology - Abstract Syntax 1620 Notation One (ASN.1) - Specification of basic notation. 2008. 1622 [ISO8824-2] 1623 ISO/IEC 8824-2: 2008: Information technology - Abstract Syntax 1624 Notation One (ASN.1) - Information object specification. 2008. 1626 [ISO8824-3] 1627 ISO/IEC 8824-3: 2008: Information technology - Abstract Syntax 1628 Notation One (ASN.1) - Constraint specification. 2008. 1630 [ISO8824-4] 1631 ISO/IEC 8824-4: 2008: Information technology - Abstract Syntax 1632 Notation One (ASN.1) - Parameterization of ASN.1 specifications. 1633 2008. 1635 [JABLON] 1636 D. Jablon. Strong password-only authenticated key exchange. ACM 1637 Computer Communications Review, October 1996. 1639 [MORRIS] 1640 Robert Morris and Ken Thompson. Password security: A case 1641 history. Communications of the ACM, 22(11):594-597, November 1642 1979. 1644 [NIST46] 1645 National Institute of Standards and Technology (NIST). FIPS PUB 1646 46-3: Data Encryption Standard. October 1999. 1648 [NIST81] 1649 National Institute of Standards and Technology (NIST). FIPS PUB 1650 81: DES Modes of Operation. December 2, 1980. 1652 [NIST180] 1653 National Institute of Standards and Technology (NIST). FIPS PUB 1654 180-4: Secure Hash Standard. March 2012. 1656 [NIST197] 1657 National Institute of Standards and Technology (NIST). FIPS PUB 1658 197: Advance Encryption Standard (AES). November 2001. 1660 [NIST198] 1661 National Institute of Standards and Technology (NIST). FIPS 1662 Publication 198-1: The Keyed - Hash Message Authentication Code 1663 (HMAC). July 2008. 1665 [NISTSP63] 1666 National Institute of Standards and Technology (NIST). Special 1667 Publication 800-63-2: Electronic Authentication Guideline, 1668 Appendix A. August 2013. 1670 [NISTSP132] 1671 National Institute of Standards and Technology (NIST). Special 1672 Publication 800-132: Recommendation for Password - Based Key 1673 Derivation, Part 1: Storage Applications. December 2010. 1675 [PKCS5_15] 1676 RSA Laboratories. PKCS #5: Password-Based Encryption Standard 1677 Version 1.5, November 1993. 1679 [PKCS8] 1680 RSA Laboratories. "PKCS #8: Private-Key Information Syntax 1681 Standard Version 1.2", RFC 5208, May 2008. 1683 [RBLOCK1] 1684 R.L. Rivest. Block-Encryption Algorithm with Data-Dependent 1685 Rotations. U.S. Patent No. 5,724,428, March 3, 1998. 1687 [RBLOCK2] 1688 R.L. Rivest. Block Encryption Algorithm with Data-Dependent 1689 Rotations. U.S. Patent No. 5,835,600, November 10, 1998. 1691 [RC5] 1692 R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the 1693 Second International Workshop on Fast Software Encryption, pages 1694 86-96, Springer-Verlag, 1994. 1696 [RFC1319] 1697 Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1698 1992, 1699 . 1701 [RFC1321] 1702 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1703 1992, 1704 . 1706 [RFC1423] 1707 Balenson, D., "Privacy Enhancement for Internet Electronic Mail: 1708 Part III: Algorithms, Modes, and Identifiers", RFC 1423, 1709 February 1993, 1710 . 1712 [RFC2040] 1713 Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 1714 RC5-CTS Algorithms", RFC 2040, October 1996, 1715 . 1717 [RFC2104] 1718 Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1719 for Message Authentication", RFC 2104, February 1997, 1720 . 1722 [RFC2268] 1723 Rivest, R., "A Description of the RC2(r) Encryption Algorithm", 1724 RFC 2268, March 1998, 1725 . 1727 [RFC2279] 1728 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1729 2279, January 1998, 1730 . 1732 [RFC2898] 1733 B. Kaliski., "PKCS #5: Password-Based Encryption Standard 1734 Version 2.0", RFC 2898, September 2000, 1735 . 1737 [RFC5652] 1738 R. Housley. RFC 5652: Cryptographic Message Syntax. IETF, 1739 September 2009, 1740 . 1742 [RFC5958] 1743 Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010, 1744 . 1746 [RFC6149] 1747 Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, 1748 March 2011, 1749 . 1751 [RFC6151] 1752 Turner, S. and L. Chen, "Updated Security Considerations for the 1753 MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 1754 2011, 1755 . 1757 [RFC6194] 1758 Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 1759 Considerations for the SHA-0 and SHA-1 Message-Digest 1760 Algorithms", RFC 6194, March 2011, 1761 . 1763 [WANG] 1764 X. Wang, A.C. Yao, and F. Yao. Cryptanalysis on SHA-1. 1765 Presented by Adi Shamir at the rump session of CRYPTO 2005. 1766 Slides may be found currently at 1767 1770 [WU] 1771 T. Wu. The Secure Remote Password protocol. In Proceedings of 1772 the 1998 Internet Society Network and Distributed System 1773 Security Symposium, pages 97-111, Internet Society, 1998. 1775 G. About PKCS 1777 The Public-Key Cryptography Standards are specifications produced by 1778 RSA Laboratories in cooperation with secure systems developers 1779 worldwide for the purpose of accelerating the deployment of public- 1780 key cryptography. First published in 1991 as a result of meetings 1781 with a small group of early adopters of public-key technology, the 1782 PKCS documents have become widely referenced and implemented. 1783 Contributions from the PKCS series have become part of many formal 1784 and de facto standards, including ANSI X9 documents, PKIX, SET, 1785 S/MIME, and SSL. 1787 Further development of most PKCS documents occurs through the IETF. 1788 Suggestions for improvement are welcome. 1790 H. Acknowledgements 1792 This document is based on a contribution of RSA Laboratories, the 1793 research center of RSA Security Inc. 1795 Authors' Addresses 1797 Kathleen M. Moriarty (editor) 1798 EMC Corporation 1799 176 South Street 1800 Hopkinton, MA 01748 1801 US 1803 Email: kathleen.moriarty@emc.com 1805 Burt Kaliski 1806 Verisign 1807 12061 Bluemont Way 1808 Reston, VA 20190 1809 US 1811 Email: bkaliski@verisign.com 1812 URI: http://verisignlabs.com 1814 Andreas Rusch 1815 RSA 1816 345 Queen Street 1817 Brisbane, QLD 4000 1818 AU 1820 Email: andreas.rusch@rsa.com