idnits 2.17.00 (12 Aug 2021) /tmp/idnits30532/draft-moriarty-pkcs5-v2dot1-02.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 1835 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5958], [PKCS8]), 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 873: '... keyLength INTEGER (1..MAX) OPTIONAL,...' RFC 2119 keyword, line 1204: '... rc2ParameterVersion INTEGER OPTIONAL,...' RFC 2119 keyword, line 1254: '... iv OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 1369: '... {@algorithm}) OPTIONAL...' RFC 2119 keyword, line 1394: '... 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 158 has weird spacing: '... dkLen leng...' == Line 162 has weird spacing: '... Hash und...' == Line 164 has weird spacing: '... hLen len...' == Line 183 has weird spacing: '... psLen leng...' == Line 195 has weird spacing: '... \xor bit...' == (9 more instances...) -- The document date (September 2, 2016) is 2086 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 1686 looks like a reference -- Missing reference section? 'RFC5958' on line 1749 looks like a reference -- Missing reference section? 'BELLOV' on line 1608 looks like a reference -- Missing reference section? 'JABLON' on line 1638 looks like a reference -- Missing reference section? 'WU' on line 1777 looks like a reference -- Missing reference section? 'RFC2898' on line 1739 looks like a reference -- Missing reference section? 'MORRIS' on line 1642 looks like a reference -- Missing reference section? 'RFC2279' on line 1734 looks like a reference -- Missing reference section? 'NISTSP63' on line 1668 looks like a reference -- Missing reference section? 'NISTSP132' on line 1673 looks like a reference -- Missing reference section? 'RFC1319' on line 1703 looks like a reference -- Missing reference section? 'RFC1321' on line 1708 looks like a reference -- Missing reference section? 'NIST180' on line 1655 looks like a reference -- Missing reference section? 'NIST46' on line 1647 looks like a reference -- Missing reference section? 'RFC2268' on line 1729 looks like a reference -- Missing reference section? 'NIST81' on line 1651 looks like a reference -- Missing reference section? 'RFC1423' on line 1713 looks like a reference -- Missing reference section? 'RFC6149' on line 1753 looks like a reference -- Missing reference section? 'RFC6151' on line 1758 looks like a reference -- Missing reference section? 'RFC6194' on line 1764 looks like a reference -- Missing reference section? 'ISO8824-1' on line 1621 looks like a reference -- Missing reference section? 'ISO8824-2' on line 1625 looks like a reference -- Missing reference section? 'ISO8824-3' on line 1629 looks like a reference -- Missing reference section? 'ISO8824-4' on line 1633 looks like a reference -- Missing reference section? 'RFC2104' on line 1724 looks like a reference -- Missing reference section? 'WANG' on line 1770 looks like a reference -- Missing reference section? 'COCHRAN' on line 1615 looks like a reference -- Missing reference section? 'NIST198' on line 1663 looks like a reference -- Missing reference section? 'ANSIX952' on line 1603 looks like a reference -- Missing reference section? 'RC5' on line 1698 looks like a reference -- Missing reference section? 'RFC5652' on line 1744 looks like a reference -- Missing reference section? 'RFC2040' on line 1719 looks like a reference -- Missing reference section? 'NIST197' on line 1659 looks like a reference -- Missing reference section? 'RBLOCK1' on line 1690 looks like a reference -- Missing reference section? 'RBLOCK2' on line 1694 looks like a reference Summary: 2 errors (**), 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: March 9, 2017 Verisign 5 A. Rusch 6 RSA 7 September 2, 2016 9 PKCS #5: Password-Based Cryptography Specification 10 Version 2.1 11 draft-moriarty-pkcs5-v2dot1-02 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 [PKCS8][RFC5958]. It is expected that application standards and 25 implementation profiles based on these specifications may include 26 additional 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 [PKCS5_21] 34 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) 35 series. By publishing this RFC, change control is transferred to the 36 IETF. 38 Status of this Memo 40 This Internet-Draft is submitted to IETF in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 Copyright and License Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4. Salt and Iteration Count . . . . . . . . . . . . . . . . . . . 6 80 4.1. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.2. Iteration Count . . . . . . . . . . . . . . . . . . . . . . 8 82 5. Key Derivation Functions . . . . . . . . . . . . . . . . . . . 8 83 5.1. PBKDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 5.2. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6. Encryption Schemes . . . . . . . . . . . . . . . . . . . . . . 12 86 6.1. PBES1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 6.1.1. PBES1 Encryption Operation . . . . . . . . . . . . . . 12 88 6.1.2. PBES1 Decryption Operation . . . . . . . . . . . . . . 13 89 6.2. PBES2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 6.2.1. PBES2 Encryption Operation . . . . . . . . . . . . . . 14 91 6.2.2. PBES2 Decryption Operation . . . . . . . . . . . . . . 15 92 7. Message Authentication Schemes . . . . . . . . . . . . . . . . 16 93 7.1. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 7.1.1 PBMAC1 Generation Operation . . . . . . . . . . . . . . 16 95 7.1.2. PBMAC1 Verification Operation . . . . . . . . . . . . . 17 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 98 A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 A.1. PBKDF1 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 A.2. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 A.3. PBES1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 A.4. PBES2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 A.5. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 B. Supporting Techniques . . . . . . . . . . . . . . . . . . . . . 22 105 B.1. Pseudorandom functions . . . . . . . . . . . . . . . . . . 22 106 B.1.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . . 22 107 B.1.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . . 23 108 B.2. Encryption Schemes . . . . . . . . . . . . . . . . . . . . 24 109 B.2.1. DES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 24 110 B.2.2. DES-EDE3-CBC-Pad . . . . . . . . . . . . . . . . . . . 25 111 B.2.3. RC2-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 25 112 B.2.4. RC5-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 26 113 B.2.5. AES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . . 27 114 B.3. Message Authentication Schemes . . . . . . . . . . . . . . 27 115 B.3.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . . 27 116 B.3.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . . 28 117 C. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 28 118 D. Intellectual Property Considerations . . . . . . . . . . . . . 32 119 E. Revision History . . . . . . . . . . . . . . . . . . . . . . . 32 120 F. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 121 F.1 Normative References . . . . . . . . . . . . . . . . . . . 34 122 G. About PKCS . . . . . . . . . . . . . . . . . . . . . . . . . . 36 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 125 1. Introduction 127 This document provides recommendations for the implementation of 128 password-based cryptography, covering the following aspects: 130 - key derivation functions 131 - encryption schemes 132 - message-authentication schemes 133 - ASN.1 syntax identifying the techniques 135 The recommendations are intended for general application within 136 computer and communications systems, and as such include a fair 137 amount of flexibility. They are particularly intended for the 138 protection of sensitive information such as private keys as in PKCS 139 #8 [PKCS8][RFC5958]. It is expected that application standards and 140 implementation profiles based on these specifications may include 141 additional constraints. 143 Other cryptographic techniques based on passwords, such as password- 144 based key entity authentication and key establishment protocols 145 [BELLOV][JABLON][WU] are outside the scope of this document. 146 Guidelines for the selection of passwords are also outside the scope. 147 This document supersedes PKCS #5 version 2.0 [RFC2898], but includes 148 compatible techniques. 150 2. Notation 152 C ciphertext, an octet string 154 c iteration count, a positive integer 156 DK derived key, an octet string 158 dkLen length in octets of derived key, a positive integer 160 EM encoded message, an octet string 162 Hash underlying hash function 164 hLen length in octets of pseudorandom function output, a positive 165 integer 167 l length in blocks of derived key, a positive integer 169 IV initialization vector, an octet string 171 K encryption key, an octet string 173 KDF key derivation function 175 M message, an octet string 177 P password, an octet string 179 PRF underlying pseudorandom function 181 PS padding string, an octet string 183 psLen length in octets of padding string, a positive integer 185 S salt, an octet string 187 T message authentication code, an octet string 189 T_1, ..., T_l, U_1, ..., U_c 190 intermediate values, octet strings 192 01, 02, ..., 08 193 octets with value 1, 2, ..., 8 195 \xor bit-wise exclusive-or of two octet strings 197 || || octet length operator 199 || concatenation operator 201 substring extraction operator: extracts octets i through j, 202 0 <= i <= j 204 3. Overview 206 In many applications of public-key cryptography, user security is 207 ultimately dependent on one or more secret text values or passwords. 208 Since a password is not directly applicable as a key to any 209 conventional cryptosystem, however, some processing of the password 210 is required to perform cryptographic operations with it. Moreover, as 211 passwords are often chosen from a relatively small space, special 212 care is required in that processing to defend against search attacks. 214 A general approach to password-based cryptography, as described by 215 Morris and Thompson [MORRIS] for the protection of password tables, 216 is to combine a password with a salt to produce a key. The salt can 217 be viewed as an index into a large set of keys derived from the 218 password, and need not be kept secret. Although it may be possible 219 for an opponent to construct a table of possible passwords (a so- 220 called "dictionary attack"), constructing a table of possible keys 221 will be difficult, since there will be many possible keys for each 222 password. An opponent will thus be limited to searching through 223 passwords separately for each salt. 225 Another approach to password-based cryptography is to construct key 226 derivation techniques that are relatively expensive, thereby 227 increasing the cost of exhaustive search. One way to do this is to 228 include an iteration count in the key derivation technique, 229 indicating how many times to iterate some underlying function by 230 which keys are derived. A modest number of iterations, say 1000, is 231 not likely to be a burden for legitimate parties when computing a 232 key, but will be a significant burden for opponents. 234 Salt and iteration count formed the basis for password-based 235 encryption in PKCS #5 v2.0, and adopted here as well for the various 236 cryptographic operations. Thus, password-based key derivation as 237 defined here is a function of a password, a salt, and an iteration 238 count, where the latter two quantities need not be kept secret. 240 From a password-based key derivation function, it is straightforward 241 to define password-based encryption and message authentication 242 schemes. As in PKCS #5 v2.0, the password-based encryption schemes 243 here are based on an underlying, conventional encryption scheme, 244 where the key for the conventional scheme is derived from the 245 password. Similarly, the password-based message authentication scheme 246 is based on an underlying conventional scheme. This two-layered 247 approach makes the password-based techniques modular in terms of the 248 underlying techniques they can be based on. 250 It is expected that the password-based key derivation functions may 251 find other applications than just the encryption and message 252 authentication schemes defined here. For instance, one might derive a 253 set of keys with a single application of a key derivation function, 254 rather than derive each key with a separate application of the 255 function. The keys in the set would be obtained as substrings of the 256 output of the key derivation function. This approach might be 257 employed as part of key establishment in a session-oriented protocol. 258 Another application is password checking, where the output of the key 259 derivation function is stored (along with the salt and iteration 260 count) for the purposes of subsequent verification of a password. 262 Throughout this document, a password is considered to be an octet 263 string of arbitrary length whose interpretation as a text string is 264 unspecified. In the interest of interoperability, however, it is 265 recommended that applications follow some common text encoding rules. 266 ASCII and UTF-8 [RFC2279] are two possibilities. (ASCII is a subset 267 of UTF-8.) 269 Although the selection of passwords is outside the scope of this 270 document, guidelines have been published [NISTSP63] that may well be 271 taken into account. 273 4. Salt and Iteration Count 275 Inasmuch as salt and iteration count are central to the techniques 276 defined in this document, some further discussion is warranted. 278 4.1. Salt 280 A salt in password-based cryptography has traditionally served the 281 purpose of producing a large set of keys corresponding to a given 282 password, among which one is selected at random according to the 283 salt. An individual key in the set is selected by applying a key 284 derivation function KDF, as 286 DK = KDF (P, S) 288 where DK is the derived key, P is the password, and S is the salt. 289 This has two benefits: 291 1. It is difficult for an opponent to precompute all the keys 292 corresponding to a dictionary of passwords, or even the most 293 likely keys. If the salt is 64 bits long, for instance, there 294 will be as many as 2^64 keys for each password. An opponent is 295 thus limited to searching for passwords after a password-based 296 operation has been performed and the salt is known. 298 2. It is unlikely that the same key will be selected twice. Again, 299 if the salt is 64 bits long, the chance of "collision" between 300 keys does not become significant until about 2^32 keys have 301 been produced, according to the Birthday Paradox. This 302 addresses some of the concerns about interactions between 303 multiple uses of the same key, which may apply for some 304 encryption and authentication techniques. 306 In password-based encryption, the party encrypting a message can gain 307 assurance that these benefits are realized simply by selecting a 308 large and sufficiently random salt when deriving an encryption key 309 from a password. A party generating a message authentication code can 310 gain such assurance in a similar fashion. 312 The party decrypting a message or verifying a message authentication 313 code, however, cannot be sure that a salt supplied by another party 314 has actually been generated at random. It is possible, for instance, 315 that the salt may have been copied from another password-based 316 operation, in an attempt to exploit interactions between multiple 317 uses of the same key. For instance, suppose two legitimate parties 318 exchange a encrypted message, where the encryption key is an 80-bit 319 key derived from a shared password with some salt. An opponent could 320 take the salt from that encryption and provide it to one of the 321 parties as though it were for a 40-bit key. If the party reveals the 322 result of decryption with the 40-bit key, the opponent may be able to 323 solve for the 40-bit key. In the case that 40-bit key is the first 324 half of the 80-bit key, the opponent can then readily solve for the 325 remaining 40 bits of the 80-bit key. 327 To defend against such attacks, either the interaction between 328 multiple uses of the same key should be carefully analyzed, or the 329 salt should contain data that explicitly distinguishes between 330 different operations. For instance, the salt might have an 331 additional, non-random octet that specifies whether the derived key 332 is for encryption, for message authentication, or for some other 333 operation. 335 Based on this, the following is recommended for salt selection: 337 1. If there is no concern about interactions between multiple uses 338 of the same key (or a prefix of that key) with the password- 339 based encryption and authentication techniques supported for a 340 given password, then the salt may be generated at random and 341 need not be checked for a particular format by the party 342 receiving the salt. It should be at least eight octets (64 343 bits) long. 345 2. Otherwise, the salt should contain data that explicitly 346 distinguishes between different operations and different key 347 lengths, in addition to a random part that is at least eight 348 octets long, and this data should be checked or regenerated by 349 the party receiving the salt. For instance, the salt could have 350 an additional non-random octet that specifies the purpose of 351 the derived key. Alternatively, it could be the encoding of a 352 structure that specifies detailed information about the derived 353 key, such as the encryption or authentication technique and a 354 sequence number among the different keys derived from the 355 password. The particular format of the additional data is left 356 to the application. 358 Note. If a random number generator or pseudorandom generator is not 359 available, a deterministic alternative for generating the salt (or 360 the random part of it) is to apply a password-based key derivation 361 function to the password and the message M to be processed. For 362 instance, the salt could be computed with a key derivation function 363 as S = KDF (P, M). This approach is not recommended if the message M 364 is known to belong to a small message space (e.g., "Yes" or "No"), 365 however, since then there will only be a small number of possible 366 salts. 368 4.2. Iteration Count 370 An iteration count has traditionally served the purpose of increasing 371 the cost of producing keys from a password, thereby also increasing 372 the difficulty of attack. Mathematically, an iteration count of c 373 will increase the security strength of a password by log2(c) 374 bits against trial based attacks like brute force or dictionary 375 attacks. 377 Choosing a reasonable value for the iteration count depends on 378 environment and circumstances, and varies from application to 379 application. This document follows the recommendations made in FIPS 380 Special Publication 800-132 [NISTSP132], which says "The iteration 381 count shall be selected as large as possible, as long as the time 382 required to generate the key using the entered password is acceptable 383 for the users. [...] A minimum iteration count of 1,000 is 384 recommended. For especially critical keys, or for very powerful 385 systems or systems where user-perceived performance is not critical, 386 an iteration count of 10,000,000 may be appropriate". 388 5. Key Derivation Functions 390 A key derivation function produces a derived key from a base key and 391 other parameters. In a password-based key derivation function, the 392 base key is a password and the other parameters are a salt value and 393 an iteration count, as outlined in Section 3. 395 The primary application of the password-based key derivation 396 functions defined here is in the encryption schemes in Section 6 and 397 the message authentication scheme in Section 7. Other applications 398 are certainly possible, hence the independent definition of these 399 functions. 401 Two functions are specified in this section: PBKDF1 and PBKDF2. 402 PBKDF2 is recommended for new applications; PBKDF1 is included only 403 for compatibility with existing applications, and is not recommended 404 for new applications. 406 A typical application of the key derivation functions defined here 407 might include the following steps: 409 1. Select a salt S and an iteration count c, as outlined in 410 Section 4. 412 2. Select a length in octets for the derived key, dkLen. 414 3. Apply the key derivation function to the password, the salt, 415 the iteration count and the key length to produce a derived 416 key. 418 4. Output the derived key. 420 Any number of keys may be derived from a password by varying the 421 salt, as described in Section 3. 423 5.1. PBKDF1 425 PBKDF1 applies a hash function, which shall be MD2 [RFC1319], MD5 426 [RFC1321] or SHA-1 [NIST180], to derive keys. The length of the 427 derived key is bounded by the length of the hash function output, 428 which is 16 octets for MD2 and MD5 and 20 octets for SHA-1. PBKDF1 is 429 compatible with the key derivation process in PKCS #5 v1.5 430 [PKCS5_15]. 432 PBKDF1 is recommended only for compatibility with existing 433 applications since the keys it produces may not be large enough for 434 some applications. 436 PBKDF1 (P, S, c, dkLen) 438 Options: Hash underlying hash function 440 Input: P password, an octet string 441 S salt, an octet string 442 c iteration count, a positive integer 443 dkLen intended length in octets of derived key, 444 a positive integer, at most 16 for MD2 or 445 MD5 and 20 for SHA-1 446 Output: DK derived key, a dkLen-octet string 448 Steps: 450 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output 451 "derived key too long" and stop. 453 2. Apply the underlying hash function Hash for c iterations to the 454 concatenation of the password P and the salt S, then extract 455 the first dkLen octets to produce a derived key DK: 457 T_1 = Hash (P || S) , 458 T_2 = Hash (T_1) , 459 ... 460 T_c = Hash (T_{c-1}) , 461 DK = T_c<0..dkLen-1> 463 3. Output the derived key DK. 465 5.2. PBKDF2 467 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an 468 example) to derive keys. The length of the derived key is essentially 469 unbounded. (However, the maximum effective search space for the 470 derived key may be limited by the structure of the underlying 471 pseudorandom function. See Appendix B.1 for further discussion.) 472 PBKDF2 is recommended for new applications. 474 PBKDF2 (P, S, c, dkLen) 476 Options: PRF underlying pseudorandom function (hLen 477 denotes the length in octets of the 478 pseudorandom function output) 480 Input: P password, an octet string 481 S salt, an octet string 482 c iteration count, a positive integer 483 dkLen intended length in octets of the derived 484 key, a positive integer, at most 485 (2^32 - 1) * hLen 487 Output: DK derived key, a dkLen-octet string 489 Steps: 491 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" and 492 stop. 494 2. Let l be the number of hLen-octet blocks in the derived key, 495 rounding up, and let r be the number of octets in the last 496 block: 498 l = CEIL (dkLen / hLen) , 499 r = dkLen - (l - 1) * hLen . 501 Here, CEIL (x) is the "ceiling" function, i.e. the smallest 502 integer greater than, or equal to, x. 504 3. For each block of the derived key apply the function F defined 505 below to the password P, the salt S, the iteration count c, and 506 the block index to compute the block: 508 T_1 = F (P, S, c, 1) , 509 T_2 = F (P, S, c, 2) , 510 ... 511 T_l = F (P, S, c, l) , 513 where the function F is defined as the exclusive-or sum of the 514 first c iterates of the underlying pseudorandom function PRF 515 applied to the password P and the concatenation of the salt S 516 and the block index i: 518 F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c 520 where 521 U_1 = PRF (P, S || INT (i)) , 522 U_2 = PRF (P, U_1) , 523 ... 524 U_c = PRF (P, U_{c-1}) . 526 Here, INT (i) is a four-octet encoding of the integer i, most 527 significant octet first. 529 4. Concatenate the blocks and extract the first dkLen octets to 530 produce a derived key DK: 532 DK = T_1 || T_2 || ... || T_l<0..r-1> 534 5. Output the derived key DK. 536 Note. The construction of the function F follows a "belt-and- 537 suspenders" approach. The iterates U_i are computed recursively to 538 remove a degree of parallelism from an opponent; they are exclusive- 539 ored together to reduce concerns about the recursion degenerating 540 into a small set of values. 542 6. Encryption Schemes 544 An encryption scheme, in the symmetric setting, consists of an 545 encryption operation and a decryption operation, where the encryption 546 operation produces a ciphertext from a message under a key, and the 547 decryption operation recovers the message from the ciphertext under 548 the same key. In a password-based encryption scheme, the key is a 549 password. 551 A typical application of a password-based encryption scheme is a 552 private-key protection method, where the message contains private-key 553 information, as in PKCS #8. The encryption schemes defined here would 554 be suitable encryption algorithms in that context. 556 Two schemes are specified in this section: PBES1 and PBES2. PBES2 is 557 recommended for new applications; PBES1 is included only for 558 compatibility with existing applications, and is not recommended for 559 new applications. 561 6.1. PBES1 563 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying 564 block cipher, which shall be either DES [NIST46] or RC2(tm) [RFC2268] 565 in CBC mode [NIST81]. PBES1 is compatible with the encryption scheme 566 in PKCS #5 v1.5 [PKCS5_15]. 568 PBES1 is recommended only for compatibility with existing 569 applications, since it supports only two underlying encryption 570 schemes, each of which has a key size (56 or 64 bits) that may not be 571 large enough for some applications. 573 6.1.1. PBES1 Encryption Operation 575 The encryption operation for PBES1 consists of the following steps, 576 which encrypt a message M under a password P to produce a ciphertext 577 C: 579 1. Select an eight-octet salt S and an iteration count c, as 580 outlined in Section 4. 582 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 583 password P, the salt S, and the iteration count c to produce at 584 derived key DK of length 16 octets: 586 DK = PBKDF1 (P, S, c, 16) . 588 3. Separate the derived key DK into an encryption key K consisting 589 of the first eight octets of DK and an initialization vector IV 590 consisting of the next eight octets: 592 K = DK<0..7> , 593 IV = DK<8..15> . 595 4. Concatenate M and a padding string PS to form an encoded 596 message EM: 598 EM = M || PS , 600 where the padding string PS consists of 8-(||M|| mod 8) octets 601 each with value 8-(||M|| mod 8). The padding string PS will 602 satisfy one of the following statements: 604 PS = 01, if ||M|| mod 8 = 7 ; 605 PS = 02 02, if ||M|| mod 8 = 6 ; 606 ... 607 PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0. 609 The length in octets of the encoded message will be a multiple 610 of eight and it will be possible to recover the message M 611 unambiguously from the encoded message. (This padding rule is 612 taken from RFC 1423 [RFC1423].) 614 5. Encrypt the encoded message EM with the underlying block cipher 615 (DES or RC2) in cipher block chaining mode under the encryption 616 key K with initialization vector IV to produce the ciphertext 617 C. For DES, the key K shall be considered as a 64-bit encoding 618 of a 56-bit DES key with parity bits ignored (see [NIST46]). 619 For RC2, the "effective key bits" shall be 64 bits. 621 6. Output the ciphertext C. 623 The salt S and the iteration count c may be conveyed to the party 624 performing decryption in an AlgorithmIdentifier value (see Appendix 625 A.3). 627 6.1.2. PBES1 Decryption Operation 629 The decryption operation for PBES1 consists of the following steps, 630 which decrypt a ciphertext C under a password P to recover a message 631 M: 633 1. Obtain the eight-octet salt S and the iteration count c. 635 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 636 password P, the salt S, and the iteration count c to produce a 637 derived key DK of length 16 octets: 639 DK = PBKDF1 (P, S, c, 16) 641 3. Separate the derived key DK into an encryption key K consisting 642 of the first eight octets of DK and an initialization vector IV 643 consisting of the next eight octets: 645 K = DK<0..7> , 646 IV = DK<8..15> . 648 4. Decrypt the ciphertext C with the underlying block cipher (DES 649 or RC2) in cipher block chaining mode under the encryption key 650 K with initialization vector IV to recover an encoded message 651 EM. If the length in octets of the ciphertext C is not a 652 multiple of eight, output "decryption error" and stop. 654 5. Separate the encoded message EM into a message M and a padding 655 string PS: 657 EM = M || PS , 659 where the padding string PS consists of some number psLen 660 octets each with value psLen, where psLen is between 1 and 8. 661 If it is not possible to separate the encoded message EM in 662 this manner, output "decryption error" and stop. 664 6. Output the recovered message M. 666 6.2. PBES2 668 PBES2 combines a password-based key derivation function, which shall 669 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 670 underlying encryption scheme (see Appendix B.2 for examples). The key 671 length and any other parameters for the underlying encryption scheme 672 depend on the scheme. 674 PBES2 is recommended for new applications. 676 6.2.1. PBES2 Encryption Operation 678 The encryption operation for PBES2 consists of the following steps, 679 which encrypt a message M under a password P to produce a ciphertext 680 C, applying a selected key derivation function KDF and a selected 681 underlying encryption scheme: 683 1. Select a salt S and an iteration count c, as outlined in 684 Section 4. 686 2. Select the length in octets, dkLen, for the derived key for the 687 underlying encryption scheme. 689 3. Apply the selected key derivation function to the password P, 690 the salt S, and the iteration count c to produce a derived key 691 DK of length dkLen octets: 693 DK = KDF (P, S, c, dkLen) . 695 4. Encrypt the message M with the underlying encryption scheme 696 under the derived key DK to produce a ciphertext C. (This step 697 may involve selection of parameters such as an initialization 698 vector and padding, depending on the underlying scheme.) 700 5. Output the ciphertext C. 702 The salt S, the iteration count c, the key length dkLen, and 703 identifiers for the key derivation function and the underlying 704 encryption scheme may be conveyed to the party performing decryption 705 in an AlgorithmIdentifier value (see Appendix A.4). 707 6.2.2. PBES2 Decryption Operation 709 The decryption operation for PBES2 consists of the following steps, 710 which decrypt a ciphertext C under a password P to recover a message 711 M: 713 1. Obtain the salt S for the operation. 715 2. Obtain the iteration count c for the key derivation function. 717 3. Obtain the key length in octets, dkLen, for the derived key for 718 the underlying encryption scheme. 720 4. Apply the selected key derivation function to the password P, 721 the salt S, and the iteration count c to produce a derived key 722 DK of length dkLen octets: 724 DK = KDF (P, S, c, dkLen) . 726 5. Decrypt the ciphertext C with the underlying encryption scheme 727 under the derived key DK to recover a message M. If the 728 decryption function outputs "decryption error," then output 729 "decryption error" and stop. 731 6. Output the recovered message M. 733 7. Message Authentication Schemes 735 A message authentication scheme consists of a MAC (message 736 authentication code) generation operation and a MAC verification 737 operation, where the MAC generation operation produces a message 738 authentication code from a message under a key, and the MAC 739 verification operation verifies the message authentication code under 740 the same key. In a password-based message authentication scheme, the 741 key is a password. 743 One scheme is specified in this section: PBMAC1. 745 7.1. PBMAC1 747 PBMAC1 combines a password-based key derivation function, which shall 748 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 749 underlying message authentication scheme (see Appendix B.3 for an 750 example). The key length and any other parameters for the underlying 751 message authentication scheme depend on the scheme. 753 7.1.1 PBMAC1 Generation Operation 755 The MAC generation operation for PBMAC1 consists of the following 756 steps, which process a message M under a password P to generate a 757 message authentication code T, applying a selected key derivation 758 function KDF and a selected underlying message authentication scheme: 760 1. Select a salt S and an iteration count c, as outlined in 761 Section 4. 763 2. Select a key length in octets, dkLen, for the derived key for 764 the underlying message authentication function. 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 generate a 774 message authentication code T. 776 5. Output the message authentication code T. 778 The salt S, the iteration count c, the key length dkLen, and 779 identifiers for the key derivation function and underlying message 780 authentication scheme may be conveyed to the party performing 781 verification in an AlgorithmIdentifier value (see Appendix A.5). 783 7.1.2. PBMAC1 Verification Operation 785 The MAC verification operation for PBMAC1 consists of the following 786 steps, which process a message M under a password P to verify a 787 message authentication code T: 789 1. Obtain the salt S and the iteration count c. 791 2. Obtain the key length in octets, dkLen, for the derived key for 792 the underlying message authentication scheme. 794 3. Apply the selected key derivation function to the password P, 795 the salt S, and the iteration count c to produce a derived key 796 DK of length dkLen octets: 798 DK = KDF (P, S, c, dkLen) . 800 4. Process the message M with the underlying message 801 authentication scheme under the derived key DK to verify the 802 message authentication code T. 804 5. If the message authentication code verifies, output "correct"; 805 else output "incorrect." 807 8. Security Considerations 809 Password-based cryptography is generally limited in the security that 810 it can provide, particularly for methods such as those defined in 811 this document where off-line password search is possible. While the 812 use of salt and iteration count can increase the complexity of attack 813 (see Section 4 for recommendations), it is essential that passwords 814 are selected well, and relevant guidelines (e.g., [NISTSP63]) should 815 be taken into account. It is also important that passwords be 816 protected well if stored. 818 In general, different keys should be derived from a password for 819 different uses to minimize the possibility of unintended 820 interactions. For password-based encryption with a single algorithm, 821 a random salt is sufficient to ensure that different keys will be 822 produced. In certain other situations, as outlined in Section 4, a 823 structured salt is necessary. The recommendations in Section 4 should 824 thus be taken into account when selecting the salt value. 826 For information on security considerations for MD2 [RFC1319] see 827 [RFC6149], for MD5 [RFC1321] see [RFC6151], for SHA-1 [NIST180] see 828 [RFC6194]. 830 9. IANA Considerations 832 None. 834 A. ASN.1 Syntax 836 This section defines ASN.1 syntax for the key derivation functions, 837 the encryption schemes, the message authentication scheme, and 838 supporting techniques. The intended application of these definitions 839 includes PKCS #8 and other syntax for key management, encrypted data, 840 and integrity-protected data. (Various aspects of ASN.1 are specified 841 in several ISO/IEC standards [ISO8824-1][ISO8824-2][ISO8824-3] 842 [ISO8824-4].) 844 The object identifier pkcs-5 identifies the arc of the OID tree from 845 which the PKCS #5-specific OIDs in this section are derived: 847 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 848 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 849 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 851 A.1. PBKDF1 853 No object identifier is given for PBKDF1, as the object identifiers 854 for PBES1 are sufficient for existing applications and PBKDF2 is 855 recommended for new applications. 857 A.2. PBKDF2 859 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation 860 function (Section 5.2). 862 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 864 The parameters field associated with this OID in an 865 AlgorithmIdentifier shall have type PBKDF2-params: 867 PBKDF2-params ::= SEQUENCE { 868 salt CHOICE { 869 specified OCTET STRING, 870 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 871 }, 872 iterationCount INTEGER (1..MAX), 873 keyLength INTEGER (1..MAX) OPTIONAL, 874 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 875 algid-hmacWithSHA1 } 877 The fields of type PBKDF2-params have the following meanings: 879 - salt specifies the salt value, or the source of the salt value. 880 It shall either be an octet string or an algorithm ID with an 881 OID in the set PBKDF2-SaltSources, which is reserved for future 882 versions of PKCS #5. 884 The salt-source approach is intended to indicate how the salt 885 value is to be generated as a function of parameters in the 886 algorithm ID, application data, or both. For instance, it may 887 indicate that the salt value is produced from the encoding of a 888 structure that specifies detailed information about the derived 889 key as suggested in Section 4.1. Some of the information may be 890 carried elsewhere, e.g., in the encryption algorithm ID. 891 However, such facilities are deferred to a future version of 892 PKCS #5. 894 In this version, an application may achieve the benefits 895 mentioned in Section 4.1 by choosing a particular 896 interpretation of the salt value in the specified alternative. 898 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 900 - iterationCount specifies the iteration count. The maximum 901 iteration count allowed depends on the implementation. It is 902 expected that implementation profiles may further constrain the 903 bounds. 905 - keyLength, an optional field, is the length in octets of the 906 derived key. The maximum key length allowed depends on the 907 implementation; it is expected that implementation profiles may 908 further constrain the bounds. The field is provided for 909 convenience only; the key length is not cryptographically 910 protected. If there is concern about interaction between 911 operations with different key lengths for a given salt (see 912 Section 4.1), the salt should distinguish among the different 913 key lengths. 915 - prf identifies the underlying pseudorandom function. It shall 916 be an algorithm ID with an OID in the set PBKDF2-PRFs, which 917 for this version of PKCS #5 shall consist of id-hmacWithSHA1 918 (see Appendix B.1.1) and any other OIDs defined by the 919 application. 921 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { 922 {NULL IDENTIFIED BY id-hmacWithSHA1}, 923 {NULL IDENTIFIED BY id-hmacWithSHA224}, 924 {NULL IDENTIFIED BY id-hmacWithSHA256}, 925 {NULL IDENTIFIED BY id-hmacWithSHA384}, 926 {NULL IDENTIFIED BY id-hmacWithSHA512}, 927 {NULL IDENTIFIED BY id-hmacWithSHA512-224}, 928 {NULL IDENTIFIED BY id-hmacWithSHA512-256}, 929 ... 930 } 932 The default pseudorandom function is HMAC-SHA-1: 934 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 935 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 937 A.3. PBES1 939 Different object identifiers identify the PBES1 encryption scheme 940 (Section 6.1) according to the underlying hash function in the key 941 derivation function and the underlying block cipher, as summarized in 942 the following table: 944 Hash Function Block Cipher OID 945 MD2 DES pkcs-5.1 946 MD2 RC2 pkcs-5.4 947 MD5 DES pkcs-5.3 948 MD5 RC2 pkcs-5.6 949 SHA-1 DES pkcs-5.10 950 SHA-1 RC2 pkcs-5.11 952 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 953 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 954 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 955 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 956 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 957 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 959 For each OID, the parameters field associated with the OID in an 960 AlgorithmIdentifier shall have type PBEParameter: 962 PBEParameter ::= SEQUENCE { 963 salt OCTET STRING (SIZE(8)), 964 iterationCount INTEGER } 966 The fields of type PBEParameter have the following meanings: 968 - salt specifies the salt value, an eight-octet string. 970 - iterationCount specifies the iteration count. 972 A.4. PBES2 974 The object identifier id-PBES2 identifies the PBES2 encryption scheme 975 (Section 6.2). 977 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 979 The parameters field associated with this OID in an 980 AlgorithmIdentifier shall have type PBES2-params: 982 PBES2-params ::= SEQUENCE { 983 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 984 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } 986 The fields of type PBES2-params have the following meanings: 988 - keyDerivationFunc identifies the underlying key derivation 989 function. It shall be an algorithm ID with an OID in the set 990 PBES2-KDFs, which for this version of PKCS #5 shall consist of 991 id-PBKDF2 (Appendix A.2). 993 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 994 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 996 - encryptionScheme identifies the underlying encryption scheme. 997 It shall be an algorithm ID with an OID in the set PBES2-Encs, 998 whose definition is left to the application. Example underlying 999 encryption schemes are given in Appendix B.2. 1001 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1003 A.5. PBMAC1 1005 The object identifier id-PBMAC1 identifies the PBMAC1 message 1006 authentication scheme (Section 7.1). 1008 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1010 The parameters field associated with this OID in an 1011 AlgorithmIdentifier shall have type PBMAC1-params: 1013 PBMAC1-params ::= SEQUENCE { 1014 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1015 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } 1017 The keyDerivationFunc field has the same meaning as the corresponding 1018 field of PBES2-params (Appendix A.4) except that the set of OIDs is 1019 PBMAC1-KDFs. 1021 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 1022 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1024 The messageAuthScheme field identifies the underlying message 1025 authentication scheme. It shall be an algorithm ID with an OID in the 1026 set PBMAC1-MACs, whose definition is left to the application. Example 1027 underlying encryption schemes are given in Appendix B.3. 1029 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1031 B. Supporting Techniques 1033 This section gives several examples of underlying functions and 1034 schemes supporting the password-based schemes in Sections 5, 6 and 7. 1036 While these supporting techniques are appropriate for applications to 1037 implement, none of them is required to be implemented. It is 1038 expected, however, that profiles for PKCS #5 will be developed that 1039 specify particular supporting techniques. 1041 This section also gives object identifiers for the supporting 1042 techniques. The object identifiers digestAlgorithm and 1043 encryptionAlgorithm identify the arcs from which certain algorithm 1044 OIDs referenced in this section are derived: 1046 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1047 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1049 B.1. Pseudorandom functions 1051 Examples of pseudorandom function for PBKDF2 (Section 5.2) include 1052 HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and 1053 SHA512/256. Applications may employ other schemes as well. 1055 B.1.1. HMAC-SHA-1 1057 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC 1058 message authentication code [RFC2104] based on the SHA-1 hash 1059 function [NIST180]. The pseudorandom function is the same function 1060 by which the message authentication code is computed, with a full- 1061 length output. (The first argument to the pseudorandom function PRF 1062 serves as HMAC's "key," and the second serves as HMAC's "text." In 1063 the case of PBKDF2, the "key" is thus the password and the "text" is 1064 the salt.) HMAC-SHA-1 has a variable key length and a 20-octet 1065 (160-bit) output value. 1067 Although the length of the key to HMAC-SHA-1 is essentially 1068 unbounded, the effective search space for pseudorandom function 1069 outputs may be limited by the structure of the function. In 1070 particular, when the key is longer than 512 bits, HMAC-SHA-1 will 1071 first hash it to 160 bits. Thus, even if a long derived key 1072 consisting of several pseudorandom function outputs is produced from 1073 a key, the effective search space for the derived key will be at most 1074 160 bits. Although the specific limitation for other key sizes 1075 depends on details of the HMAC construction, one should assume, to be 1076 conservative, that the effective search space is limited to 160 bits 1077 for other key sizes as well. 1079 (The 160-bit limitation should not generally pose a practical 1080 limitation in the case of password-based cryptography, since the 1081 search space for a password is unlikely to be greater than 160 bits.) 1083 The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1 1084 pseudorandom function: 1086 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1088 The parameters field associated with this OID in an 1089 AlgorithmIdentifier shall have type NULL. This object identifier is 1090 employed in the object set PBKDF2-PRFs (Appendix A.2). 1092 Note. Although HMAC-SHA-1 was designed as a message authentication 1093 code, its proof of security is readily modified to accommodate 1094 requirements for a pseudorandom function, under stronger assumptions. 1095 A hash function may also meet the requirements of a pseudorandom 1096 function under certain assumptions. For instance, the direct 1097 application of a hash function to to the concatenation of the "key" 1098 and the "text" may be appropriate, provided that "text" has 1099 appropriate structure to prevent certain attacks. HMAC-SHA-1 is 1100 preferable, however, because it treats "key" and "text" as separate 1101 arguments and does not require "text" to have any structure. 1103 During 2004 and 2005 there were a number of attacks on SHA-1 that 1104 reduced its perceived effective strength against collision attacks to 1105 62 bits instead of the expected 80 bits (e.g. Wang et al. [WANG], 1106 confirmed by M. Cochran [COCHRAN]). However, since these attacks 1107 centered on finding collisions between values they are not a direct 1108 security consideration here because the collision-resistant property 1109 is not required by the HMAC authentication scheme. 1111 B.1.2. HMAC-SHA-2 1113 HMAC-SHA-2 refers to the set of pseudo-random functions corresponding 1114 to the HMAC message authentication code (now a FIPS standard 1115 [NIST198]) based on the new SHA-2 functions (FIPS 180-4 [NIST180]). 1116 HMAC-SHA-2 has a variable key length and variable output value 1117 depending on the hash function chosen (SHA-224, SHA-256, SHA-384, 1118 SHA-512, SHA -512/224, or SHA-512/256), that is 28, 32, 48, or 64 1119 octets. 1121 Using the new hash functions extends the search space for the 1122 produced keys. Where SHA-1 limits the search space to 20 octets, 1123 SHA-2 sets new limits of 28, 32, 48 and 64 octets. 1125 Object identifiers for HMAC are defined as follows: 1127 id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} 1128 id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} 1129 id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} 1130 id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} 1131 id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} 1132 id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} 1134 B.2. Encryption Schemes 1136 An example encryption scheme for PBES2 (Section 6.2) is AES-CBC-Pad. 1137 The schemes defined in PKCS #5 v2.0 [RFC2898], DES-CBC-Pad, DES-EDE3- 1138 CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad, are still supported, but 1139 DES-CBC-Pad, DES-EDE3-CBC-Pad, RC2-CBC-Pad are now considered legacy 1140 and should only be used for backwards compatibility reasons. 1142 The object identifiers given in this section are intended to be 1143 employed in the object set PBES2-Encs (Appendix A.4). 1145 B.2.1. DES-CBC-Pad 1147 DES-CBC-Pad is single-key DES [NIST46] in CBC mode [NIST81] with the 1148 RFC 1423 [RFC1423] padding operation (see Section 6.1.1). DES-CBC-Pad 1149 has an eight- octet encryption key and an eight-octet initialization 1150 vector. The key is considered as a 64-bit encoding of a 56-bit DES 1151 key with parity bits ignored. 1153 The object identifier desCBC (defined in the NIST/OSI Implementors' 1154 Workshop agreements) identifies the DES-CBC-Pad encryption scheme: 1156 desCBC OBJECT IDENTIFIER ::= 1157 {iso(1) identified-organization(3) oiw(14) secsig(3) 1158 algorithms(2) 7} 1160 The parameters field associated with this OID in an 1161 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1162 specifying the initialization vector for CBC mode. 1164 B.2.2. DES-EDE3-CBC-Pad 1166 DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [ANSIX952] with 1167 the RFC 1423 [RFC1423] padding operation. DES-EDE3-CBC-Pad has a 1168 24-octet encryption key and an eight-octet initialization vector. The 1169 key is considered as the concatenation of three eight-octet keys, 1170 each of which is a 64-bit encoding of a 56-bit DES key with parity 1171 bits ignored. 1173 The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad 1174 encryption scheme: 1176 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1178 The parameters field associated with this OID in an 1179 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1180 specifying the initialization vector for CBC mode. 1182 Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 1183 [ANSIX952]; the one given here is preferred since it specifies 1184 padding. 1186 B.2.3. RC2-CBC-Pad 1188 RC2-CBC-Pad is the RC2(tm) encryption algorithm [RFC2268] in CBC mode 1189 with the RFC 1423 [RFC1423] padding operation. RC2-CBC-Pad has a 1190 variable key length, from one to 128 octets, a separate "effective 1191 key bits" parameter from one to 1024 bits that limits the effective 1192 search space independent of the key length, and an eight-octet 1193 initialization vector. 1195 The object identifier rc2CBC identifies the RC2-CBC-Pad encryption 1196 scheme: 1198 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1200 The parameters field associated with OID in an AlgorithmIdentifier 1201 shall have type RC2-CBC-Parameter: 1203 RC2-CBC-Parameter ::= SEQUENCE { 1204 rc2ParameterVersion INTEGER OPTIONAL, 1205 iv OCTET STRING (SIZE(8)) } 1207 The fields of type RC2-CBCParameter have the following meanings: 1209 - rc2ParameterVersion is a proprietary RSA Security Inc. encoding 1210 of the "effective key bits" for RC2. The following encodings 1211 are defined: 1213 Effective Key Bits Encoding 1214 40 160 1215 64 120 1216 128 58 1217 b >= 256 b 1219 If the rc2ParameterVersion field is omitted, the "effective key bits" 1220 defaults to 32. (This is for backward compatibility with certain very 1221 old implementations.) 1223 - iv is the eight-octet initialization vector. 1225 B.2.4. RC5-CBC-Pad 1227 RC5-CBC-Pad is the RC5(tm) encryption algorithm [RC5] in CBC mode 1228 with RFC 5652 [RFC5652] padding operation, which is a generalization 1229 of the RFC 1423 [RFC1423] padding operation. The scheme is fully 1230 specified in [RFC2040]. RC5-CBC-Pad has a variable key length, from 0 1231 to 256 octets, and supports both a 64-bit block size and a 128-bit 1232 block size. For the former, it has an eight-octet initialization 1233 vector, and for the latter, a 16-octet initialization vector. 1234 RC5-CBC-Pad also has a variable number of "rounds" in the encryption 1235 operation, from 8 to 127. 1237 Note: For RC5 with a 64-bit block size, the padding string is as 1238 defined in RFC 1423 [RFC1423]. For RC5 with a 128-bit block size, the 1239 padding string consists of 16-(||M|| mod 16) octets each with value 1240 16-(||M|| mod 16). 1242 The object identifier rc5-CBC-PAD [RFC2040] identifies RC5-CBC-Pad 1243 encryption scheme: 1245 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1247 The parameters field associated with this OID in an 1248 AlgorithmIdentifier shall have type RC5-CBC-Parameters: 1250 RC5-CBC-Parameters ::= SEQUENCE { 1251 version INTEGER {v1-0(16)} (v1-0), 1252 rounds INTEGER (8..127), 1253 blockSizeInBits INTEGER (64 | 128), 1254 iv OCTET STRING OPTIONAL } 1256 The fields of type RC5-CBC-Parameters have the following meanings: 1258 - version is the version of the algorithm, which shall be v1-0. 1260 - rounds is the number of rounds in the encryption operation, 1261 which shall be between 8 and 127. 1263 - blockSizeInBits is the block size in bits, which shall be 64 or 1264 128. 1266 - iv is the initialization vector, an eight-octet string for 1267 64-bit RC5 and a 16-octet string for 128-bit RC5. The default 1268 is a string of the appropriate length consisting of zero 1269 octets. 1271 B.2.5. AES-CBC-Pad 1273 AES-CBC-Pad is the AES encryption algorithm [NIST197] in CBC mode 1274 with RFC 5652 [RFC5652] padding operation. AES-CBC-Pad has a variable 1275 key length of 16, 24, or 32 octets and has a 16-octet block size. It 1276 has a 16-octet initialization vector. 1278 Note: For AES, the padding string consists of 16-(||M|| mod 16) 1279 octets each with value 16-(||M|| mod 16). 1281 For AES, object identifiers are defined depending on key size and 1282 operation mode. For example, the 16-octet (128 bit) key AES 1283 encryption scheme in CBC mode would be aes128-CBC-Pad identifying the 1284 AES-CBC-PAD encryption scheme using a 16-octet key: 1286 aes128-CBC-PAD OBJECT IDENTIFIER ::= {aes 2} 1288 The AES object identifier is defined in Appendix C. 1290 The parameters field associated with this OID in an 1291 AlgorithmIdentifier shall have type OCTET STRING (SIZE(16)), 1292 specifying the initialization vector for CBC mode. 1294 B.3. Message Authentication Schemes 1296 An example message authentication scheme for PBMAC1 (Section 7.1) is 1297 HMAC-SHA-1. 1299 B.3.1. HMAC-SHA-1 1301 HMAC-SHA-1 is the HMAC message authentication scheme [RFC2104] based 1302 on the SHA-1 hash function [NIST180]. HMAC-SHA-1 has a variable key 1303 length and a 20-octet (160-bit) message authentication code. 1305 The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies 1306 the HMAC-SHA-1 message authentication scheme. (The object identifier 1307 is the same for both the pseudorandom function and the message 1308 authentication scheme; the distinction is to be understood by 1309 context.) This object identifier is intended to be employed in the 1310 object set PBMAC1-Macs (Appendix A.5). 1312 B.3.2. HMAC-SHA-2 1314 HMAC-SHA-2 refers to the set of HMAC message authentication schemes 1315 [NIST198] based on the SHA-2 functions [NIST180]. HMAC-SHA-2 has a 1316 variable key length and a message authentication code whose length 1317 is based on the hash function chosen (SHA-224, SHA-256, SHA-384, 1318 SHA-512, SHA-512/224, or SHA-512/256giving 28, 32, 48 or 64 octets). 1320 The object identifiers id-hmacWithSHA224, id-hmacWithSHA256, id- 1321 hmacWithSHA384, id-hmacWithSHA512, id-hmacWithSHA512-224,and id- 1322 hmacWithSHA512-256 (see Appendix B.1.2) identify the HMAC-SHA-2 1323 schemes. The object identifiers are the same for both the 1324 pseudo-random functions and the message authentication schemes; the 1325 distinction is to be understood by context. These object identifiers 1326 are intended to be employed in the object set PBMAC1-Macs (Appendix 1327 A.5) 1329 C. ASN.1 Module 1331 For reference purposes, the ASN.1 syntax in the preceding sections is 1332 presented as an ASN.1 module here. 1334 -- PKCS #5 v2.1 ASN.1 Module 1335 -- Revised October 27, 2012 1337 -- This module has been checked for conformance with the 1338 -- ASN.1 standard by the OSS ASN.1 Tools 1340 PKCS5v2-1 { 1341 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 1342 modules(16) pkcs5v2-1(2) 1343 } 1345 DEFINITIONS EXPLICIT TAGS ::= 1347 BEGIN 1349 -- ======================== 1350 -- Basic object identifiers 1351 -- ======================== 1353 nistAlgorithms OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) country(16) 1354 us(840) organization(1) 1355 gov(101) csor(3) 4} 1356 oiw OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) 14} 1357 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 1358 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 1359 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 1361 -- ======================= 1362 -- Basic types and classes 1363 -- ======================= 1365 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= 1366 SEQUENCE { 1367 algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), 1368 parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} 1369 {@algorithm}) OPTIONAL 1370 } 1372 ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER 1374 -- ====== 1375 -- PBKDF2 1376 -- ====== 1378 PBKDF2Algorithms ALGORITHM-IDENTIFIER ::= { 1379 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1380 ... 1381 } 1383 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 1385 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 1386 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 1388 PBKDF2-params ::= SEQUENCE { 1389 salt CHOICE { 1390 specified OCTET STRING, 1391 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 1392 }, 1393 iterationCount INTEGER (1..MAX), 1394 keyLength INTEGER (1..MAX) OPTIONAL, 1395 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 1396 algid-hmacWithSHA1 1397 } 1399 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 1401 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { 1402 {NULL IDENTIFIED BY id-hmacWithSHA1}, 1403 {NULL IDENTIFIED BY id-hmacWithSHA224}, 1404 {NULL IDENTIFIED BY id-hmacWithSHA256}, 1405 {NULL IDENTIFIED BY id-hmacWithSHA384}, 1406 {NULL IDENTIFIED BY id-hmacWithSHA512}, 1407 {NULL IDENTIFIED BY id-hmacWithSHA512-224}, 1408 {NULL IDENTIFIED BY id-hmacWithSHA512-256}, 1409 ... 1410 } 1412 -- ===== 1413 -- PBES1 1414 -- ===== 1416 PBES1Algorithms ALGORITHM-IDENTIFIER ::= { 1417 {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} | 1418 {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} | 1419 {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} | 1420 {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} | 1421 {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} | 1422 {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC}, 1423 ... 1424 } 1426 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 1427 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 1428 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 1429 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 1430 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 1431 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 1433 PBEParameter ::= SEQUENCE { 1434 salt OCTET STRING (SIZE(8)), 1435 iterationCount INTEGER 1436 } 1438 -- ===== 1439 -- PBES2 1440 -- ===== 1442 PBES2Algorithms ALGORITHM-IDENTIFIER ::= { 1443 {PBES2-params IDENTIFIED BY id-PBES2}, 1444 ... 1445 } 1447 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 1449 PBES2-params ::= SEQUENCE { 1450 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 1451 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} 1452 } 1454 PBES2-KDFs ALGORITHM-IDENTIFIER ::= { 1455 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1456 ... 1457 } 1459 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1461 -- ====== 1462 -- PBMAC1 1463 -- ====== 1465 PBMAC1Algorithms ALGORITHM-IDENTIFIER ::= { 1466 {PBMAC1-params IDENTIFIED BY id-PBMAC1}, 1467 ... 1468 } 1470 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1472 PBMAC1-params ::= SEQUENCE { 1473 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1474 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} 1475 } 1477 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= { 1478 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1479 ... 1480 } 1482 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1484 -- ===================== 1485 -- Supporting techniques 1486 -- ===================== 1488 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1489 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1491 SupportingAlgorithms ALGORITHM-IDENTIFIER ::= { 1492 {NULL IDENTIFIED BY id-hmacWithSHA1} | 1493 {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} | 1494 {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} | 1495 {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} | 1496 {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}, | 1497 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes128-CBC-PAD} | 1498 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes192-CBC-PAD} | 1499 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes256-CBC-PAD}, 1500 ... 1501 } 1503 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1504 id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} 1505 id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} 1506 id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} 1507 id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} 1508 id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} 1509 id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} 1511 desCBC OBJECT IDENTIFIER ::= {oiw secsig(3) algorithms(2) 7} 1513 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1515 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1517 RC2-CBC-Parameter ::= SEQUENCE { 1518 rc2ParameterVersion INTEGER OPTIONAL, 1519 iv OCTET STRING (SIZE(8)) 1520 } 1522 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1524 RC5-CBC-Parameters ::= SEQUENCE { 1525 version INTEGER {v1-0(16)} (v1-0), 1526 rounds INTEGER (8..127), 1527 blockSizeInBits INTEGER (64 | 128), 1528 iv OCTET STRING OPTIONAL 1529 } 1531 aes OBJECT IDENTIFIER ::= { nistAlgorithms 1 } 1532 aes128-CBC-PAD OBJECT IDENTIFIER ::= { aes 2 } 1533 aes192-CBC-PAD OBJECT IDENTIFIER ::= { aes 22 } 1534 aes256-CBC-PAD OBJECT IDENTIFIER ::= { aes 42 } 1536 END 1538 D. Intellectual Property Considerations 1540 EMC Corporation makes no patent claims on the general constructions 1541 described in this document, although specific underlying techniques 1542 may be covered. Among the underlying techniques, the RC5 encryption 1543 algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 1544 [RBLOCK1] and 5,835,600 [RBLOCK2]. 1546 RC2 and RC5 are trademarks of EMC Corporation. 1548 EMC Corporation makes no representation regarding intellectual 1549 property claims by other parties. Such determination is the 1550 responsibility of the user. 1552 E. Revision History 1554 Versions 1.0-1.3 1556 Versions 1.0-1.3 were distributed to participants in RSA Data 1557 Security Inc.'s Public-Key Cryptography Standards meetings in 1558 February and March 1991. 1560 Version 1.4 1562 Version 1.4 was part of the June 3, 1991 initial public release of 1563 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1564 document SEC-SIG-91-20. 1566 Version 1.5 1568 Version 1.5 incorporated several editorial changes, including 1569 updates to the references and the addition of a revision history. 1571 Version 2.0 1573 Version 2.0 incorporates major editorial changes in terms of the 1574 document structure, and introduces the PBES2 encryption scheme, 1575 the PBMAC1 message authentication scheme, and independent 1576 password-based key derivation functions. This version continues to 1577 support the encryption process in version 1.5. 1579 Version 2.1 1581 This document transfers PKCS #5 into the IETF and includes some 1582 minor changes from the authors for this submission. 1584 o Introduces AES/CBC as an encryption scheme for PBES2 and HMAC 1585 with the hash functions SHA-224, SHA-256, SHA-384, SHA-512, 1586 SHA-512/224, and SHA512/256 as pseudo-random functions for PBKDF2 1587 and message authentication schemes for PBMAC1. 1589 o Replacement of RSA with EMC in the "Intellectual Property 1590 Considerations". 1592 o Changes references to PKCS #5 and PKCS #8 to RSA 2898 and RFC 1593 5208/5898. 1595 o Incorporates two editorial errata reported on PKCS #5 [RFC2898]. 1597 o Added security considerations for MD2, MD5, and SHA-1. 1599 F. References 1601 F.1 Normative References 1603 [ANSIX952] 1604 American National Standard X9.52 - 1998, Triple Data Encryption 1605 Algorithm Modes of Operation. Working draft, Accredited 1606 Standards Committee X9, July 27, 1998. 1608 [BELLOV] 1609 S.M. Bellovin and M. Merritt. Encrypted key exchange: Password- 1610 based protocols secure against dictionary attacks. In 1611 Proceedings of the 1992 IEEE Computer Society Conference on 1612 Research in Security and Privacy, pages 72-84, IEEE Computer 1613 Society, 1992. 1615 [COCHRAN] 1616 M. Cochran. Notes on the Wang et al. 2^63 SHA-1 Differential 1617 Path. International Association for Cryptologic Research, ePrint 1618 Archive. August 2008. Available from 1619 1621 [ISO8824-1] 1622 ISO/IEC 8824-1: 2008: Information technology - Abstract Syntax 1623 Notation One (ASN.1) - Specification of basic notation. 2008. 1625 [ISO8824-2] 1626 ISO/IEC 8824-2: 2008: Information technology - Abstract Syntax 1627 Notation One (ASN.1) - Information object specification. 2008. 1629 [ISO8824-3] 1630 ISO/IEC 8824-3: 2008: Information technology - Abstract Syntax 1631 Notation One (ASN.1) - Constraint specification. 2008. 1633 [ISO8824-4] 1634 ISO/IEC 8824-4: 2008: Information technology - Abstract Syntax 1635 Notation One (ASN.1) - Parameterization of ASN.1 specifications. 1636 2008. 1638 [JABLON] 1639 D. Jablon. Strong password-only authenticated key exchange. ACM 1640 Computer Communications Review, October 1996. 1642 [MORRIS] 1643 Robert Morris and Ken Thompson. Password security: A case 1644 history. Communications of the ACM, 22(11):594-597, November 1645 1979. 1647 [NIST46] 1648 National Institute of Standards and Technology (NIST). FIPS PUB 1649 46-3: Data Encryption Standard. October 1999. 1651 [NIST81] 1652 National Institute of Standards and Technology (NIST). FIPS PUB 1653 81: DES Modes of Operation. December 2, 1980. 1655 [NIST180] 1656 National Institute of Standards and Technology (NIST). FIPS PUB 1657 180-4: Secure Hash Standard. March 2012. 1659 [NIST197] 1660 National Institute of Standards and Technology (NIST). FIPS PUB 1661 197: Advance Encryption Standard (AES). November 2001. 1663 [NIST198] 1664 National Institute of Standards and Technology (NIST). FIPS 1665 Publication 198-1: The Keyed - Hash Message Authentication Code 1666 (HMAC). July 2008. 1668 [NISTSP63] 1669 National Institute of Standards and Technology (NIST). Special 1670 Publication 800-63-2: Electronic Authentication Guideline, 1671 Appendix A. August 2013. 1673 [NISTSP132] 1674 National Institute of Standards and Technology (NIST). Special 1675 Publication 800-132: Recommendation for Password - Based Key 1676 Derivation, Part 1: Storage Applications. December 2010. 1678 [PKCS5_15] 1679 RSA Laboratories. PKCS #5: Password-Based Encryption Standard 1680 Version 1.5, November 1993. 1682 [PKCS5_21] 1683 RSA Laboratories. PKCS #5: Password-Based Encryption Standard 1684 Version 2.1, October 2012. 1686 [PKCS8] 1687 RSA Laboratories. "PKCS #8: Private-Key Information Syntax 1688 Standard Version 1.2", RFC 5208, May 2008. 1690 [RBLOCK1] 1691 R.L. Rivest. Block-Encryption Algorithm with Data-Dependent 1692 Rotations. U.S. Patent No. 5,724,428, March 3, 1998. 1694 [RBLOCK2] 1695 R.L. Rivest. Block Encryption Algorithm with Data-Dependent 1696 Rotations. U.S. Patent No. 5,835,600, November 10, 1998. 1698 [RC5] 1699 R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the 1700 Second International Workshop on Fast Software Encryption, pages 1701 86-96, Springer-Verlag, 1994. 1703 [RFC1319] 1704 Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1705 1992, 1706 . 1708 [RFC1321] 1709 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1710 1992, 1711 . 1713 [RFC1423] 1714 Balenson, D., "Privacy Enhancement for Internet Electronic Mail: 1715 Part III: Algorithms, Modes, and Identifiers", RFC 1423, 1716 February 1993, 1717 . 1719 [RFC2040] 1720 Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 1721 RC5-CTS Algorithms", RFC 2040, October 1996, 1722 . 1724 [RFC2104] 1725 Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1726 for Message Authentication", RFC 2104, February 1997, 1727 . 1729 [RFC2268] 1730 Rivest, R., "A Description of the RC2(r) Encryption Algorithm", 1731 RFC 2268, March 1998, 1732 . 1734 [RFC2279] 1735 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1736 2279, January 1998, 1737 . 1739 [RFC2898] 1740 B. Kaliski., "PKCS #5: Password-Based Encryption Standard 1741 Version 2.0", RFC 2898, September 2000, 1742 . 1744 [RFC5652] 1745 R. Housley. RFC 5652: Cryptographic Message Syntax. IETF, 1746 September 2009, 1747 . 1749 [RFC5958] 1750 Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010, 1751 . 1753 [RFC6149] 1754 Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, 1755 March 2011, 1756 . 1758 [RFC6151] 1759 Turner, S. and L. Chen, "Updated Security Considerations for the 1760 MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 1761 2011, 1762 . 1764 [RFC6194] 1765 Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 1766 Considerations for the SHA-0 and SHA-1 Message-Digest 1767 Algorithms", RFC 6194, March 2011, 1768 . 1770 [WANG] 1771 X. Wang, A.C. Yao, and F. Yao. Cryptanalysis on SHA-1. 1772 Presented by Adi Shamir at the rump session of CRYPTO 2005. 1773 Slides may be found currently at 1774 1777 [WU] 1778 T. Wu. The Secure Remote Password protocol. In Proceedings of 1779 the 1998 Internet Society Network and Distributed System 1780 Security Symposium, pages 97-111, Internet Society, 1998. 1782 G. About PKCS 1784 The Public-Key Cryptography Standards are specifications produced by 1785 RSA Laboratories in cooperation with secure systems developers 1786 worldwide for the purpose of accelerating the deployment of public- 1787 key cryptography. First published in 1991 as a result of meetings 1788 with a small group of early adopters of public-key technology, the 1789 PKCS documents have become widely referenced and implemented. 1790 Contributions from the PKCS series have become part of many formal 1791 and de facto standards, including ANSI X9 documents, PKIX, SET, 1792 S/MIME, and SSL. 1794 Further development of most PKCS documents occurs through the IETF. 1795 Suggestions for improvement are welcome. 1797 H. Acknowledgements 1799 This document is based on a contribution of RSA Laboratories, the 1800 research center of RSA Security Inc. 1802 Authors' Addresses 1804 Kathleen M. Moriarty (editor) 1805 EMC Corporation 1806 176 South Street 1807 Hopkinton, MA 01748 1808 US 1810 Email: kathleen.moriarty@emc.com 1812 Burt Kaliski 1813 Verisign 1814 12061 Bluemont Way 1815 Reston, VA 20190 1816 US 1818 Email: bkaliski@verisign.com 1819 URI: http://verisignlabs.com 1821 Andreas Rusch 1822 RSA 1823 345 Queen Street 1824 Brisbane, QLD 4000 1825 AU 1827 Email: andreas.rusch@rsa.com