idnits 2.17.00 (12 Aug 2021) /tmp/idnits30922/draft-moriarty-pkcs5-v2dot1-00.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 1860 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 867: '... keyLength INTEGER (1..MAX) OPTIONAL,...' RFC 2119 keyword, line 1196: '... rc2ParameterVersion INTEGER OPTIONAL,...' RFC 2119 keyword, line 1246: '... iv OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 1361: '... {@algorithm}) OPTIONAL...' RFC 2119 keyword, line 1386: '... 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...' == (10 more instances...) -- The document date (February 3, 2016) is 2298 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? '29' on line 1693 looks like a reference -- Missing reference section? '33' on line 1709 looks like a reference -- Missing reference section? '4' on line 1606 looks like a reference -- Missing reference section? '11' on line 1633 looks like a reference -- Missing reference section? '31' on line 1702 looks like a reference -- Missing reference section? '28' on line 1690 looks like a reference -- Missing reference section? '14' on line 1642 looks like a reference -- Missing reference section? '32' on line 1706 looks like a reference -- Missing reference section? '20' on line 1663 looks like a reference -- Missing reference section? '21' on line 1667 looks like a reference -- Missing reference section? '12' on line 1636 looks like a reference -- Missing reference section? '22' on line 1671 looks like a reference -- Missing reference section? '17' on line 1652 looks like a reference -- Missing reference section? '27' on line 1687 looks like a reference -- Missing reference section? '15' on line 1646 looks like a reference -- Missing reference section? '24' on line 1678 looks like a reference -- Missing reference section? '16' on line 1649 looks like a reference -- Missing reference section? '3' on line 1602 looks like a reference -- Missing reference section? '34' on line 1711 looks like a reference -- Missing reference section? '35' on line 1714 looks like a reference -- Missing reference section? '36' on line 1718 looks like a reference -- Missing reference section? '7' on line 1620 looks like a reference -- Missing reference section? '8' on line 1623 looks like a reference -- Missing reference section? '9' on line 1626 looks like a reference -- Missing reference section? '10' on line 1629 looks like a reference -- Missing reference section? '13' on line 1639 looks like a reference -- Missing reference section? '30' on line 1696 looks like a reference -- Missing reference section? '5' on line 1612 looks like a reference -- Missing reference section? '19' on line 1659 looks like a reference -- Missing reference section? '1' on line 1595 looks like a reference -- Missing reference section? '23' on line 1674 looks like a reference -- Missing reference section? '6' on line 1617 looks like a reference -- Missing reference section? '2' on line 1599 looks like a reference -- Missing reference section? '18' on line 1655 looks like a reference -- Missing reference section? '25' on line 1681 looks like a reference -- Missing reference section? '26' on line 1684 looks like a reference Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 39 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) A. Rusch 4 Expires: August 6, 2016 RSA 5 B. Kaliski 6 Verisign 7 February 3, 2016 9 PKCS #5: Password-Based Cryptography Specification 10 Version 2.1 11 draft-moriarty-pkcs5-v2dot1-00 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 [29][33]. 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 [4][11][31] are outside the scope of this document. Guidelines for 145 the selection of passwords are also outside the scope. This document 146 supersedes PKCS #5 version 2.0 [28], but includes compatible 147 techniques. 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 [14] for the protection of password tables, is to 215 combine a password with a salt to produce a key. The salt can be 216 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 [32] are two possibilities. (ASCII is a subset of 266 UTF-8.) 268 Although the selection of passwords is outside the scope of this 269 document, guidelines have been published [20] that may well be taken 270 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 [21], which says "The iteration count 380 shall be selected as large as possible, as long as the time required 381 to generate the key using the entered password is acceptable for the 382 users. [...] A minimum iteration count of 1,000 is recommended. For 383 especially critical keys, or for very powerful systems or systems 384 where user-perceived performance is not critical, an iteration count 385 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 [12], MD5 [22] or 425 SHA-1 [17], to derive keys. The length of the derived key is bounded 426 by the length of the hash function output, which is 16 octets for MD2 427 and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key 428 derivation process in PKCS #5 v1.5 [27]. 430 PBKDF1 is recommended only for compatibility with existing 431 applications since the keys it produces may not be large enough for 432 some applications. 434 PBKDF1 (P, S, c, dkLen) 436 Options: Hash underlying hash function 438 Input: P password, an octet string 439 S salt, an eight-octet string 440 c iteration count, a positive integer 441 dkLen intended length in octets of derived key, 442 a positive integer, at most 16 for MD2 or 443 MD5 and 20 for SHA-1 444 Output: DK derived key, a dkLen-octet string 446 Steps: 448 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output 449 "derived key too long" and stop. 451 2. Apply the underlying hash function Hash for c iterations to the 452 concatenation of the password P and the salt S, then extract 453 the first dkLen octets to produce a derived key DK: 455 T_1 = Hash (P || S) , 456 T_2 = Hash (T_1) , 457 ... 458 T_c = Hash (T_{c-1}) , 459 DK = Tc<0..dkLen-1> 461 3. Output the derived key DK. 463 5.2. PBKDFs 465 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an 466 example) to derive keys. The length of the derived key is essentially 467 unbounded. (However, the maximum effective search space for the 468 derived key may be limited by the structure of the underlying 469 pseudorandom function. See Appendix B.1 for further discussion.) 470 PBKDF2 is recommended for new applications. 472 PBKDF2 (P, S, c, dkLen) 474 Options: PRF underlying pseudorandom function (hLen 475 denotes the length in octets of the 476 pseudorandom function output) 478 Input: P password, an octet string 479 S salt, an octet string 480 c iteration count, a positive integer 481 dkLen intended length in octets of the derived 482 key, a positive integer, at most 483 (2^32 - 1) * hLen 485 Output: DK derived key, a dkLen-octet string 487 Steps: 489 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" and 490 stop. 492 2. Let l be the number of hLen-octet blocks in the derived key, 493 rounding up, and let r be the number of octets in the last 494 block: 496 l = CEIL (dkLen / hLen) , 497 r = dkLen - (l - 1) * hLen . 499 Here, CEIL (x) is the "ceiling" function, i.e. the smallest 500 integer greater than, or equal to, x. 502 3. For each block of the derived key apply the function F defined 503 below to the password P, the salt S, the iteration count c, and 504 the block index to compute the block: 506 T_1 = F (P, S, c, 1) , 507 T_2 = F (P, S, c, 2) , 508 ... 509 T_l = F (P, S, c, l) , 511 where the function F is defined as the exclusive-or sum of the 512 first c iterates of the underlying pseudorandom function PRF 513 applied to the password P and the concatenation of the salt S 514 and the block index i: 516 where 517 U_1 = PRF (P, S || INT (i)) , 518 U_2 = PRF (P, U_1) , 519 ... 520 U_c = PRF (P, U_{c-1}) . 522 Here, INT (i) is a four-octet encoding of the integer i, most 523 significant octet first. 525 4. Concatenate the blocks and extract the first dkLen octets to 526 produce a derived key DK: 528 DK = T_1 || T_2 || ... || T_l<0..r-1> 530 5. Output the derived key DK. 532 Note. The construction of the function F follows a "belt-and- 533 suspenders" approach. The iterates U_i are computed recursively to 534 remove a degree of parallelism from an opponent; they are exclusive- 535 ored together to reduce concerns about the recursion degenerating 536 into a small set of values. 538 6. Encryption Schemes 540 An encryption scheme, in the symmetric setting, consists of an 541 encryption operation and a decryption operation, where the encryption 542 operation produces a ciphertext from a message under a key, and the 543 decryption operation recovers the message from the ciphertext under 544 the same key. In a password-based encryption scheme, the key is a 545 password. 547 A typical application of a password-based encryption scheme is a 548 private-key protection method, where the message contains private-key 549 information, as in PKCS #8. The encryption schemes defined here would 550 be suitable encryption algorithms in that context. 552 Two schemes are specified in this section: PBES1 and PBES2. PBES2 is 553 recommended for new applications; PBES1 is included only for 554 compatibility with existing applications, and is not recommended for 555 new applications. 557 6.1. PBES1 559 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying 560 block cipher, which shall be either DES [15] or RC2(tm) [24] in CBC 561 mode [16]. PBES1 is compatible with the encryption scheme in PKCS #5 562 v1.5 [27]. 564 PBES1 is recommended only for compatibility with existing 565 applications, since it supports only two underlying encryption 566 schemes, each of which has a key size (56 or 64 bits) that may not be 567 large enough for some applications. 569 6.1.1. PBES Encryption Operation 571 The encryption operation for PBES1 consists of the following steps, 572 which encrypt a message M under a password P to produce a ciphertext 573 C: 575 1. Select an eight-octet salt S and an iteration count c, as 576 outlined in Section 4. 578 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 579 password P, the salt S, and the iteration count c to produce at 580 derived key DK of length 16 octets: 582 DK = PBKDF1 (P, S, c, 16) . 584 3. Separate the derived key DK into an encryption key K consisting 585 of the first eight octets of DK and an initialization vector IV 586 consisting of the next eight octets: 588 K = DK<0..7> , 589 IV = DK<8..15> . 591 4. Concatenate M and a padding string PS to form an encoded 592 message EM: 594 EM = M || PS , 596 where the padding string PS consists of 8-(||M|| mod 8) octets 597 each with value 8-(||M|| mod 8). The padding string PS will 598 satisfy one of the following statements: 600 PS = 01, if ||M|| mod 8 = 7 ; 601 PS = 02 02, if ||M|| mod 8 = 6 ; 602 ... 603 PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0. 605 The length in octets of the encoded message will be a multiple 606 of eight and it will be possible to recover the message M 607 unambiguously from the encoded message. (This padding rule is 608 taken from RFC 1423 [3].) 610 5. Encrypt the encoded message EM with the underlying block cipher 611 (DES or RC2) in cipher block chaining mode under the encryption 612 key K with initialization vector IV to produce the ciphertext 613 C. For DES, the key K shall be considered as a 64-bit encoding 614 of a 56-bit DES key with parity bits ignored (see [15]). For 615 RC2, the "effective key bits" shall be 64 bits. 617 6. Output the ciphertext C. 619 The salt S and the iteration count c may be conveyed to the party 620 performing decryption in an AlgorithmIdentifier value (see Appendix 621 A.3). 623 6.1.2. PBES1 Decryption Operation 625 The decryption operation for PBES1 consists of the following steps, 626 which decrypt a ciphertext C under a password P to recover a message 627 M: 629 1. Obtain the eight-octet salt S and the iteration count c. 631 2. Apply the PBKDF1 key derivation function (Section 5.1) to the 632 password P, the salt S, and the iteration count c to produce a 633 derived key DK of length 16 octets: 635 DK = PBKDF1 (P, S, c, 16) 637 3. Separate the derived key DK into an encryption key K consisting 638 of the first eight octets of DK and an initialization vector IV 639 consisting of the next eight octets: 641 K = DK<0..7> , 642 IV = DK<8..15> . 644 4. Decrypt the ciphertext C with the underlying block cipher (DES 645 or RC2) in cipher block chaining mode under the encryption key 646 K with initialization vector IV to recover an encoded message 647 EM. If the length in octets of the ciphertext C is not a 648 multiple of eight, output "decryption error" and stop. 650 5. Separate the encoded message EM into a message M and a padding 651 string PS: 653 EM = M || PS , 655 where the padding string PS consists of some number psLen 656 octets each with value psLen, where psLen is between 1 and 8. 657 If it is not possible to separate the encoded message EM in 658 this manner, output "decryption error" and stop. 660 6. Output the recovered message M. 662 6.2. PBES2 664 PBES2 combines a password-based key derivation function, which shall 665 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 666 underlying encryption scheme (see Appendix B.2 for examples). The key 667 length and any other parameters for the underlying encryption scheme 668 depend on the scheme. 670 PBES2 is recommended for new applications. 672 6.2.1. PBES2 Encryption Operation 674 The encryption operation for PBES2 consists of the following steps, 675 which encrypt a message M under a password P to produce a ciphertext 676 C, applying a selected key derivation function KDF and a selected 677 underlying encryption scheme: 679 1. Select a salt S and an iteration count c, as outlined in 680 Section 4. 682 2. Select the length in octets, dkLen, for the derived key for the 683 underlying encryption scheme. 685 3. Apply the selected key derivation function to the password P, 686 the salt S, and the iteration count c to produce a derived key 687 DK of length dkLen octets: 689 DK = KDF (P, S, c, dkLen) . 691 4. Encrypt the message M with the underlying encryption scheme 692 under the derived key DK to produce a ciphertext C. (This step 693 may involve selection of parameters such as an initialization 694 vector and padding, depending on the underlying scheme.) 696 5. Output the ciphertext C. 698 The salt S, the iteration count c, the key length dkLen, and 699 identifiers for the key derivation function and the underlying 700 encryption scheme may be conveyed to the party performing decryption 701 in an AlgorithmIdentifier value (see Appendix A.4). 703 6.2.2. PBES2 Decryption Operation 705 The decryption operation for PBES2 consists of the following steps, 706 which decrypt a ciphertext C under a password P to recover a message 707 M: 709 1. Obtain the salt S for the operation. 711 2. Obtain the iteration count c for the key derivation function. 713 3. Obtain the key length in octets, dkLen, for the derived key for 714 the underlying encryption scheme. 716 4. Apply the selected key derivation function to the password P, 717 the salt S, and the iteration count c to produce a derived key 718 DK of length dkLen octets: 720 DK = KDF (P, S, c, dkLen) . 722 5. Decrypt the ciphertext C with the underlying encryption scheme 723 under the derived key DK to recover a message M. If the 724 decryption function outputs "decryption error," then output 725 "decryption error" and stop. 727 6. Output the recovered message M. 729 7. Message Authentication Schemes 731 A message authentication scheme consists of a MAC (message 732 authentication code) generation operation and a MAC verification 733 operation, where the MAC generation operation produces a message 734 authentication code from a message under a key, and the MAC 735 verification operation verifies the message authentication code under 736 the same key. In a password-based message authentication scheme, the 737 key is a password. 739 One scheme is specified in this section: PBMAC1. 741 7.1. PBMAC1 743 PBMAC1 combines a password-based key derivation function, which shall 744 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an 745 underlying message authentication scheme (see Appendix B.3 for an 746 example). The key length and any other parameters for the underlying 747 message authentication scheme depend on the scheme. 749 7.1.1 PBMAC1 Generation Operation 751 The MAC generation operation for PBMAC1 consists of the following 752 steps, which process a message M under a password P to generate a 753 message authentication code T, applying a selected key derivation 754 function KDF and a selected underlying message authentication scheme: 756 1. Select a salt S and an iteration count c, as outlined in 757 Section 4. 759 2. Select a key length in octets, dkLen, for the derived key for 760 the underlying message authentication function. 762 3. Apply the selected key derivation function to the password P, 763 the salt S, and the iteration count c to produce a derived key 764 DK of length dkLen octets: 766 DK = KDF (P, S, c, dkLen) . 768 4. Process the message M with the underlying message 769 authentication scheme under the derived key DK to generate a 770 message authentication code T. 772 5. Output the message authentication code T. 774 The salt S, the iteration count c, the key length dkLen, and 775 identifiers for the key derivation function and underlying message 776 authentication scheme may be conveyed to the party performing 777 verification in an AlgorithmIdentifier value (see Appendix A.5). 779 7.1.2. PBMAC1 Verification Operation 781 The MAC verification operation for PBMAC1 consists of the following 782 steps, which process a message M under a password P to verify a 783 message authentication code T: 785 1. Obtain the salt S and the iteration count c. 787 2. Obtain the key length in octets, dkLen, for the derived key for 788 the underlying message authentication scheme. 790 3. Apply the selected key derivation function to the password P, 791 the salt S, and the iteration count c to produce a derived key 792 DK of length dkLen octets: 794 DK = KDF (P, S, c, dkLen) . 796 4. Process the message M with the underlying message 797 authentication scheme under the derived key DK to verify the 798 message authentication code T. 800 5. If the message authentication code verifies, output "correct"; 801 else output "incorrect." 803 8. Security Considerations 805 Password-based cryptography is generally limited in the security that 806 it can provide, particularly for methods such as those defined in 807 this document where off-line password search is possible. While the 808 use of salt and iteration count can increase the complexity of attack 809 (see Section 4 for recommendations), it is essential that passwords 810 are selected well, and relevant guidelines (e.g., [20]) should be 811 taken into account. It is also important that passwords be protected 812 well if stored. 814 In general, different keys should be derived from a password for 815 different uses to minimize the possibility of unintended 816 interactions. For password-based encryption with a single algorithm, 817 a random salt is sufficient to ensure that different keys will be 818 produced. In certain other situations, as outlined in Section 4, a 819 structured salt is necessary. The recommendations in Section 4 should 820 thus be taken into account when selecting the salt value. 822 For information on security considerations for MD2 [12] see [34], for 823 MD5 [22] see [35], for SHA-1 [17] see [36]. 825 9. IANA Considerations 827 None. 829 A. ASN.1 Syntax 831 This section defines ASN.1 syntax for the key derivation functions, 832 the encryption schemes, the message authentication scheme, and 833 supporting techniques. The intended application of these definitions 834 includes PKCS #8 and other syntax for key management, encrypted data, 835 and integrity-protected data. (Various aspects of ASN.1 are specified 836 in several ISO/IEC standards [7][8][9][10].) 838 The object identifier pkcs-5 identifies the arc of the OID tree from 839 which the PKCS #5-specific OIDs in this section are derived: 841 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 842 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 843 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 845 A.1. PBKDF1 847 No object identifier is given for PBKDF1, as the object identifiers 848 for PBES1 are sufficient for existing applications and PBKDF2 is 849 recommended for new applications. 851 A.2. PBKDF2 853 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation 854 function (Section 5.2). 856 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 858 The parameters field associated with this OID in an 859 AlgorithmIdentifier shall have type PBKDF2-params: 861 PBKDF2-params ::= SEQUENCE { 862 salt CHOICE { 863 specified OCTET STRING, 864 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 865 }, 866 iterationCount INTEGER (1..MAX), 867 keyLength INTEGER (1..MAX) OPTIONAL, 868 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 869 algid-hmacWithSHA1 } 871 The fields of type PBKDF2-params have the following meanings: 873 - salt specifies the salt value, or the source of the salt value. 874 It shall either be an octet string or an algorithm ID with an 875 OID in the set PBKDF2-SaltSources, which is reserved for future 876 versions of PKCS #5. 878 The salt-source approach is intended to indicate how the salt 879 value is to be generated as a function of parameters in the 880 algorithm ID, application data, or both. For instance, it may 881 indicate that the salt value is produced from the encoding of a 882 structure that specifies detailed information about the derived 883 key as suggested in Section 4.1. Some of the information may be 884 carried elsewhere, e.g., in the encryption algorithm ID. 885 However, such facilities are deferred to a future version of 886 PKCS #5. 888 In this version, an application may achieve the benefits 889 mentioned in Section 4.1 by choosing a particular 890 interpretation of the salt value in the specified alternative. 892 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 894 - iterationCount specifies the iteration count. The maximum 895 iteration count allowed depends on the implementation. It is 896 expected that implementation profiles may further constrain the 897 bounds. 899 - keyLength, an optional field, is the length in octets of the 900 derived key. The maximum key length allowed depends on the 901 implementation; it is expected that implementation profiles may 902 further constrain the bounds. The field is provided for 903 convenience only; the key length is not cryptographically 904 protected. If there is concern about interaction between 905 operations with different key lengths for a given salt (see 906 Section 4.1), the salt should distinguish among the different 907 key lengths. 909 - prf identifies the underlying pseudorandom function. It shall 910 be an algorithm ID with an OID in the set PBKDF2-PRFs, which 911 for this version of PKCS #5 shall consist of id-hmacWithSHA1 912 (see Appendix B.1.1) and any other OIDs defined by the 913 application. 915 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { 916 {NULL IDENTIFIED BY id-hmacWithSHA1}, 917 {NULL IDENTIFIED BY id-hmacWithSHA224}, 918 {NULL IDENTIFIED BY id-hmacWithSHA256}, 919 {NULL IDENTIFIED BY id-hmacWithSHA384}, 920 {NULL IDENTIFIED BY id-hmacWithSHA512}, 921 {NULL IDENTIFIED BY id-hmacWithSHA512-224}, 922 {NULL IDENTIFIED BY id-hmacWithSHA512-256}, 923 ... 924 } 926 The default pseudorandom function is HMAC-SHA-1: 928 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 929 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 931 A.3. PBES1 933 Different object identifiers identify the PBES1 encryption scheme 934 (Section 6.1) according to the underlying hash function in the key 935 derivation function and the underlying block cipher, as summarized in 936 the following table: 938 Hash Function Block Cipher OID 939 MD2 DES pkcs-5.1 940 MD2 RC2 pkcs-5.4 941 MD5 DES pkcs-5.3 942 MD5 RC2 pkcs-5.6 943 SHA-1 DES pkcs-5.10 944 SHA-1 RC2 pkcs-5.11 946 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 947 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 948 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 949 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 950 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 951 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 953 For each OID, the parameters field associated with the OID in an 954 AlgorithmIdentifier shall have type PBEParameter: 956 PBEParameter ::= SEQUENCE { 957 salt OCTET STRING (SIZE(8)), 958 iterationCount INTEGER } 960 The fields of type PBEParameter have the following meanings: 962 - salt specifies the salt value, an eight-octet string. 964 - iterationCount specifies the iteration count. 966 A.4. PBES2 968 The object identifier id-PBES2 identifies the PBES2 encryption scheme 969 (Section 6.2). 971 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 973 The parameters field associated with this OID in an 974 AlgorithmIdentifier shall have type PBES2-params: 976 PBES2-params ::= SEQUENCE { 977 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 978 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} } 980 The fields of type PBES2-params have the following meanings: 982 - keyDerivationFunc identifies the underlying key derivation 983 function. It shall be an algorithm ID with an OID in the set 984 PBES2-KDFs, which for this version of PKCS #5 shall consist of 985 id-PBKDF2 (Appendix A.2). 987 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 988 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 990 - encryptionScheme identifies the underlying encryption scheme. 991 It shall be an algorithm ID with an OID in the set PBES2-Encs, 992 whose definition is left to the application. Example underlying 993 encryption schemes are given in Appendix B.2. 995 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 997 A.5. PBMAC1 999 The object identifier id-PBMAC1 identifies the PBMAC1 message 1000 authentication scheme (Section 7.1). 1002 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1004 The parameters field associated with this OID in an 1005 AlgorithmIdentifier shall have type PBMAC1-params: 1007 PBMAC1-params ::= SEQUENCE { 1008 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1009 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} } 1011 The keyDerivationFunc field has the same meaning as the corresponding 1012 field of PBES2-params (Appendix A.4) except that the set of OIDs is 1013 PBMAC1-KDFs. 1015 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= 1016 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... } 1018 The messageAuthScheme field identifies the underlying message 1019 authentication scheme. It shall be an algorithm ID with an OID in the 1020 set PBMAC1-MACs, whose definition is left to the application. Example 1021 underlying encryption schemes are given in Appendix B.3. 1023 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1025 B. Supporting Techniques 1027 This section gives several examples of underlying functions and 1028 schemes supporting the password-based schemes in Sections 5, 6 and 7. 1030 While these supporting techniques are appropriate for applications to 1031 implement, none of them is required to be implemented. It is 1032 expected, however, that profiles for PKCS #5 will be developed that 1033 specify particular supporting techniques. 1035 This section also gives object identifiers for the supporting 1036 techniques. The object identifiers digestAlgorithm and 1037 encryptionAlgorithm identify the arcs from which certain algorithm 1038 OIDs referenced in this section are derived: 1040 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1041 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1043 B.1. Pseudorandom functions 1045 Examples of pseudorandom function for PBKDF2 (Section 5.2) include 1046 HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and 1047 SHA512/256. Applications may employ other schemes as well. 1049 B.1.1. HMAC-SHA-1 1051 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC 1052 message authentication code [13] based on the SHA-1 hash function 1053 [17]. The pseudorandom function is the same function by which the 1054 message authentication code is computed, with a full-length output. 1055 (The first argument to the pseudorandom function PRF serves as HMAC's 1056 "key," and the second serves as HMAC's "text." In the case of PBKDF2, 1057 the "key" is thus the password and the "text" is the salt.) HMAC- 1058 SHA-1 has a variable key length and a 20-octet (160-bit) output 1059 value. 1061 Although the length of the key to HMAC-SHA-1 is essentially 1062 unbounded, the effective search space for pseudorandom function 1063 outputs may be limited by the structure of the function. In 1064 particular, when the key is longer than 512 bits, HMAC-SHA-1 will 1065 first hash it to 160 bits. Thus, even if a long derived key 1066 consisting of several pseudorandom function outputs is produced from 1067 a key, the effective search space for the derived key will be at most 1068 160 bits. Although the specific limitation for other key sizes 1069 depends on details of the HMAC construction, one should assume, to be 1070 conservative, that the effective search space is limited to 160 bits 1071 for other key sizes as well. 1073 (The 160-bit limitation should not generally pose a practical 1074 limitation in the case of password-based cryptography, since the 1075 search space for a password is unlikely to be greater than 160 bits.) 1077 The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1 1078 pseudorandom function: 1080 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1082 The parameters field associated with this OID in an 1083 AlgorithmIdentifier shall have type NULL. This object identifier is 1084 employed in the object set PBKDF2-PRFs (Appendix A.2). 1086 Note. Although HMAC-SHA-1 was designed as a message authentication 1087 code, its proof of security is readily modified to accommodate 1088 requirements for a pseudorandom function, under stronger assumptions. 1089 A hash function may also meet the requirements of a pseudorandom 1090 function under certain assumptions. For instance, the direct 1091 application of a hash function to to the concatenation of the "key" 1092 and the "text" may be appropriate, provided that "text" has 1093 appropriate structure to prevent certain attacks. HMAC-SHA-1 is 1094 preferable, however, because it treats "key" and "text" as separate 1095 arguments and does not require "text" to have any structure. 1097 During 2004 and 2005 there were a number of attacks on SHA-1 that 1098 reduced its perceived effective strength against collision attacks to 1099 62 bits instead of the expected 80 bits (e.g. Wang et al. [30], 1100 confirmed by M. Cochran [5]). However, since these attacks centered 1101 on finding collisions between values they are not a direct security 1102 consideration here because the collision-resistant property is not 1103 required by the HMAC authentication scheme. 1105 B.1.2. HMAC-SHA-2 1107 HMAC-SHA-2 refers to the set of pseudo-random functions corresponding 1108 to the HMAC message authentication code (now a FIPS standard [19]) 1109 based on the new SHA-2 functions (FIPS 180-4 [17]). HMAC-SHA-2 has a 1110 variable key length and variable output value depending on the hash 1111 function chosen (SHA-224, SHA-256, SHA-384, SHA-512, SHA -512/224,or 1112 SHA-512/256), that is 28, 32, 48, or 64 octets. 1114 Using the new hash functions extends the search space for the 1115 produced keys. Where SHA-1 limits the search space to 20 octets, 1116 SHA-2 sets new limits of 28, 32, 48 and 64 octets. 1118 Object identifiers for HMAC are defined as follows: 1120 id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} 1121 id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} 1122 id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} 1123 id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} 1124 id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} 1125 id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} 1127 B.2. Encryption Schemes 1129 An example encryption scheme for PBES2 (Section 6.2) is AES-CBC-Pad. 1130 The schemes defined in PKCS #5 v2.0 [28], DES-CBC-Pad, DES-EDE3-CBC- 1131 Pad, RC2-CBC-Pad, and RC5-CBC-Pad, are still supported, but DES-CBC- 1132 Pad, DES-EDE3-CBC-Pad, RC2-CBC-Pad are now considered legacy and 1133 should only be used for backwards compatibility reasons. 1135 The object identifiers given in this section are intended to be 1136 employed in the object set PBES2-Encs (Appendix A.4). 1138 B.2.1. DES-CBC-Pad 1140 DES-CBC-Pad is single-key DES [15] in CBC mode [16] with the RFC 1423 1141 [3] padding operation (see Section 6.1.1). DES-CBC-Pad has an eight- 1142 octet encryption key and an eight-octet initialization vector. The 1143 key is considered as a 64-bit encoding of a 56-bit DES key with 1144 parity bits ignored. 1146 The object identifier desCBC (defined in the NIST/OSI Implementors' 1147 Workshop agreements) identifies the DES-CBC-Pad encryption scheme: 1149 desCBC OBJECT IDENTIFIER ::= 1150 {iso(1) identified-organization(3) oiw(14) secsig(3) 1151 algorithms(2) 7} 1153 The parameters field associated with this OID in an 1154 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1155 specifying the initialization vector for CBC mode. 1157 B.2.2. DES-EDE3-CBC-Pad 1159 DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [1] with the RFC 1160 1423 [3] padding operation. DES-EDE3-CBC-Pad has a 24-octet 1161 encryption key and an eight-octet initialization vector. The key is 1162 considered as the concatenation of three eight-octet keys, each of 1163 which is a 64-bit encoding of a 56-bit DES key with parity bits 1164 ignored. 1166 The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad 1167 encryption scheme: 1169 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1171 The parameters field associated with this OID in an 1172 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), 1173 specifying the initialization vector for CBC mode. 1175 Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 1176 [1]; the one given here is preferred since it specifies padding. 1178 B.2.3. RC2-CBC-Pad 1180 RC2-CBC-Pad is the RC2(tm) encryption algorithm [24] in CBC mode with 1181 the RFC 1423 [3] padding operation. RC2-CBC-Pad has a variable key 1182 length, from one to 128 octets, a separate "effective key bits" 1183 parameter from one to 1024 bits that limits the effective search 1184 space independent of the key length, and an eight-octet 1185 initialization vector. 1187 The object identifier rc2CBC identifies the RC2-CBC-Pad encryption 1188 scheme: 1190 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1192 The parameters field associated with OID in an AlgorithmIdentifier 1193 shall have type RC2-CBC-Parameter: 1195 RC2-CBC-Parameter ::= SEQUENCE { 1196 rc2ParameterVersion INTEGER OPTIONAL, 1197 iv OCTET STRING (SIZE(8)) } 1199 The fields of type RC2-CBCParameter have the following meanings: 1201 - rc2ParameterVersion is a proprietary RSA Security Inc. encoding 1202 of the "effective key bits" for RC2. The following encodings 1203 are defined: 1205 Effective Key Bits Encoding 1206 40 160 1207 64 120 1208 128 58 1209 b >= 256 b 1211 If the rc2ParameterVersion field is omitted, the "effective key bits" 1212 defaults to 32. (This is for backward compatibility with certain very 1213 old implementations.) 1215 - iv is the eight-octet initialization vector. 1217 B.2.4. RC5-CBC-Pad 1219 RC5-CBC-Pad is the RC5(tm) encryption algorithm [23] in CBC mode with 1220 RFC 5652 [6] padding operation, which is a generalization of the RFC 1221 1423 [3] padding operation. The scheme is fully specified in [2]. 1222 RC5-CBC-Pad has a variable key length, from 0 to 256 octets, and 1223 supports both a 64-bit block size and a 128-bit block size. For the 1224 former, it has an eight-octet initialization vector, and for the 1225 latter, a 16-octet initialization vector. RC5-CBC-Pad also has a 1226 variable number of "rounds" in the encryption operation, from 8 to 1227 127. 1229 Note: For RC5 with a 64-bit block size, the padding string is as 1230 defined in RFC 1423 [3]. For RC5 with a 128-bit block size, the 1231 padding string consists of 16-(||M|| mod 16) octets each with value 1232 16-(||M|| mod 16). 1234 The object identifier rc5-CBC-PAD [2] identifies RC5-CBC-Pad 1235 encryption scheme: 1237 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1239 The parameters field associated with this OID in an 1240 AlgorithmIdentifier shall have type RC5-CBC-Parameters: 1242 RC5-CBC-Parameters ::= SEQUENCE { 1243 version INTEGER {v1-0(16)} (v1-0), 1244 rounds INTEGER (8..127), 1245 blockSizeInBits INTEGER (64 | 128), 1246 iv OCTET STRING OPTIONAL } 1248 The fields of type RC5-CBC-Parameters have the following meanings: 1250 - version is the version of the algorithm, which shall be v1-0. 1252 - rounds is the number of rounds in the encryption operation, 1253 which shall be between 8 and 127. 1255 - blockSizeInBits is the block size in bits, which shall be 64 or 1256 128. 1258 - iv is the initialization vector, an eight-octet string for 1259 64-bit RC5 and a 16-octet string for 128-bit RC5. The default 1260 is a string of the appropriate length consisting of zero 1261 octets. 1263 B.2.5. AES-CBC-Pad 1265 AES-CBC-Pad is the AES encryption algorithm [18] in CBC mode with RFC 1266 5652 [6] padding operation. AES-CBC-Pad has a variable key length of 1267 16, 24, or 32 octets and has a 16-octet block size. It has a 16-octet 1268 initialization vector. 1270 Note: For AES, the padding string consists of 16-(||M|| mod 16) 1271 octets each with value 16-(||M|| mod 16). 1273 For AES, object identifiers are defined depending on key size and 1274 operation mode. For example, the 16-octet (128 bit) key AES 1275 encryption scheme in CBC mode would be aes128-CBC-Pad identifying the 1276 AES-CBC-PAD encryption scheme using a 16-octet key: 1278 aes128-CBC-PAD OBJECT IDENTIFIER ::= {aes 2} 1280 The AES object identifier is defined in Appendix C. 1282 The parameters field associated with this OID in an 1283 AlgorithmIdentifier shall have type OCTET STRING (SIZE(16)), 1284 specifying the initialization vector for CBC mode. 1286 B.3. Message Authentication Schemes 1288 An example message authentication scheme for PBMAC1 (Section 7.1) is 1289 HMAC-SHA-1. 1291 B.3.1. HMAC-SHA-1 1293 HMAC-SHA-1 is the HMAC message authentication scheme [13] based on 1294 the SHA-1 hash function [17]. HMAC-SHA-1 has a variable key length 1295 and a 20-octet (160-bit) message authentication code. 1297 The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies 1298 the HMAC-SHA-1 message authentication scheme. (The object identifier 1299 is the same for both the pseudorandom function and the message 1300 authentication scheme; the distinction is to be understood by 1301 context.) This object identifier is intended to be employed in the 1302 object set PBMAC1-Macs (Appendix A.5). 1304 B.3.2. HMAC-SHA-2 1306 HMAC-SHA-2 refers to the set of HMAC message authentication schemes 1307 [19] based on the SHA-2 functions [17]. HMAC-SHA-2 has a variable key 1308 length and a message authentication code whose length is based on 1309 the hash function chosen (SHA-224, SHA-256, SHA-384, SHA-512, 1310 SHA-512/224, or SHA-512/256giving 28, 32, 48 or 64 octets). 1312 The object identifiers id-hmacWithSHA224, id-hmacWithSHA256, id- 1313 hmacWithSHA384, id-hmacWithSHA512, id-hmacWithSHA512-224,and id- 1314 hmacWithSHA512-256 (see Appendix B.1.2) identify the HMAC-SHA-2 1315 schemes. The object identifiers are the same for both the 1316 pseudo-random functions and the message authentication schemes; the 1317 distinction is to be understood by context. These object identifiers 1318 are intended to be employed in the object set PBMAC1-Macs (Appendix 1319 A.5) 1321 C. ASN.1 Module 1323 For reference purposes, the ASN.1 syntax in the preceding sections is 1324 presented as an ASN.1 module here. 1326 -- PKCS #5 v2.1 ASN.1 Module 1327 -- Revised October 27, 2012 1329 -- This module has been checked for conformance with the 1330 -- ASN.1 standard by the OSS ASN.1 Tools 1332 PKCS5v2-1 { 1333 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 1334 modules(16) pkcs5v2-1(2) 1335 } 1337 DEFINITIONS EXPLICIT TAGS ::= 1339 BEGIN 1341 -- ======================== 1342 -- Basic object identifiers 1343 -- ======================== 1345 nistAlgorithms OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) country(16) 1346 us(840) organization(1) 1347 gov(101) csor(3) 4} 1348 oiw OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) 14} 1349 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549} 1350 pkcs OBJECT IDENTIFIER ::= {rsadsi 1} 1351 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5} 1353 -- ======================= 1354 -- Basic types and classes 1355 -- ======================= 1357 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= 1358 SEQUENCE { 1359 algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), 1360 parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} 1361 {@algorithm}) OPTIONAL 1362 } 1364 ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER 1366 -- ====== 1367 -- PBKDF2 1368 -- ====== 1370 PBKDF2Algorithms ALGORITHM-IDENTIFIER ::= { 1371 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1372 ... 1373 } 1375 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12} 1377 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= 1378 {algorithm id-hmacWithSHA1, parameters NULL : NULL} 1380 PBKDF2-params ::= SEQUENCE { 1381 salt CHOICE { 1382 specified OCTET STRING, 1383 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} 1384 }, 1385 iterationCount INTEGER (1..MAX), 1386 keyLength INTEGER (1..MAX) OPTIONAL, 1387 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT 1388 algid-hmacWithSHA1 1389 } 1391 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } 1393 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= { 1394 {NULL IDENTIFIED BY id-hmacWithSHA1}, 1395 {NULL IDENTIFIED BY id-hmacWithSHA224}, 1396 {NULL IDENTIFIED BY id-hmacWithSHA256}, 1397 {NULL IDENTIFIED BY id-hmacWithSHA384}, 1398 {NULL IDENTIFIED BY id-hmacWithSHA512}, 1399 {NULL IDENTIFIED BY id-hmacWithSHA512-224}, 1400 {NULL IDENTIFIED BY id-hmacWithSHA512-256}, 1401 ... 1402 } 1404 -- ===== 1405 -- PBES1 1406 -- ===== 1408 PBES1Algorithms ALGORITHM-IDENTIFIER ::= { 1409 {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} | 1410 {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} | 1411 {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} | 1412 {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} | 1413 {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} | 1414 {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC}, 1415 ... 1416 } 1418 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1} 1419 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4} 1420 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3} 1421 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6} 1422 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10} 1423 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11} 1425 PBEParameter ::= SEQUENCE { 1426 salt OCTET STRING (SIZE(8)), 1427 iterationCount INTEGER 1428 } 1430 -- ===== 1431 -- PBES2 1432 -- ===== 1434 PBES2Algorithms ALGORITHM-IDENTIFIER ::= { 1435 {PBES2-params IDENTIFIED BY id-PBES2}, 1436 ... 1437 } 1439 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13} 1441 PBES2-params ::= SEQUENCE { 1442 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}}, 1443 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} 1444 } 1446 PBES2-KDFs ALGORITHM-IDENTIFIER ::= { 1447 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1448 ... 1449 } 1451 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... } 1453 -- ====== 1454 -- PBMAC1 1455 -- ====== 1457 PBMAC1Algorithms ALGORITHM-IDENTIFIER ::= { 1458 {PBMAC1-params IDENTIFIED BY id-PBMAC1}, 1459 ... 1460 } 1462 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14} 1464 PBMAC1-params ::= SEQUENCE { 1465 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}, 1466 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} 1467 } 1469 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::= { 1470 {PBKDF2-params IDENTIFIED BY id-PBKDF2}, 1471 ... 1472 } 1474 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... } 1476 -- ===================== 1477 -- Supporting techniques 1478 -- ===================== 1480 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2} 1481 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3} 1483 SupportingAlgorithms ALGORITHM-IDENTIFIER ::= { 1484 {NULL IDENTIFIED BY id-hmacWithSHA1} | 1485 {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} | 1486 {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} | 1487 {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} | 1488 {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}, | 1489 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes128-CBC-PAD} | 1490 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes192-CBC-PAD} | 1491 {OCTET STRING (SIZE(16)) IDENTIFIED BY aes256-CBC-PAD}, 1492 ... 1493 } 1495 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 1496 id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8} 1497 id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9} 1498 id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10} 1499 id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11} 1500 id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12} 1501 id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13} 1503 desCBC OBJECT IDENTIFIER ::= {oiw secsig(3) algorithms(2) 7} 1505 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7} 1507 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2} 1509 RC2-CBC-Parameter ::= SEQUENCE { 1510 rc2ParameterVersion INTEGER OPTIONAL, 1511 iv OCTET STRING (SIZE(8)) 1512 } 1514 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9} 1516 RC5-CBC-Parameters ::= SEQUENCE { 1517 version INTEGER {v1-0(16)} (v1-0), 1518 rounds INTEGER (8..127), 1519 blockSizeInBits INTEGER (64 | 128), 1520 iv OCTET STRING OPTIONAL 1521 } 1523 aes OBJECT IDENTIFIER ::= { nistAlgorithms 1 } 1524 aes128-CBC-PAD OBJECT IDENTIFIER ::= { aes 2 } 1525 aes192-CBC-PAD OBJECT IDENTIFIER ::= { aes 22 } 1526 aes256-CBC-PAD OBJECT IDENTIFIER ::= { aes 42 } 1528 END 1530 D. Intellectual Property Considerations 1532 EMC Corporation makes no patent claims on the general constructions 1533 described in this document, although specific underlying techniques 1534 may be covered. Among the underlying techniques, the RC5 encryption 1535 algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 1536 [25] and 5,835,600 [26]. 1538 RC2 and RC5 are trademarks of EMC Corporation. 1540 EMC Corporation makes no representation regarding intellectual 1541 property claims by other parties. Such determination is the 1542 responsibility of the user. 1544 E. Revision History 1546 Versions 1.0-1.3 1548 Versions 1.0-1.3 were distributed to participants in RSA Data 1549 Security Inc.'s Public-Key Cryptography Standards meetings in 1550 February and March 1991. 1552 Version 1.4 1554 Version 1.4 was part of the June 3, 1991 initial public release of 1555 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1556 document SEC-SIG-91-20. 1558 Version 1.5 1560 Version 1.5 incorporated several editorial changes, including 1561 updates to the references and the addition of a revision history. 1563 Version 2.0 1565 Version 2.0 incorporates major editorial changes in terms of the 1566 document structure, and introduces the PBES2 encryption scheme, 1567 the PBMAC1 message authentication scheme, and independent 1568 password-based key derivation functions. This version continues to 1569 support the encryption process in version 1.5. 1571 Version 2.1 1573 This document transfers PKCS #5 into the IETF and includes some 1574 minor changes from the authors for this submission. 1576 o Introduces AES/CBC as an encryption scheme for PBES2 and HMAC 1577 with the hash functions SHA-224, SHA-256, SHA-384, SHA-512, 1578 SHA-512/224, and SHA512/256 as pseudo-random functions for PBKDF2 1579 and message authentication schemes for PBMAC1. 1581 o Replacement of RSA with EMC in the "Intellectual Property 1582 Considerations". 1584 o Changes references to PKCS #5 and PKCS #8 to RSA 2898 and RFC 1585 5208/5898. 1587 o Incorporates two editorial errata reported on PKCS #5 [28]. 1589 o Added security considerations for MD2, MD5, and SHA-1. 1591 F. References 1593 F.1 Normative References 1595 [1] American National Standard X9.52 - 1998, Triple Data Encryption 1596 Algorithm Modes of Operation. Working draft, Accredited 1597 Standards Committee X9, July 27, 1998. 1599 [2] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 1600 RC5-CTS Algorithms", RFC 2040, October 1996. 1602 [3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: 1603 Part III: Algorithms, Modes, and Identifiers", RFC 1423, 1604 February 1993. 1606 [4] 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 [5] M. Cochran. Notes on the Wang et al. 2^63 SHA-1 Differential 1613 Path. International Association for Cryptologic Research, ePrint 1614 Archive. August 2008. Available from 1615 http://eprint.iacr.org/2007/474 1617 [6] R. Housley. RFC 5652: Cryptographic Message Syntax. IETF, 1618 September 2009. 1620 [7] ISO/IEC 8824-1: 2008: Information technology - Abstract Syntax 1621 Notation One (ASN.1) - Specification of basic notation. 2008. 1623 [8] ISO/IEC 8824-2: 2008: Information technology - Abstract Syntax 1624 Notation One (ASN.1) - Information object specification. 2008. 1626 [9] ISO/IEC 8824-3: 2008: Information technology - Abstract Syntax 1627 Notation One (ASN.1) - Constraint specification. 2008. 1629 [10] ISO/IEC 8824-4: 2008: Information technology - Abstract Syntax 1630 Notation One (ASN.1) - Parameterization of ASN.1 specifications. 1631 2008. 1633 [11] D. Jablon. Strong password-only authenticated key exchange. ACM 1634 Computer Communications Review, October 1996. 1636 [12] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1637 1992. 1639 [13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1640 for Message Authentication", RFC 2104, February 1997. 1642 [14] Robert Morris and Ken Thompson. Password security: A case 1643 history. Communications of the ACM, 22(11):594-597, November 1644 1979. 1646 [15] National Institute of Standards and Technology (NIST). FIPS PUB 1647 46-3: Data Encryption Standard. October 1999. 1649 [16] National Institute of Standards and Technology (NIST). FIPS PUB 1650 81: DES Modes of Operation. December 2, 1980. 1652 [17] National Institute of Standards and Technology (NIST). FIPS PUB 1653 180-4: Secure Hash Standard. March 2012. 1655 [18] National Institute of Standards and Technology (NIST). FIPS 1656 Publication 197: Advance Encryption Standard (AES). November 1657 2001. 1659 [19] National Institute of Standards and Technology (NIST). FIPS 1660 Publication 198-1: The Keyed - Hash Message Authentication Code 1661 (HMAC). July 2008. 1663 [20] National Institute of Standards and Technology (NIST). Special 1664 Publication 800-63-2: Electronic Authentication Guideline, 1665 Appendix A. August 2013. 1667 [21] National Institute of Standards and Technology (NIST). Special 1668 Publication 800-132: Recommendation for Password - Based Key 1669 Derivation, Part 1: Storage Applications. December 2010. 1671 [22] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1672 1992. 1674 [23] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the 1675 Second International Workshop on Fast Software Encryption, pages 1676 86-96, Springer-Verlag, 1994. 1678 [24] Rivest, R., "A Description of the RC2(r) Encryption Algorithm", 1679 RFC 2268, March 1998. 1681 [25] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent 1682 Rotations. U.S. Patent No. 5,724,428, March 3, 1998. 1684 [26] R.L. Rivest. Block Encryption Algorithm with Data-Dependent 1685 Rotations. U.S. Patent No. 5,835,600, November 10, 1998. 1687 [27] RSA Laboratories. PKCS #5: Password-Based Encryption Standard 1688 Version 1.5, November 1993. 1690 [28] B. Kaliski., "PKCS #5: Password-Based Encryption Standard 1691 Version 2.0", RFC 2898, September 2000. 1693 [29] RSA Laboratories. "PKCS #8: Private-Key Information Syntax 1694 Standard Version 1.2", RFC 5208, May 2008. 1696 [30] X. Wang, A.C. Yao, and F. Yao. Cryptanalysis on SHA-1. 1697 Presented by Adi Shamir at the rump session of CRYPTO 2005. 1698 Slides may be found currently at 1699 http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New- 1700 Result.pdf 1702 [31] T. Wu. The Secure Remote Password protocol. In Proceedings of 1703 the 1998 Internet Society Network and Distributed System 1704 Security Symposium, pages 97-111, Internet Society, 1998. 1706 [32] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1707 2279, January 1998. 1709 [33] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010. 1711 [34] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, 1712 March 2011. 1714 [35] Turner, S. and L. Chen, "Updated Security Considerations for the 1715 MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 1716 2011. 1718 [36] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 1719 Considerations for the SHA-0 and SHA-1 Message-Digest 1720 Algorithms", RFC 6194, March 2011. 1722 G. About PKCS 1724 The Public-Key Cryptography Standards are specifications produced by 1725 RSA Laboratories in cooperation with secure systems developers 1726 worldwide for the purpose of accelerating the deployment of public- 1727 key cryptography. First published in 1991 as a result of meetings 1728 with a small group of early adopters of public-key technology, the 1729 PKCS documents have become widely referenced and implemented. 1730 Contributions from the PKCS series have become part of many formal 1731 and de facto standards, including ANSI X9 documents, PKIX, SET, 1732 S/MIME, and SSL. 1734 Further development of PKCS occurs through the IETF. Suggestions for 1735 improvement are welcome. 1737 Authors' Addresses 1739 Kathleen M. Moriarty (editor) 1740 EMC Corporation 1741 176 South Street 1742 Hopkinton, MA 1743 United States 1745 Email: Kathleen.Moriarty@emc.com 1747 Andreas Rusch 1748 RSA Security Inc. 1749 345 Queen Street 1750 Brisbane, QLD, 4000 1751 Australia 1753 EMail: Andreas.Rusch@rsa.com 1755 Burt Kaliski 1756 Verisign 1757 12061 Bluemont Way 1758 Reston, VA 1759 United States 1761 EMail: bkaliski@verisign.com