```
' and
'
``````
' lines.
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Missing reference section? '25' on line 1498 looks like a reference
-- Missing reference section? '4' on line 1429 looks like a reference
-- Missing reference section? '5' on line 1434 looks like a reference
-- Missing reference section? '26' on line 1501 looks like a reference
-- Missing reference section? '24' on line 1495 looks like a reference
-- Missing reference section? '8' on line 1443 looks like a reference
-- Missing reference section? '27' on line 1505 looks like a reference
-- Missing reference section? '17' on line 1473 looks like a reference
-- Missing reference section? '6' on line 1437 looks like a reference
-- Missing reference section? '19' on line 1479 looks like a reference
-- Missing reference section? '18' on line 1476 looks like a reference
-- Missing reference section? '15' on line 1467 looks like a reference
-- Missing reference section? '21' on line 1486 looks like a reference
-- Missing reference section? '16' on line 1470 looks like a reference
-- Missing reference section? '3' on line 1425 looks like a reference
-- Missing reference section? '9' on line 1446 looks like a reference
-- Missing reference section? '10' on line 1449 looks like a reference
-- Missing reference section? '11' on line 1453 looks like a reference
-- Missing reference section? '12' on line 1456 looks like a reference
-- Missing reference section? '13' on line 1460 looks like a reference
-- Missing reference section? '14' on line 1463 looks like a reference
-- Missing reference section? '7' on line 1440 looks like a reference
-- Missing reference section? '1' on line 1418 looks like a reference
-- Missing reference section? '20' on line 1482 looks like a reference
-- Missing reference section? '2' on line 1422 looks like a reference
-- Missing reference section? '22' on line 1489 looks like a reference
-- Missing reference section? '23' on line 1492 looks like a reference
Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 30 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT B. Kaliski
3 Expires: November 2000 RSA Laboratories
4 Intended Category: Informational May 2000
6 PKCS #5: Password-Based Cryptography Specification
7 Version 2.0
9
```
11 Status of this memo
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026 except that the right to
15 produce derivative works is not granted.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that other
19 groups may also distribute working documents as Internet-Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 Abstract
34 This memo represents a republication of PKCS #5 v 2.0 from RSA
35 Laboratories' Public-Key Cryptography Standards (PKCS) series, and
36 change control is retained within the PKCS process. The remainder of
37 this text is taken from that specification.
39 This document provides recommendations for the implementation of
40 password-based cryptography, covering key derivation functions,
41 encryption schemes, message-authentication schemes, and ASN.1 syntax
42 identifying the techniques.
44 The recommendations are intended for general application within
45 computer and communications systems, and as such include a fair
46 amount of flexibility. They are particularly intended for the
47 protection of sensitive information such as private keys, as in PKCS
48 #8 [25]. It is expected that application standards and implementation
49 profiles based on these specifications may include additional
50 constraints.
52 Other cryptographic techniques based on passwords, such as password-
53 based key entity authentication and key establishment protocols
54 [4][5][26] are outside the scope of this document. Guidelines for the
55 selection of passwords are also outside the scope.
57 Table of contents
59 1. Introduction ................................................ 3
60 2. Notation .................................................... 3
61 3. Overview .................................................... 4
62 4. Salt and iteration count .................................... 6
63 4.1 Salt .................................................... 6
64 4.2 Iteration count ......................................... 8
65 5. Key derivation functions .................................... 8
66 5.1 PBKDF1 .................................................. 9
67 5.2 PBKDF2 .................................................. 9
68 6. Encryption schemes .......................................... 11
69 6.1 PBES1 ................................................... 12
70 6.1.1 Encryption operation ............................. 12
71 6.1.2 Decryption operation ............................. 13
72 6.2 PBES2 ................................................... 14
73 6.2.1 Encryption operation ............................. 14
74 6.2.2 Decryption operation ............................. 15
75 7. Message authentication schemes .............................. 15
76 7.1 PBMAC1 .................................................. 15
77 7.1.1 MAC generation ................................... 16
78 7.1.2 MAC verification ................................. 16
79 8. Security considerations ..................................... 17
80 9. Author's address............................................. 17
82 Appendices
84 A. ASN.1 syntax ................................................ 18
85 A.1 PBKDF1 .................................................. 18
86 A.2 PBKDF2 .................................................. 18
87 A.3 PBES1 ................................................... 20
88 A.4 PBES2 ................................................... 20
89 A.5 PBMAC1 .................................................. 21
90 B. Supporting techniques ....................................... 22
91 B.1 Pseudorandom functions .................................. 22
92 B.2 Encryption schemes ...................................... 23
93 B.3 Message authentication schemes .......................... 26
94 C. ASN.1 module ................................................ 26
95 D. Intellectual property considerations ........................ 30
96 E. Revision history ............................................ 30
97 F. References .................................................. 31
98 G. Contact information & About PKCS ............................ 33
100 1. Introduction
102 This document provides recommendations for the implementation of
103 password-based cryptography, covering the following aspects:
105 - key derivation functions
106 - encryption schemes
107 - message-authentication schemes
108 - ASN.1 syntax identifying the techniques
110 The recommendations are intended for general application within
111 computer and communications systems, and as such include a fair
112 amount of flexibility. They are particularly intended for the
113 protection of sensitive information such as private keys, as in PKCS
114 #8 [25]. It is expected that application standards and implementation
115 profiles based on these specifications may include additional
116 constraints.
118 Other cryptographic techniques based on passwords, such as password-
119 based key entity authentication and key establishment protocols
120 [4][5][26] are outside the scope of this document. Guidelines for the
121 selection of passwords are also outside the scope.
123 This document supersedes PKCS #5 version 1.5 [24], but includes
124 compatible techniques.
126 2. Notation
128 C ciphertext, an octet string
130 c iteration count, a positive integer
132 DK derived key, an octet string
134 dkLen length in octets of derived key, a positive integer
136 EM encoded message, an octet string
138 Hash underlying hash function
140 hLen length in octets of pseudorandom function output, a positive
141 integer
143 l length in blocks of derived key, a positive integer
145 IV initialization vector, an octet string
146 K encryption key, an octet string
148 KDF key derivation function
150 M message, an octet string
152 P password, an octet string
154 PRF underlying pseudorandom function
156 PS padding string, an octet string
158 psLen length in octets of padding string, a positive integer
160 S salt, an octet string
162 T message authentication code, an octet string
164 T_1, ..., T_l, U_1, ..., U_c
165 intermediate values, octet strings
167 01, 02, ..., 08
168 octets with value 1, 2, ..., 8
170 \xor bit-wise exclusive-or of two octet strings
172 || || octet length operator
174 || concatenation operator
176 substring extraction operator: extracts octets i through j,
177 0 <= i <= j
179 3. Overview
181 In many applications of public-key cryptography, user security is
182 ultimately dependent on one or more secret text values or passwords.
183 Since a password is not directly applicable as a key to any
184 conventional cryptosystem, however, some processing of the password
185 is required to perform cryptographic operations with it. Moreover, as
186 passwords are often chosen from a relatively small space, special
187 care is required in that processing to defend against search attacks.
189 A general approach to password-based cryptography, as described by
190 Morris and Thompson [8] for the protection of password tables, is to
191 combine a password with a salt to produce a key. The salt can be
192 viewed as an index into a large set of keys derived from the
193 password, and need not be kept secret. Although it may be possible
194 for an opponent to construct a table of possible passwords (a so-
195 called "dictionary attack"), constructing a table of possible keys
196 will be difficult, since there will be many possible keys for each
197 password. An opponent will thus be limited to searching through
198 passwords separately for each salt.
200 Another approach to password-based cryptography is to construct key
201 derivation techniques that are relatively expensive, thereby
202 increasing the cost of exhaustive search. One way to do this is to
203 include an iteration count in the key derivation technique,
204 indicating how many times to iterate some underlying function by
205 which keys are derived. A modest number of iterations, say 1000, is
206 not likely to be a burden for legitimate parties when computing a
207 key, but will be a significant burden for opponents.
209 Salt and iteration count formed the basis for password-based
210 encryption in PKCS #5 v1.5, and adopted here as well for the various
211 cryptographic operations. Thus, password-based key derivation as
212 defined here is a function of a password, a salt, and an iteration
213 count, where the latter two quantities need not be kept secret.
215 From a password-based key derivation function, it is straightforward
216 to define password-based encryption and message authentication
217 schemes. As in PKCS #5 v1.5, the password-based encryption schemes
218 here are based on an underlying, conventional encryption scheme,
219 where the key for the conventional scheme is derived from the
220 password. Similarly, the password-based message authentication scheme
221 is based on an underlying conventional scheme. This two- layered
222 approach makes the password-based techniques modular in terms of the
223 underlying techniques they can be based on.
225 It is expected that the password-based key derivation functions may
226 find other applications than just the encryption and message
227 authentication schemes defined here. For instance, one might derive a
228 set of keys with a single application of a key derivation function,
229 rather than derive each key with a separate application of the
230 function. The keys in the set would be obtained as substrings of the
231 output of the key derivation function. This approach might be
232 employed as part of key establishment in a session-oriented protocol.
233 Another application is password checking, where the output of the key
234 derivation function is stored (along with the salt and iteration
235 count) for the purposes of subsequent verification of a password.
237 Throughout this document, a password is considered to be an octet
238 string of arbitrary length whose interpretation as a text string is
239 unspecified. In the interest of interoperability, however, it is
240 recommended that applications follow some common text encoding rules.
241 ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of
242 UTF-8.)
244 Although the selection of passwords is outside the scope of this
245 document, guidelines have been published [17] that may well be taken
246 into account.
248 4. Salt and iteration count
250 Inasmuch as salt and iteration count are central to the techniques
251 defined in this document, some further discussion is warranted.
253 4.1 Salt
255 A salt in password-based cryptography has traditionally served the
256 purpose of producing a large set of keys corresponding to a given
257 password, among which one is selected at random according to the
258 salt. An individual key in the set is selected by applying a key
259 derivation function KDF, as
261 DK = KDF (P, S)
263 where DK is the derived key, P is the password, and S is the salt.
264 This has two benefits:
266 1. It is difficult for an opponent to precompute all the keys
267 corresponding to a dictionary of passwords, or even the
268 most likely keys. If the salt is 64 bits long, for
269 instance, there will be as many as 2^64 keys for each
270 password. An opponent is thus limited to searching for
271 passwords after a password-based operation has been
272 performed and the salt is known.
274 2. It is unlikely that the same key will be selected twice.
275 Again, if the salt is 64 bits long, the chance of
276 "collision" between keys does not become significant until
277 about 2^32 keys have been produced, according to the
278 Birthday Paradox. This addresses some of the concerns about
279 interactions between multiple uses of the same key, which
280 may apply for some encryption and authentication
281 techniques.
283 In password-based encryption, the party encrypting a message can gain
284 assurance that these benefits are realized simply by selecting a
285 large and sufficiently random salt when deriving an encryption key
286 from a password. A party generating a message authentication code can
287 gain such assurance in a similar fashion.
289 The party decrypting a message or verifying a message authentication
290 code, however, cannot be sure that a salt supplied by another party
291 has actually been generated at random. It is possible, for instance,
292 that the salt may have been copied from another password-based
293 operation, in an attempt to exploit interactions between multiple
294 uses of the same key. For instance, suppose two legitimate parties
295 exchange a encrypted message, where the encryption key is an 80-bit
296 key derived from a shared password with some salt. An opponent could
297 take the salt from that encryption and provide it to one of the
298 parties as though it were for a 40-bit key. If the party reveals the
299 result of decryption with the 40-bit key, the opponent may be able to
300 solve for the 40-bit key. In the case that 40-bit key is the first
301 half of the 80-bit key, the opponent can then readily solve for the
302 remaining 40 bits of the 80-bit key.
304 To defend against such attacks, either the interaction between
305 multiple uses of the same key should be carefully analyzed, or the
306 salt should contain data that explicitly distinguishes between
307 different operations. For instance, the salt might have an
308 additional, non-random octet that specifies whether the derived key
309 is for encryption, for message authentication, or for some other
310 operation.
312 Based on this, the following is recommended for salt selection:
314 1. If there is no concern about interactions between multiple
315 uses of the same key (or a prefix of that key) with the
316 password-based encryption and authentication techniques
317 supported for a given password, then the salt may be
318 generated at random and need not be checked for a
319 particular format by the party receiving the salt. It
320 should be at least eight octets (64 bits) long.
322 2. Otherwise, the salt should contain data that explicitly
323 distinguishes between different operations and different
324 key lengths, in addition to a random part that is at least
325 eight octets long, and this data should be checked or
326 regenerated by the party receiving the salt. For instance,
327 the salt could have an additional non-random octet that
328 specifies the purpose of the derived key. Alternatively,
329 it could be the encoding of a structure that specifies
330 detailed information about the derived key, such as the
331 encryption or authentication technique and a sequence
332 number among the different keys derived from the password.
333 The particular format of the additional data is left to the
334 application.
336 Note. If a random number generator or pseudorandom generator is not
337 available, a deterministic alternative for generating the salt (or
338 the random part of it) is to apply a password-based key derivation
339 function to the password and the message M to be processed. For
340 instance, the salt could be computed with a key derivation function
341 as S = KDF (P, M). This approach is not recommended if the message M
342 is known to belong to a small message space (e.g., "Yes" or "No"),
343 however, since then there will only be a small number of possible
344 salts.
346 4.2 Iteration count
348 An iteration count has traditionally served the purpose of increasing
349 the cost of producing keys from a password, thereby also increasing
350 the difficulty of attack. For the methods in this document, a minimum
351 of 1000 iterations is recommended. This will increase the cost of
352 exhaustive search for passwords significantly, without a noticeable
353 impact in the cost of deriving individual keys.
355 5. Key derivation functions
357 A key derivation function produces a derived key from a base key and
358 other parameters. In a password-based key derivation function, the
359 base key is a password and the other parameters are a salt value and
360 an iteration count, as outlined in Section 3.
362 The primary application of the password-based key derivation
363 functions defined here is in the encryption schemes in Section 6 and
364 the message authentication scheme in Section 7. Other applications
365 are certainly possible, hence the independent definition of these
366 functions.
368 Two functions are specified in this section: PBKDF1 and PBKDF2.
369 PBKDF2 is recommended for new applications; PBKDF1 is included only
370 for compatibility with existing applications, and is not recommended
371 for new applications.
373 A typical application of the key derivation functions defined here
374 might include the following steps:
376 1. Select a salt S and an iteration count c, as outlined in
377 Section 4.
379 2. Select a length in octets for the derived key, dkLen.
381 3. Apply the key derivation function to the password, the
382 salt, the iteration count and the key length to produce a
383 derived key.
385 4. Output the derived key.
387 Any number of keys may be derived from a password by varying the
388 salt, as described in Section 3.
390 5.1 PBKDF1
392 PBKDF1 applies a hash function, which shall be MD2 [6], MD5 [19] or
393 SHA-1 [18], to derive keys. The length of the derived key is bounded
394 by the length of the hash function output, which is 16 octets for MD2
395 and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key
396 derivation process in PKCS #5 v1.5.
398 PBKDF1 is recommended only for compatibility with existing
399 applications since the keys it produces may not be large enough for
400 some applications.
402 PBKDF1 (P, S, c, dkLen)
404 Options: Hash underlying hash function
406 Input: P password, an octet string
407 S salt, an eight-octet string
408 c iteration count, a positive integer
409 dkLen intended length in octets of derived key,
410 a positive integer, at most 16 for MD2 or
411 MD5 and 20 for SHA-1
413 Output: DK derived key, a dkLen-octet string
415 Steps:
417 1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1,
418 output "derived key too long" and stop.
420 2. Apply the underlying hash function Hash for c iterations to
421 the concatenation of the password P and the salt S, then
422 extract the first dkLen octets to produce a derived key DK:
424 T_1 = Hash (P || S) ,
425 T_2 = Hash (T_1) ,
426 ...
427 T_c = Hash (T_{c-1}) ,
428 DK = Tc<0..dkLen-1>
430 3. Output the derived key DK.
432 5.2 PBKDF2
434 PBKDF2 applies a pseudorandom function (see Appendix B.1 for an
435 example) to derive keys. The length of the derived key is essentially
436 unbounded. (However, the maximum effective search space for the
437 derived key may be limited by the structure of the underlying
438 pseudorandom function. See Appendix B.1 for further discussion.)
439 PBKDF2 is recommended for new applications.
441 PBKDF2 (P, S, c, dkLen)
443 Options: PRF underlying pseudorandom function (hLen
444 denotes the length in octets of the
445 pseudorandom function output)
447 Input: P password, an octet string
448 S salt, an octet string
449 c iteration count, a positive integer
450 dkLen intended length in octets of the derived
451 key, a positive integer, at most
452 (2^32 - 1) * hLen
454 Output: DK derived key, a dkLen-octet string
456 Steps:
458 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long"
459 and stop.
461 2. Let l be the number of hLen-octet blocks in the derived key,
462 rounding up, and let r be the number of octets in the last
463 block:
465 l = CEIL (dkLen / hLen) ,
466 r = dkLen - (l - 1) * hLen .
468 Here, CEIL (x) is the "ceiling" function, i.e. the smallest
469 integer greater than, or equal to, x.
471 3. For each block of the derived key apply the function F
472 defined below to the password P, the salt S, the iteration
473 count c, and the block index to compute the block:
475 T_1 = F (P, S, c, 1) ,
476 T_2 = F (P, S, c, 2) ,
477 ...
478 T_l = F (P, S, c, l) ,
480 where the function F is defined as the exclusive-or sum of
481 the first c iterates of the underlying pseudorandom function
482 PRF applied to the password P and the concatenation of the
483 salt S and the block index i:
485 F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c
487 where
489 U_1 = PRF (P, S || INT (i)) ,
490 U_2 = PRF (P, U_1) ,
491 ...
492 U_c = PRF (P, U_{c-1}) .
494 Here, INT (i) is a four-octet encoding of the integer i, most
495 significant octet first.
497 4. Concatenate the blocks and extract the first dkLen octets to
498 produce a derived key DK:
500 DK = T_1 || T_2 || ... || T_l<0..r-1>
502 5. Output the derived key DK.
504 Note. The construction of the function F follows a "belt-and-
505 suspenders" approach. The iterates U_i are computed recursively to
506 remove a degree of parallelism from an opponent; they are exclusive-
507 ored together to reduce concerns about the recursion degenerating
508 into a small set of values.
510 6. Encryption schemes
512 An encryption scheme, in the symmetric setting, consists of an
513 encryption operation and a decryption operation, where the encryption
514 operation produces a ciphertext from a message under a key, and the
515 decryption operation recovers the message from the ciphertext under
516 the same key. In a password-based encryption scheme, the key is a
517 password.
519 A typical application of a password-based encryption scheme is a
520 private-key protection method, where the message contains private-key
521 information, as in PKCS #8. The encryption schemes defined here would
522 be suitable encryption algorithms in that context.
524 Two schemes are specified in this section: PBES1 and PBES2. PBES2 is
525 recommended for new applications; PBES1 is included only for
526 compatibility with existing applications, and is not recommended for
527 new applications.
529 6.1 PBES1
531 PBES1 combines the PBKDF1 function (Section 5.1) with an underlying
532 block cipher, which shall be either DES [15] or RC2(tm) [21] in CBC
533 mode [16]. PBES1 is compatible with the encryption scheme in PKCS #5
534 v1.5.
536 PBES1 is recommended only for compatibility with existing
537 applications, since it supports only two underlying encryption
538 schemes, each of which has a key size (56 or 64 bits) that may not be
539 large enough for some applications.
541 6.1.1 Encryption operation
543 The encryption operation for PBES1 consists of the following steps,
544 which encrypt a message M under a password P to produce a ciphertext
545 C:
547 1. Select an eight-octet salt S and an iteration count c, as
548 outlined in Section 4.
550 2. Apply the PBKDF1 key derivation function (Section 5.1) to the
551 password P, the salt S, and the iteration count c to produce
552 at derived key DK of length 16 octets:
554 DK = PBKDF1 (P, S, c, 16) .
556 3. Separate the derived key DK into an encryption key K
557 consisting of the first eight octets of DK and an
558 initialization vector IV consisting of the next eight octets:
560 K = DK<0..7> ,
561 IV = DK<8..15> .
563 4. Concatenate M and a padding string PS to form an encoded
564 message EM:
566 EM = M || PS ,
568 where the padding string PS consists of 8-(||M|| mod 8)
569 octets each with value 8-(||M|| mod 8). The padding string PS
570 will satisfy one of the following statements:
572 PS = 01, if ||M|| mod 8 = 7 ;
573 PS = 02 02, if ||M|| mod 8 = 6 ;
574 ...
575 PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0.
577 The length in octets of the encoded message will be a
578 multiple of eight and it will be possible to recover the
579 message M unambiguously from the encoded message. (This
580 padding rule is taken from RFC 1423 [3].)
582 5. Encrypt the encoded message EM with the underlying block
583 cipher (DES or RC2) in cipher block chaining mode under the
584 encryption key K with initialization vector IV to produce the
585 ciphertext C. For DES, the key K shall be considered as a
586 64-bit encoding of a 56-bit DES key with parity bits ignored
587 (see [9]). For RC2, the "effective key bits" shall be 64
588 bits.
590 6. Output the ciphertext C.
592 The salt S and the iteration count c may be conveyed to the party
593 performing decryption in an AlgorithmIdentifier value (see Appendix
594 A.3).
596 6.1.2 Decryption operation
598 The decryption operation for PBES1 consists of the following steps,
599 which decrypt a ciphertext C under a password P to recover a message
600 M:
602 1. Obtain the eight-octet salt S and the iteration count c.
604 2. Apply the PBKDF1 key derivation function (Section 5.1) to the
605 password P, the salt S, and the iteration count c to produce
606 a derived key DK of length 16 octets:
608 DK = PBKDF1 (P, S, c, 16)
610 3. Separate the derived key DK into an encryption key K
611 consisting of the first eight octets of DK and an
612 initialization vector IV consisting of the next eight octets:
614 K = DK<0..7> ,
615 IV = DK<8..15> .
617 4. Decrypt the ciphertext C with the underlying block cipher
618 (DES or RC2) in cipher block chaining mode under the
619 encryption key K with initialization vector IV to recover an
620 encoded message EM. If the length in octets of the ciphertext
621 C is not a multiple of eight, output "decryption error" and
622 stop.
624 5. Separate the encoded message EM into a message M and a
625 padding string PS:
627 EM = M || PS ,
629 where the padding string PS consists of some number psLen
630 octets each with value psLen, where psLen is between 1 and 8.
631 If it is not possible to separate the encoded message EM in
632 this manner, output "decryption error" and stop.
634 6. Output the recovered message M.
636 6.2 PBES2
638 PBES2 combines a password-based key derivation function, which shall
639 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an
640 underlying encryption scheme (see Appendix B.2 for examples). The key
641 length and any other parameters for the underlying encryption scheme
642 depend on the scheme.
644 PBES2 is recommended for new applications.
646 6.2.1 Encryption operation
648 The encryption operation for PBES2 consists of the following steps,
649 which encrypt a message M under a password P to produce a ciphertext
650 C, applying a selected key derivation function KDF and a selected
651 underlying encryption scheme:
653 1. Select a salt S and an iteration count c, as outlined in
654 Section 4.
656 2. Select the length in octets, dkLen, for the derived key for
657 the underlying encryption scheme.
659 3. Apply the selected key derivation function to the password P,
660 the salt S, and the iteration count c to produce a derived
661 key DK of length dkLen octets:
663 DK = KDF (P, S, c, dkLen) .
665 4. Encrypt the message M with the underlying encryption scheme
666 under the derived key DK to produce a ciphertext C. (This
667 step may involve selection of parameters such as an
668 initialization vector and padding, depending on the
669 underlying scheme.)
671 5. Output the ciphertext C.
673 The salt S, the iteration count c, the key length dkLen, and
674 identifiers for the key derivation function and the underlying
675 encryption scheme may be conveyed to the party performing decryption
676 in an AlgorithmIdentifier value (see Appendix A.4).
678 6.2.2 Decryption operation
680 The decryption operation for PBES2 consists of the following steps,
681 which decrypt a ciphertext C under a password P to recover a message
682 M:
684 1. Obtain the salt S for the operation.
686 2. Obtain the iteration count c for the key derivation function.
688 3. Obtain the key length in octets, dkLen, for the derived key
689 for the underlying encryption scheme.
691 4. Apply the selected key derivation function to the password P,
692 the salt S, and the iteration count c to produce a derived
693 key DK of length dkLen octets:
695 DK = KDF (P, S, c, dkLen) .
697 5. Decrypt the ciphertext C with the underlying encryption
698 scheme under the derived key DK to recover a message M. If
699 the decryption function outputs "decryption error," then
700 output "decryption error" and stop.
702 6. Output the recovered message M.
704 7. Message authentication schemes
706 A message authentication scheme consists of a MAC (message
707 authentication code) generation operation and a MAC verification
708 operation, where the MAC generation operation produces a message
709 authentication code from a message under a key, and the MAC
710 verification operation verifies the message authentication code under
711 the same key. In a password-based message authentication scheme, the
712 key is a password.
714 One scheme is specified in this section: PBMAC1.
716 7.1 PBMAC1
718 PBMAC1 combines a password-based key derivation function, which shall
719 be PBKDF2 (Section 5.2) for this version of PKCS #5, with an
720 underlying message authentication scheme (see Appendix B.3 for an
721 example). The key length and any other parameters for the underlying
722 message authentication scheme depend on the scheme.
724 7.1.1 MAC generation
726 The MAC generation operation for PBMAC1 consists of the following
727 steps, which process a message M under a password P to generate a
728 message authentication code T, applying a selected key derivation
729 function KDF and a selected underlying message authentication scheme:
731 1. Select a salt S and an iteration count c, as outlined in
732 Section 4.
734 2. Select a key length in octets, dkLen, for the derived key for
735 the underlying message authentication function.
737 3. Apply the selected key derivation function to the password P,
738 the salt S, and the iteration count c to produce a derived
739 key DK of length dkLen octets:
741 DK = KDF (P, S, c, dkLen) .
743 4. Process the message M with the underlying message
744 authentication scheme under the derived key DK to generate a
745 message authentication code T.
747 5. Output the message authentication code T.
749 The salt S, the iteration count c, the key length dkLen, and
750 identifiers for the key derivation function and underlying message
751 authentication scheme may be conveyed to the party performing
752 verification in an AlgorithmIdentifier value (see Appendix A.5).
754 7.1.2 MAC verification
756 The MAC verification operation for PBMAC1 consists of the following
757 steps, which process a message M under a password P to verify a
758 message authentication code T:
760 1. Obtain the salt S and the iteration count c.
762 2. Obtain the key length in octets, dkLen, for the derived key
763 for the underlying message authentication scheme.
765 3. Apply the selected key derivation function to the password P,
766 the salt S, and the iteration count c to produce a derived
767 key DK of length dkLen octets:
769 DK = KDF (P, S, c, dkLen) .
771 4. Process the message M with the underlying message
772 authentication scheme under the derived key DK to verify the
773 message authentication code T.
775 5. If the message authentication code verifies, output
776 "correct"; else output "incorrect."
778 8. Security considerations
780 Password-based cryptography is generally limited in the security that
781 it can provide, particularly for methods such as those defined in
782 this document where off-line password search is possible. While the
783 use of salt and iteration count can increase the complexity of attack
784 (see Section 4 for recommendations), it is essential that passwords
785 are selected well, and relevant guidelines (e.g., [17]) should be
786 taken into account. It is also important that passwords be protected
787 well if stored.
789 In general, different keys should be derived from a password for
790 different uses to minimize the possibility of unintended
791 interactions. For password-based encryption with a single algorithm,
792 a random salt is sufficient to ensure that different keys will be
793 produced. In certain other situations, as outlined in Section 4, a
794 structured salt is necessary. The recommendations in Section 4 should
795 thus be taken into account when selecting the salt value.
797 9. Author's address
799 Burt Kaliski
800 RSA Laboratories
801 20 Crosby Drive
802 Bedford, MA 01730 USA
804 Email: bkaliski@rsasecurity.com
806 APPENDICES
808 A. ASN.1 syntax
810 This section defines ASN.1 syntax for the key derivation functions,
811 the encryption schemes, the message authentication scheme, and
812 supporting techniques. The intended application of these definitions
813 includes PKCS #8 and other syntax for key management, encrypted data,
814 and integrity-protected data. (Various aspects of ASN.1 are specified
815 in several ISO/IEC standards [9][10][11][12][13][14].)
817 The object identifier pkcs-5 identifies the arc of the OID tree from
818 which the PKCS #5-specific OIDs in this section are derived:
820 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549}
821 pkcs OBJECT IDENTIFIER ::= {rsadsi 1}
822 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5}
824 A.1 PBKDF1
826 No object identifier is given for PBKDF1, as the object identifiers
827 for PBES1 are sufficient for existing applications and PBKDF2 is
828 recommended for new applications.
830 A.2 PBKDF2
832 The object identifier id-PBKDF2 identifies the PBKDF2 key derivation
833 function (Section 5.2).
835 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12}
837 The parameters field associated with this OID in an
838 AlgorithmIdentifier shall have type PBKDF2-params:
840 PBKDF2-params ::= SEQUENCE {
841 salt CHOICE {
842 specified OCTET STRING,
843 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
844 },
845 iterationCount INTEGER (1..MAX),
846 keyLength INTEGER (1..MAX) OPTIONAL,
847 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT
848 algid-hmacWithSHA1 }
850 The fields of type PKDF2-params have the following meanings:
852 - salt specifies the salt value, or the source of the salt value.
853 It shall either be an octet string or an algorithm ID with an OID
854 in the set PBKDF2-SaltSources, which is reserved for future
855 versions of PKCS #5.
857 The salt-source approach is intended to indicate how the salt
858 value is to be generated as a function of parameters in the
859 algorithm ID, application data, or both. For instance, it may
860 indicate that the salt value is produced from the encoding of
861 a structure that specifies detailed information about the derived
862 key as suggested in Section 4.1. Some of the information may be
863 carried elsewhere, e.g., in the encryption algorithm ID. However,
864 such facilities are deferred to a future version of PKCS #5.
866 In this version, an application may achieve the benefits
867 mentioned in Section 4.1 by choosing a particular interpretation
868 of the salt value in the specified alternative.
870 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... }
872 - iterationCount specifies the iteration count. The maximum
873 iteration count allowed depends on the implementation. It is
874 expected that implementation profiles may further constrain the
875 bounds.
877 - keyLength, an optional field, is the length in octets of the
878 derived key. The maximum key length allowed depends on the
879 implementation; it is expected that implementation profiles may
880 further constrain the bounds. The field is provided for
881 convenience only; the key length is not cryptographically
882 protected. If there is concern about interaction between
883 operations with different key lengths for a given salt (see
884 Section 4.1), the salt should distinguishes among the different
885 key lengths.
887 - prf identifies the underlying pseudorandom function. It shall be
888 an algorithm ID with an OID in the set PBKDF2-PRFs, which for
889 this version of PKCS #5 shall consist of id-hmacWithSHA1 (see
890 Appendix B.1.1) and any other OIDs defined by the application.
892 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::=
893 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... }
895 The default pseudorandom function is HMAC-SHA-1:
897 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::=
898 {algorithm id-hmacWithSHA1, parameters NULL : NULL}
900 A.3 PBES1
902 Different object identifiers identify the PBES1 encryption scheme
903 (Section 6.1) according to the underlying hash function in the key
904 derivation function and the underlying block cipher, as summarized in
905 the following table:
907 Hash Function Block Cipher OID
908 MD2 DES pkcs-5.1
909 MD2 RC2 pkcs-5.4
910 MD5 DES pkcs-5.3
911 MD5 RC2 pkcs-5.6
912 SHA-1 DES pkcs-5.10
913 SHA-1 RC2 pkcs-5.11
915 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1}
916 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4}
917 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3}
918 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6}
919 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10}
920 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11}
922 For each OID, the parameters field associated with the OID in an
923 AlgorithmIdentifier shall have type PBEParameter:
925 PBEParameter ::= SEQUENCE {
926 salt OCTET STRING (SIZE(8)),
927 iterationCount INTEGER }
929 The fields of type PBEParameter have the following meanings:
931 - salt specifies the salt value, an eight-octet string.
933 - iterationCount specifies the iteration count.
935 A.4 PBES2
937 The object identifier id-PBES2 identifies the PBES2 encryption scheme
938 (Section 6.2).
940 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13}
942 The parameters field associated with this OID in an
943 AlgorithmIdentifier shall have type PBES2-params:
945 PBES2-params ::= SEQUENCE {
946 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}},
947 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} }
949 The fields of type PBES2-params have the following meanings:
951 - keyDerivationFunc identifies the underlying key derivation
952 function. It shall be an algorithm ID with an OID in the set
953 PBES2-KDFs, which for this version of PKCS #5 shall consist of
954 id-PBKDF2 (Appendix A.2).
956 PBES2-KDFs ALGORITHM-IDENTIFIER ::=
957 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }
959 - encryptionScheme identifies the underlying encryption scheme. It
960 shall be an algorithm ID with an OID in the set PBES2-Encs, whose
961 definition is left to the application. Example underlying
962 encryption schemes are given in Appendix B.2.
964 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... }
966 A.5 PBMAC1
968 The object identifier id-PBMAC1 identifies the PBMAC1 message
969 authentication scheme (Section 7.1).
971 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14}
973 The parameters field associated with this OID in an
974 AlgorithmIdentifier shall have type PBMAC1-params:
976 PBMAC1-params ::= SEQUENCE {
977 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}},
978 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} }
980 The keyDerivationFunc field has the same meaning as the corresponding
981 field of PBES2-params (Appendix A.4) except that the set of OIDs is
982 PBMAC1-KDFs.
984 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::=
985 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }
987 The messageAuthScheme field identifies the underlying message
988 authentication scheme. It shall be an algorithm ID with an OID in the
989 set PBMAC1-MACs, whose definition is left to the application. Example
990 underlying encryption schemes are given in Appendix B.3.
992 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... }
994 B. Supporting techniques
996 This section gives several examples of underlying functions and
997 schemes supporting the password-based schemes in Sections 5, 6 and 7.
999 While these supporting techniques are appropriate for applications to
1000 implement, none of them is required to be implemented. It is
1001 expected, however, that profiles for PKCS #5 will be developed that
1002 specify particular supporting techniques.
1004 This section also gives object identifiers for the supporting
1005 techniques. The object identifiers digestAlgorithm and
1006 encryptionAlgorithm identify the arcs from which certain algorithm
1007 OIDs referenced in this section are derived:
1009 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2}
1010 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3}
1012 B.1 Pseudorandom functions
1014 An example pseudorandom function for PBKDF2 (Section 5.2) is HMAC-
1015 SHA-1.
1017 B.1.1 HMAC-SHA-1
1019 HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC
1020 message authentication code [7] based on the SHA-1 hash function
1021 [18]. The pseudorandom function is the same function by which the
1022 message authentication code is computed, with a full-length output.
1023 (The first argument to the pseudorandom function PRF serves as HMAC's
1024 "key," and the second serves as HMAC's "text." In the case of PBKDF2,
1025 the "key" is thus the password and the "text" is the salt.) HMAC-
1026 SHA-1 has a variable key length and a 20-octet (160-bit) output
1027 value.
1029 Although the length of the key to HMAC-SHA-1 is essentially
1030 unbounded, the effective search space for pseudorandom function
1031 outputs may be limited by the structure of the function. In
1032 particular, when the key is longer than 512 bits, HMAC-SHA-1 will
1033 first hash it to 160 bits. Thus, even if a long derived key
1034 consisting of several pseudorandom function outputs is produced from
1035 a key, the effective search space for the derived key will be at most
1036 160 bits. Although the specific limitation for other key sizes
1037 depends on details of the HMAC construction, one should assume, to be
1038 conservative, that the effective search space is limited to 160 bits
1039 for other key sizes as well.
1041 (The 160-bit limitation should not generally pose a practical
1042 limitation in the case of password-based cryptography, since the
1043 search space for a password is unlikely to be greater than 160 bits.)
1045 The object identifier id-hmacWithSHA1 identifies the HMAC-SHA-1
1046 pseudorandom function:
1048 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
1050 The parameters field associated with this OID in an
1051 AlgorithmIdentifier shall have type NULL. This object identifier is
1052 employed in the object set PBKDF2-PRFs (Appendix A.2).
1054 Note. Although HMAC-SHA-1 was designed as a message authentication
1055 code, its proof of security is readily modified to accommodate
1056 requirements for a pseudorandom function, under stronger assumptions.
1058 A hash function may also meet the requirements of a pseudorandom
1059 function under certain assumptions. For instance, the direct
1060 application of a hash function to to the concatenation of the "key"
1061 and the "text" may be appropriate, provided that "text" has
1062 appropriate structure to prevent certain attacks. HMAC-SHA-1 is
1063 preferable, however, because it treats "key" and "text" as separate
1064 arguments and does not require "text" to have any structure.
1066 B.2 Encryption schemes
1068 Example pseudorandom functions for PBES2 (Section 6.2) are DES-CBC-
1069 Pad, DES-EDE2-CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad.
1071 The object identifiers given in this section are intended to be
1072 employed in the object set PBES2-Encs (Appendix A.4).
1074 B.2.1 DES-CBC-Pad
1076 DES-CBC-Pad is single-key DES [15] in CBC mode [16] with the RFC 1423
1077 padding operation (see Section 6.1.1). DES-CBC-Pad has an eight-octet
1078 encryption key and an eight-octet initialization vector. The key is
1079 considered as a 64-bit encoding of a 56-bit DES key with parity bits
1080 ignored.
1082 The object identifier desCBC (defined in the NIST/OSI Implementors'
1083 Workshop agreements) identifies the DES-CBC-Pad encryption scheme:
1085 desCBC OBJECT IDENTIFIER ::=
1086 {iso(1) identified-organization(3) oiw(14) secsig(3)
1087 algorithms(2) 7}
1089 The parameters field associated with this OID in an
1090 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)),
1091 specifying the initialization vector for CBC mode.
1093 B.2.2 DES-EDE3-CBC-Pad
1095 DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [1] with the RFC
1096 1423 padding operation. DES-EDE3-CBC-Pad has a 24-octet encryption
1097 key and an eight-octet initialization vector. The key is considered
1098 as the concatenation of three eight-octet keys, each of which is a
1099 64-bit encoding of a 56-bit DES key with parity bits ignored.
1101 The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad
1102 encryption scheme:
1104 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7}
1106 The parameters field associated with this OID in an
1107 AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)),
1108 specifying the initialization vector for CBC mode.
1110 Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52
1111 [1]; the one given here is preferred since it specifies padding.
1113 B.2.3 RC2-CBC-Pad
1115 RC2-CBC-Pad is the RC2(tm) encryption algorithm [21] in CBC mode with
1116 the RFC 1423 padding operation. RC2-CBC-Pad has a variable key
1117 length, from one to 128 octets, a separate "effective key bits"
1118 parameter from one to 1024 bits that limits the effective search
1119 space independent of the key length, and an eight-octet
1120 initialization vector.
1122 The object identifier rc2CBC identifies the RC2-CBC-Pad encryption
1123 scheme:
1125 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2}
1127 The parameters field associated with OID in an AlgorithmIdentifier
1128 shall have type RC2-CBC-Parameter:
1130 RC2-CBC-Parameter ::= SEQUENCE {
1131 rc2ParameterVersion INTEGER OPTIONAL,
1132 iv OCTET STRING (SIZE(8)) }
1134 The fields of type RC2-CBCParameter have the following meanings:
1136 - rc2ParameterVersion is a proprietary RSA Security Inc. encoding
1137 of the "effective key bits" for RC2. The following encodings are
1138 defined:
1140 Effective Key Bits Encoding
1141 40 160
1142 64 120
1143 128 58
1144 b >= 256 b
1146 If the rc2ParameterVersion field is omitted, the "effective key bits"
1147 defaults to 32. (This is for backward compatibility with certain very
1148 old implementations.)
1150 - iv is the eight-octet initialization vector.
1152 B.2.4 RC5-CBC-Pad
1154 RC5-CBC-Pad is the RC5(tm) encryption algorithm [20] in CBC mode with
1155 a generalization of the RFC 1423 padding operation. This scheme is
1156 fully specified in [2]. RC5-CBC-Pad has a variable key length, from 0
1157 to 256 octets, and supports both a 64-bit block size and a 128-bit
1158 block size. For the former, it has an eight-octet initialization
1159 vector, and for the latter, a 16-octet initialization vector. RC5-
1160 CBC-Pad also has a variable number of "rounds" in the encryption
1161 operation, from 8 to 127.
1163 Note: The generalization of the padding operation is as follows. For
1164 RC5 with a 64-bit block size, the padding string is as defined in RFC
1165 1423. For RC5 with a 128-bit block size, the padding string consists
1166 of 16-(||M|| mod 16) octets each with value 16-(||M|| mod 16).
1168 The object identifier rc5-CBC-PAD [2] identifies RC5-CBC-Pad
1169 encryption scheme:
1171 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9}
1173 The parameters field associated with this OID in an
1174 AlgorithmIdentifier shall have type RC5-CBC-Parameters:
1176 RC5-CBC-Parameters ::= SEQUENCE {
1177 version INTEGER {v1-0(16)} (v1-0),
1178 rounds INTEGER (8..127),
1179 blockSizeInBits INTEGER (64 | 128),
1180 iv OCTET STRING OPTIONAL }
1182 The fields of type RC5-CBC-Parameters have the following meanings:
1184 - version is the version of the algorithm, which shall be v1-0.
1186 - rounds is the number of rounds in the encryption operation,
1187 which shall be between 8 and 127.
1189 - blockSizeInBits is the block size in bits, which shall be 64 or
1190 128.
1192 - iv is the initialization vector, an eight-octet string for 64-bit
1193 RC5 and a 16-octet string for 128-bit RC5. The default is a
1194 string of the appropriate length consisting of zero octets.
1196 B.3 Message authentication schemes
1198 An example message authentication scheme for PBMAC1 (Section 7.1) is
1199 HMAC-SHA-1.
1201 B.3.1 HMAC-SHA-1
1203 HMAC-SHA-1 is the HMAC message authentication scheme [7] based on the
1204 SHA-1 hash function [18]. HMAC-SHA-1 has a variable key length and a
1205 20-octet (160-bit) message authentication code.
1207 The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies
1208 the HMAC-SHA-1 message authentication scheme. (The object identifier
1209 is the same for both the pseudorandom function and the message
1210 authentication scheme; the distinction is to be understood by
1211 context.) This object identifier is intended to be employed in the
1212 object set PBMAC1-Macs (Appendix A.5).
1214 C. ASN.1 module
1216 For reference purposes, the ASN.1 syntax in the preceding sections is
1217 presented as an ASN.1 module here.
1219 -- PKCS #5 v2.0 ASN.1 Module
1220 -- Revised March 25, 1999
1222 -- This module has been checked for conformance with the
1223 -- ASN.1 standard by the OSS ASN.1 Tools
1225 PKCS5v2-0 {iso(1) member-body(2) us(840) rsadsi(113549)
1226 pkcs(1) pkcs-5(5) modules(16) pkcs5v2-0(1)}
1228 DEFINITIONS ::= BEGIN
1230 -- Basic object identifiers
1232 rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549}
1233 pkcs OBJECT IDENTIFIER ::= {rsadsi 1}
1234 pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5}
1236 -- Basic types and classes
1238 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::=
1239 SEQUENCE {
1240 algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}),
1241 parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet}
1242 {@algorithm}) OPTIONAL
1243 }
1245 ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER
1247 -- PBKDF2
1249 PBKDF2Algorithms ALGORITHM-IDENTIFIER ::=
1250 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ...}
1252 id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12}
1254 algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::=
1255 {algorithm id-hmacWithSHA1, parameters NULL : NULL}
1257 PBKDF2-params ::= SEQUENCE {
1258 salt CHOICE {
1259 specified OCTET STRING,
1260 otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
1261 },
1262 iterationCount INTEGER (1..MAX),
1263 keyLength INTEGER (1..MAX) OPTIONAL,
1264 prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT
1265 algid-hmacWithSHA1
1266 }
1268 PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... }
1270 PBKDF2-PRFs ALGORITHM-IDENTIFIER ::=
1271 { {NULL IDENTIFIED BY id-hmacWithSHA1}, ... }
1273 -- PBES1
1275 PBES1Algorithms ALGORITHM-IDENTIFIER ::= {
1276 {PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} |
1277 {PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} |
1278 {PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} |
1279 {PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} |
1280 {PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} |
1281 {PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC},
1282 ...
1283 }
1285 pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1}
1286 pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4}
1287 pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3}
1288 pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6}
1289 pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10}
1290 pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11}
1292 PBEParameter ::= SEQUENCE {
1293 salt OCTET STRING (SIZE(8)),
1294 iterationCount INTEGER
1295 }
1297 -- PBES2
1299 PBES2Algorithms ALGORITHM-IDENTIFIER ::=
1300 { {PBES2-params IDENTIFIED BY id-PBES2}, ...}
1302 id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13}
1304 PBES2-params ::= SEQUENCE {
1305 keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}},
1306 encryptionScheme AlgorithmIdentifier {{PBES2-Encs}}
1307 }
1309 PBES2-KDFs ALGORITHM-IDENTIFIER ::=
1310 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }
1312 PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... }
1314 -- PBMAC1
1316 PBMAC1Algorithms ALGORITHM-IDENTIFIER ::=
1317 { {PBMAC1-params IDENTIFIED BY id-PBMAC1}, ...}
1319 id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14}
1321 PBMAC1-params ::= SEQUENCE {
1322 keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}},
1323 messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}}
1324 }
1326 PBMAC1-KDFs ALGORITHM-IDENTIFIER ::=
1327 { {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }
1329 PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... }
1331 -- Supporting techniques
1333 digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2}
1334 encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3}
1336 SupportingAlgorithms ALGORITHM-IDENTIFIER ::= {
1337 {NULL IDENTIFIED BY id-hmacWithSHA1} |
1338 {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} |
1339 {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} |
1340 {RC2-CBC-Parameter IDENTIFIED BY rc2CBC} |
1341 {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD},
1342 ...
1343 }
1345 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
1347 desCBC OBJECT IDENTIFIER ::=
1348 {iso(1) identified-organization(3) oiw(14) secsig(3)
1349 algorithms(2) 7} -- from OIW
1351 des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7}
1353 rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2}
1355 RC2-CBC-Parameter ::= SEQUENCE {
1356 rc2ParameterVersion INTEGER OPTIONAL,
1357 iv OCTET STRING (SIZE(8))
1358 }
1360 rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9}
1362 RC5-CBC-Parameters ::= SEQUENCE {
1363 version INTEGER {v1-0(16)} (v1-0),
1364 rounds INTEGER (8..127),
1365 blockSizeInBits INTEGER (64 | 128),
1366 iv OCTET STRING OPTIONAL
1367 }
1369 END
1371 D. Intellectual property considerations
1373 RSA Security makes no patent claims on the general constructions
1374 described in this document, although specific underlying techniques
1375 may be covered. Among the underlying techniques, the RC5 encryption
1376 algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428
1377 [22] and 5,835,600 [23].
1379 RC2 and RC5 are trademarks of RSA Security.
1381 License to copy this document is granted provided that it is
1382 identified as RSA Security Inc. Public-Key Cryptography Standards
1383 (PKCS) in all material mentioning or referencing this document.
1385 RSA Security makes no representations regarding intellectual property
1386 claims by other parties. Such determination is the responsibility of
1387 the user.
1389 E. Revision history
1391 Versions 1.0-1.3
1393 Versions 1.0-1.3 were distributed to participants in RSA Data
1394 Security Inc.'s Public-Key Cryptography Standards meetings in
1395 February and March 1991.
1397 Version 1.4
1399 Version 1.4 was part of the June 3, 1991 initial public release of
1400 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop
1401 document SEC-SIG-91-20.
1403 Version 1.5
1405 Version 1.5 incorporated several editorial changes, including
1406 updates to the references and the addition of a revision history.
1408 Version 2.0
1410 Version 2.0 incorporates major editorial changes in terms of the
1411 document structure, and introduces the PBES2 encryption scheme,
1412 the PBMAC1 message authentication scheme, and independent
1413 password-based key derivation functions. This version continues to
1414 support the encryption process in version 1.5.
1416 F. References
1418 [1] American National Standard X9.52 - 1998, Triple Data Encryption
1419 Algorithm Modes of Operation. Working draft, Accredited Standards
1420 Committee X9, July 27, 1998.
1422 [2] R. Baldwin and R. Rivest. RFC 2040: The RC5, RC5-CBC, RC5-CBC-
1423 Pad, and RC5-CTS Algorithms. IETF, October 1996.
1425 [3] D. Balenson. RFC 1423: Privacy Enhancement for Internet
1426 Electronic Mail: Part III: Algorithms, Modes, and Identifiers. IETF,
1427 February 1993.
1429 [4] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password-
1430 based protocols secure against dictionary attacks. In Proceedings of
1431 the 1992 IEEE Computer Society Conference on Research in Security and
1432 Privacy, pages 72-84, IEEE Computer Society, 1992.
1434 [5] D. Jablon. Strong password-only authenticated key exchange. ACM
1435 Computer Communications Review, October 1996.
1437 [6] B. Kaliski. RFC 1319: The MD2 Message-Digest Algorithm. IETF,
1438 April 1992.
1440 [7] H. Krawczyk, M. Bellare, and R. Canetti. RFC 2104: HMAC: Keyed-
1441 Hashing for Message Authentication. IETF, February 1997.
1443 [8] Robert Morris and Ken Thompson. Password security: A case
1444 history. Communications of the ACM, 22(11):594-597, November 1979.
1446 [9] ISO/IEC 8824-1:1995: Information technology - Abstract Syntax
1447 Notation One (ASN.1) - Specification of basic notation. 1995.
1449 [10] ISO/IEC 8824-1:1995/Amd.1:1995 Information technology - Abstract
1450 Syntax Notation One (ASN.1) - Specification of basic notation -
1451 Amendment 1 - Rules of extensibility. 1995.
1453 [11] ISO/IEC 8824-2:1995 Information technology - Abstract Syntax
1454 Notation One (ASN.1) - Information object specification. 1995.
1456 [12] ISO/IEC 8824-2:1995/Amd.1:1995 Information technology - Abstract
1457 Syntax Notation One (ASN.1) - Information object specification -
1458 Amendment 1 - Rules of extensibility. 1995.
1460 [13] ISO/IEC 8824-3:1995 Information technology - Abstract Syntax
1461 Notation One (ASN.1) - Constraint specification. 1995.
1463 [14] ISO/IEC 8824-4:1995 Information technology - Abstract Syntax
1464 Notation One (ASN.1) - Parameterization of ASN.1 specifications.
1465 1995.
1467 [15] National Institute of Standards and Technology (NIST). FIPS PUB
1468 46-2: Data Encryption Standard. December 30, 1993.
1470 [16] National Institute of Standards and Technology (NIST). FIPS PUB
1471 81: DES Modes of Operation. December 2, 1980.
1473 [17] National Institute of Standards and Technology (NIST). FIPS PUB
1474 112: Password Usage. May 30, 1985.
1476 [18] National Institute of Standards and Technology (NIST). FIPS PUB
1477 180-1: Secure Hash Standard. April 1994.
1479 [19] R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. IETF,
1480 April 1992.
1482 [20] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the
1483 Second International Workshop on Fast Software Encryption, pages 86-
1484 96, Springer-Verlag, 1994.
1486 [21] R. Rivest. RFC 2268: A Description of the RC2(r) Encryption
1487 Algorithm. IETF, March 1998.
1489 [22] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent
1490 Rotations. U.S. Patent No. 5,724,428, March 3, 1998.
1492 [23] R.L. Rivest. Block Encryption Algorithm with Data-Dependent
1493 Rotations. U.S. Patent No. 5,835,600, November 10, 1998.
1495 [24] RSA Laboratories. PKCS #5: Password-Based Encryption Standard.
1496 Version 1.5, November 1993.
1498 [25] RSA Laboratories. PKCS #8: Private-Key Information Syntax
1499 Standard. Version 1.2, November 1993.
1501 [26] T. Wu. The Secure Remote Password protocol. In Proceedings of
1502 the 1998 Internet Society Network and Distributed System Security
1503 Symposium, pages 97-111, Internet Society, 1998.
1505 [27] F. Yergeau. RFC 2279: UTF-8, a Transformation Format of ISO
1506 10646. IETF, January 1998.
1508 G. Contact information & About PKCS
1510 The Public-Key Cryptography Standards are specifications produced by
1511 RSA Laboratories in cooperation with secure systems developers
1512 worldwide for the purpose of accelerating the deployment of public-
1513 key cryptography. First published in 1991 as a result of meetings
1514 with a small group of early adopters of public-key technology, the
1515 PKCS documents have become widely referenced and implemented.
1516 Contributions from the PKCS series have become part of many formal
1517 and de facto standards, including ANSI X9 documents, PKIX, SET,
1518 S/MIME, and SSL.
1520 Further development of PKCS occurs through mailing list discussions
1521 and occasional workshops, and suggestions for improvement are
1522 welcome. For more information, contact:
1524 PKCS Editor
1525 RSA Laboratories
1526 20 Crosby Drive
1527 Bedford, MA 01730 USA
1528 pkcs-editor@rsasecurity.com
1529 http://www.rsalabs.com/pkcs/