< draft-moriarty-pkcs5-v2dot1-00.txt		draft-moriarty-pkcs5-v2dot1-01.txt >
	INTERNET-DRAFT K. Moriarty, Ed.		INTERNET-DRAFT K. Moriarty, Ed.
	Intended Status: Informational EMC		Intended Status: Informational EMC
	Obsoletes: 2898 (once approved) A. Rusch		Obsoletes: 2898 (once approved) B. Kaliski
	Expires: August 6, 2016 RSA		Expires: October 9, 2016 Verisign
	B. Kaliski		A. Rusch
	Verisign		RSA
	February 3, 2016		April 8, 2016
	PKCS #5: Password-Based Cryptography Specification		PKCS #5: Password-Based Cryptography Specification
	Version 2.1		Version 2.1
	draft-moriarty-pkcs5-v2dot1-00		draft-moriarty-pkcs5-v2dot1-01
	Abstract		Abstract
	This document provides recommendations for the implementation of		This document provides recommendations for the implementation of
	password-based cryptography, covering key derivation functions,		password-based cryptography, covering key derivation functions,
	encryption schemes, message-authentication schemes, and ASN.1 syntax		encryption schemes, message-authentication schemes, and ASN.1 syntax
	identifying the techniques.		identifying the techniques.
	The recommendations are intended for general application within		The recommendations are intended for general application within
	computer and communications systems, and as such include a fair		computer and communications systems, and as such include a fair
	skipping to change at line 139 ¶		skipping to change at line 139 ¶
	- key derivation functions		- key derivation functions
	- encryption schemes		- encryption schemes
	- message-authentication schemes		- message-authentication schemes
	- ASN.1 syntax identifying the techniques		- ASN.1 syntax identifying the techniques
	The recommendations are intended for general application within		The recommendations are intended for general application within
	computer and communications systems, and as such include a fair		computer and communications systems, and as such include a fair
	amount of flexibility. They are particularly intended for the		amount of flexibility. They are particularly intended for the
	protection of sensitive information such as private keys as in PKCS		protection of sensitive information such as private keys as in PKCS
	#8 [29][33]. It is expected that application standards and		#8 [PKCS8][RFC5958]. It is expected that application standards and
	implementation profiles based on these specifications may include		implementation profiles based on these specifications may include
	additional constraints.		additional constraints.
	Other cryptographic techniques based on passwords, such as password-		Other cryptographic techniques based on passwords, such as password-
	based key entity authentication and key establishment protocols		based key entity authentication and key establishment protocols
	[4][11][31] are outside the scope of this document. Guidelines for		[BELLOV][JABLON][WU] are outside the scope of this document.
	the selection of passwords are also outside the scope. This document		Guidelines for the selection of passwords are also outside the scope.
	supersedes PKCS #5 version 2.0 [28], but includes compatible		This document supersedes PKCS #5 version 2.0 [RFC2898], but includes
	techniques.		compatibletechniques.
	2. Notation		2. Notation
	C ciphertext, an octet string		C ciphertext, an octet string
	c iteration count, a positive integer		c iteration count, a positive integer
	DK derived key, an octet string		DK derived key, an octet string
	dkLen length in octets of derived key, a positive integer		dkLen length in octets of derived key, a positive integer
	skipping to change at line 215 ¶		skipping to change at line 215 ¶
	In many applications of public-key cryptography, user security is		In many applications of public-key cryptography, user security is
	ultimately dependent on one or more secret text values or passwords.		ultimately dependent on one or more secret text values or passwords.
	Since a password is not directly applicable as a key to any		Since a password is not directly applicable as a key to any
	conventional cryptosystem, however, some processing of the password		conventional cryptosystem, however, some processing of the password
	is required to perform cryptographic operations with it. Moreover, as		is required to perform cryptographic operations with it. Moreover, as
	passwords are often chosen from a relatively small space, special		passwords are often chosen from a relatively small space, special
	care is required in that processing to defend against search attacks.		care is required in that processing to defend against search attacks.
	A general approach to password-based cryptography, as described by		A general approach to password-based cryptography, as described by
	Morris and Thompson [14] for the protection of password tables, is to		Morris and Thompson [MORRIS] for the protection of password tables,
	combine a password with a salt to produce a key. The salt can be		is to combine a password with a salt to produce a key. The salt can
	viewed as an index into a large set of keys derived from the		be viewed as an index into a large set of keys derived from the
	password, and need not be kept secret. Although it may be possible		password, and need not be kept secret. Although it may be possible
	for an opponent to construct a table of possible passwords (a so-		for an opponent to construct a table of possible passwords (a so-
	called "dictionary attack"), constructing a table of possible keys		called "dictionary attack"), constructing a table of possible keys
	will be difficult, since there will be many possible keys for each		will be difficult, since there will be many possible keys for each
	password. An opponent will thus be limited to searching through		password. An opponent will thus be limited to searching through
	passwords separately for each salt.		passwords separately for each salt.
	Another approach to password-based cryptography is to construct key		Another approach to password-based cryptography is to construct key
	derivation techniques that are relatively expensive, thereby		derivation techniques that are relatively expensive, thereby
	increasing the cost of exhaustive search. One way to do this is to		increasing the cost of exhaustive search. One way to do this is to
	skipping to change at line 266 ¶		skipping to change at line 266 ¶
	output of the key derivation function. This approach might be		output of the key derivation function. This approach might be
	employed as part of key establishment in a session-oriented protocol.		employed as part of key establishment in a session-oriented protocol.
	Another application is password checking, where the output of the key		Another application is password checking, where the output of the key
	derivation function is stored (along with the salt and iteration		derivation function is stored (along with the salt and iteration
	count) for the purposes of subsequent verification of a password.		count) for the purposes of subsequent verification of a password.
	Throughout this document, a password is considered to be an octet		Throughout this document, a password is considered to be an octet
	string of arbitrary length whose interpretation as a text string is		string of arbitrary length whose interpretation as a text string is
	unspecified. In the interest of interoperability, however, it is		unspecified. In the interest of interoperability, however, it is
	recommended that applications follow some common text encoding rules.		recommended that applications follow some common text encoding rules.
	ASCII and UTF-8 [32] are two possibilities. (ASCII is a subset of		ASCII and UTF-8 [RFC2279] are two possibilities. (ASCII is a subset
	UTF-8.)		of UTF-8.)
	Although the selection of passwords is outside the scope of this		Although the selection of passwords is outside the scope of this
	document, guidelines have been published [20] that may well be taken		document, guidelines have been published [NISTSP63] that may well be
	into account.		taken into account.
	4. Salt and Iteration Count		4. Salt and Iteration Count
	Inasmuch as salt and iteration count are central to the techniques		Inasmuch as salt and iteration count are central to the techniques
	defined in this document, some further discussion is warranted.		defined in this document, some further discussion is warranted.
	4.1. Salt		4.1. Salt
	A salt in password-based cryptography has traditionally served the		A salt in password-based cryptography has traditionally served the
	purpose of producing a large set of keys corresponding to a given		purpose of producing a large set of keys corresponding to a given
	skipping to change at line 380 ¶		skipping to change at line 380 ¶
	An iteration count has traditionally served the purpose of increasing		An iteration count has traditionally served the purpose of increasing
	the cost of producing keys from a password, thereby also increasing		the cost of producing keys from a password, thereby also increasing
	the difficulty of attack. Mathematically, an iteration count of c		the difficulty of attack. Mathematically, an iteration count of c
	will increase the security strength of a password by log2(c)		will increase the security strength of a password by log2(c)
	bits against trial based attacks like brute force or dictionary		bits against trial based attacks like brute force or dictionary
	attacks.		attacks.
	Choosing a reasonable value for the iteration count depends on		Choosing a reasonable value for the iteration count depends on
	environment and circumstances, and varies from application to		environment and circumstances, and varies from application to
	application. This document follows the recommendations made in FIPS		application. This document follows the recommendations made in FIPS
	Special Publication 800-132 [21], which says "The iteration count		Special Publication 800-132 [NISTSP132], which says "The iteration
	shall be selected as large as possible, as long as the time required		count shall be selected as large as possible, as long as the time
	to generate the key using the entered password is acceptable for the		required to generate the key using the entered password is acceptable
	users. [...] A minimum iteration count of 1,000 is recommended. For		for the users. [...] A minimum iteration count of 1,000 is
	especially critical keys, or for very powerful systems or systems		recommended. For especially critical keys, or for very powerful
	where user-perceived performance is not critical, an iteration count		systems or systems where user-perceived performance is not critical,
	of 10,000,000 may be appropriate".		an iteration count of 10,000,000 may be appropriate".
	5. Key Derivation Functions		5. Key Derivation Functions
	A key derivation function produces a derived key from a base key and		A key derivation function produces a derived key from a base key and
	other parameters. In a password-based key derivation function, the		other parameters. In a password-based key derivation function, the
	base key is a password and the other parameters are a salt value and		base key is a password and the other parameters are a salt value and
	an iteration count, as outlined in Section 3.		an iteration count, as outlined in Section 3.
	The primary application of the password-based key derivation		The primary application of the password-based key derivation
	functions defined here is in the encryption schemes in Section 6 and		functions defined here is in the encryption schemes in Section 6 and
	skipping to change at line 425 ¶		skipping to change at line 425 ¶
	the iteration count and the key length to produce a derived		the iteration count and the key length to produce a derived
	key.		key.
	4. Output the derived key.		4. Output the derived key.
	Any number of keys may be derived from a password by varying the		Any number of keys may be derived from a password by varying the
	salt, as described in Section 3.		salt, as described in Section 3.
	5.1. PBKDF1		5.1. PBKDF1
	PBKDF1 applies a hash function, which shall be MD2 [12], MD5 [22] or		PBKDF1 applies a hash function, which shall be MD2 [RFC1319], MD5
	SHA-1 [17], to derive keys. The length of the derived key is bounded		[RFC1321] or SHA-1 [NIST180], to derive keys. The length of the
	by the length of the hash function output, which is 16 octets for MD2		derived key is bounded by the length of the hash function output,
	and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key		which is 16 octets for MD2 and MD5 and 20 octets for SHA-1. PBKDF1 is
	derivation process in PKCS #5 v1.5 [27].		compatible with the key derivation process in PKCS #5 v1.5
			[PKCS5_15].
	PBKDF1 is recommended only for compatibility with existing		PBKDF1 is recommended only for compatibility with existing
	applications since the keys it produces may not be large enough for		applications since the keys it produces may not be large enough for
	some applications.		some applications.
	PBKDF1 (P, S, c, dkLen)		PBKDF1 (P, S, c, dkLen)
	Options: Hash underlying hash function		Options: Hash underlying hash function
	Input: P password, an octet string		Input: P password, an octet string
	skipping to change at line 561 ¶		skipping to change at line 562 ¶
	be suitable encryption algorithms in that context.		be suitable encryption algorithms in that context.
	Two schemes are specified in this section: PBES1 and PBES2. PBES2 is		Two schemes are specified in this section: PBES1 and PBES2. PBES2 is
	recommended for new applications; PBES1 is included only for		recommended for new applications; PBES1 is included only for
	compatibility with existing applications, and is not recommended for		compatibility with existing applications, and is not recommended for
	new applications.		new applications.
	6.1. PBES1		6.1. PBES1
	PBES1 combines the PBKDF1 function (Section 5.1) with an underlying		PBES1 combines the PBKDF1 function (Section 5.1) with an underlying
	block cipher, which shall be either DES [15] or RC2(tm) [24] in CBC		block cipher, which shall be either DES [NIST46] or RC2(tm) [RFC2268]
	mode [16]. PBES1 is compatible with the encryption scheme in PKCS #5		in CBC mode [NIST81]. PBES1 is compatible with the encryption scheme
	v1.5 [27].		in PKCS #5 v1.5 [PKCS5_15].
	PBES1 is recommended only for compatibility with existing		PBES1 is recommended only for compatibility with existing
	applications, since it supports only two underlying encryption		applications, since it supports only two underlying encryption
	schemes, each of which has a key size (56 or 64 bits) that may not be		schemes, each of which has a key size (56 or 64 bits) that may not be
	large enough for some applications.		large enough for some applications.
	6.1.1. PBES Encryption Operation		6.1.1. PBES Encryption Operation
	The encryption operation for PBES1 consists of the following steps,		The encryption operation for PBES1 consists of the following steps,
	which encrypt a message M under a password P to produce a ciphertext		which encrypt a message M under a password P to produce a ciphertext
	skipping to change at line 609 ¶		skipping to change at line 610 ¶
	satisfy one of the following statements:		satisfy one of the following statements:
	PS = 01, if ||M|| mod 8 = 7 ;		PS = 01, if ||M|| mod 8 = 7 ;
	PS = 02 02, if ||M|| mod 8 = 6 ;		PS = 02 02, if ||M|| mod 8 = 6 ;
	...		...
	PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0.		PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0.
	The length in octets of the encoded message will be a multiple		The length in octets of the encoded message will be a multiple
	of eight and it will be possible to recover the message M		of eight and it will be possible to recover the message M
	unambiguously from the encoded message. (This padding rule is		unambiguously from the encoded message. (This padding rule is
	taken from RFC 1423 [3].)		taken from RFC 1423 [RFC1423].)
	5. Encrypt the encoded message EM with the underlying block cipher		5. Encrypt the encoded message EM with the underlying block cipher
	(DES or RC2) in cipher block chaining mode under the encryption		(DES or RC2) in cipher block chaining mode under the encryption
	key K with initialization vector IV to produce the ciphertext		key K with initialization vector IV to produce the ciphertext
	C. For DES, the key K shall be considered as a 64-bit encoding		C. For DES, the key K shall be considered as a 64-bit encoding
	of a 56-bit DES key with parity bits ignored (see [15]). For		of a 56-bit DES key with parity bits ignored (see [NIST46]).
	RC2, the "effective key bits" shall be 64 bits.		For RC2, the "effective key bits" shall be 64 bits.
	6. Output the ciphertext C.		6. Output the ciphertext C.
	The salt S and the iteration count c may be conveyed to the party		The salt S and the iteration count c may be conveyed to the party
	performing decryption in an AlgorithmIdentifier value (see Appendix		performing decryption in an AlgorithmIdentifier value (see Appendix
	A.3).		A.3).
	6.1.2. PBES1 Decryption Operation		6.1.2. PBES1 Decryption Operation
	The decryption operation for PBES1 consists of the following steps,		The decryption operation for PBES1 consists of the following steps,
	skipping to change at line 811 ¶		skipping to change at line 812 ¶
	5. If the message authentication code verifies, output "correct";		5. If the message authentication code verifies, output "correct";
	else output "incorrect."		else output "incorrect."
	8. Security Considerations		8. Security Considerations
	Password-based cryptography is generally limited in the security that		Password-based cryptography is generally limited in the security that
	it can provide, particularly for methods such as those defined in		it can provide, particularly for methods such as those defined in
	this document where off-line password search is possible. While the		this document where off-line password search is possible. While the
	use of salt and iteration count can increase the complexity of attack		use of salt and iteration count can increase the complexity of attack
	(see Section 4 for recommendations), it is essential that passwords		(see Section 4 for recommendations), it is essential that passwords
	are selected well, and relevant guidelines (e.g., [20]) should be		are selected well, and relevant guidelines (e.g., [NISTSP63]) should
	taken into account. It is also important that passwords be protected		be taken into account. It is also important that passwords be
	well if stored.		protected well if stored.
	In general, different keys should be derived from a password for		In general, different keys should be derived from a password for
	different uses to minimize the possibility of unintended		different uses to minimize the possibility of unintended
	interactions. For password-based encryption with a single algorithm,		interactions. For password-based encryption with a single algorithm,
	a random salt is sufficient to ensure that different keys will be		a random salt is sufficient to ensure that different keys will be
	produced. In certain other situations, as outlined in Section 4, a		produced. In certain other situations, as outlined in Section 4, a
	structured salt is necessary. The recommendations in Section 4 should		structured salt is necessary. The recommendations in Section 4 should
	thus be taken into account when selecting the salt value.		thus be taken into account when selecting the salt value.
	For information on security considerations for MD2 [12] see [34], for		For information on security considerations for MD2 [RFC1319] see
	MD5 [22] see [35], for SHA-1 [17] see [36].		[RFC6149], for MD5 [RFC1321] see [RFC6151], for SHA-1 [NIST180] see
			[RFC6194].
	9. IANA Considerations		9. IANA Considerations
	None.		None.
	A. ASN.1 Syntax		A. ASN.1 Syntax
	This section defines ASN.1 syntax for the key derivation functions,		This section defines ASN.1 syntax for the key derivation functions,
	the encryption schemes, the message authentication scheme, and		the encryption schemes, the message authentication scheme, and
	supporting techniques. The intended application of these definitions		supporting techniques. The intended application of these definitions
	includes PKCS #8 and other syntax for key management, encrypted data,		includes PKCS #8 and other syntax for key management, encrypted data,
	and integrity-protected data. (Various aspects of ASN.1 are specified		and integrity-protected data. (Various aspects of ASN.1 are specified
	in several ISO/IEC standards [7][8][9][10].)		in several ISO/IEC standards [ISO8824-1][ISO8824-2][ISO8824-3]
			[ISO8824-4].)
	The object identifier pkcs-5 identifies the arc of the OID tree from		The object identifier pkcs-5 identifies the arc of the OID tree from
	which the PKCS #5-specific OIDs in this section are derived:		which the PKCS #5-specific OIDs in this section are derived:
	rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549}		rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549}
	pkcs OBJECT IDENTIFIER ::= {rsadsi 1}		pkcs OBJECT IDENTIFIER ::= {rsadsi 1}
	pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5}		pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5}
	A.1. PBKDF1		A.1. PBKDF1
	skipping to change at line 1053 ¶		skipping to change at line 1056 ¶
	B.1. Pseudorandom functions		B.1. Pseudorandom functions
	Examples of pseudorandom function for PBKDF2 (Section 5.2) include		Examples of pseudorandom function for PBKDF2 (Section 5.2) include
	HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and		HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and
	SHA512/256. Applications may employ other schemes as well.		SHA512/256. Applications may employ other schemes as well.
	B.1.1. HMAC-SHA-1		B.1.1. HMAC-SHA-1
	HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC		HMAC-SHA-1 is the pseudorandom function corresponding to the HMAC
	message authentication code [13] based on the SHA-1 hash function		message authentication code [RFC2104] based on the SHA-1 hash
	[17]. The pseudorandom function is the same function by which the		function [NIST180]. The pseudorandom function is the same function
	message authentication code is computed, with a full-length output.		by which the message authentication code is computed, with a full-
	(The first argument to the pseudorandom function PRF serves as HMAC's		length output. (The first argument to the pseudorandom function PRF
	"key," and the second serves as HMAC's "text." In the case of PBKDF2,		serves as HMAC's "key," and the second serves as HMAC's "text." In
	the "key" is thus the password and the "text" is the salt.) HMAC-		the case of PBKDF2, the "key" is thus the password and the "text" is
	SHA-1 has a variable key length and a 20-octet (160-bit) output		the salt.) HMAC-SHA-1 has a variable key length and a 20-octet
	value.		(160-bit) output value.
	Although the length of the key to HMAC-SHA-1 is essentially		Although the length of the key to HMAC-SHA-1 is essentially
	unbounded, the effective search space for pseudorandom function		unbounded, the effective search space for pseudorandom function
	outputs may be limited by the structure of the function. In		outputs may be limited by the structure of the function. In
	particular, when the key is longer than 512 bits, HMAC-SHA-1 will		particular, when the key is longer than 512 bits, HMAC-SHA-1 will
	first hash it to 160 bits. Thus, even if a long derived key		first hash it to 160 bits. Thus, even if a long derived key
	consisting of several pseudorandom function outputs is produced from		consisting of several pseudorandom function outputs is produced from
	a key, the effective search space for the derived key will be at most		a key, the effective search space for the derived key will be at most
	160 bits. Although the specific limitation for other key sizes		160 bits. Although the specific limitation for other key sizes
	depends on details of the HMAC construction, one should assume, to be		depends on details of the HMAC construction, one should assume, to be
	skipping to change at line 1100 ¶		skipping to change at line 1103 ¶
	A hash function may also meet the requirements of a pseudorandom		A hash function may also meet the requirements of a pseudorandom
	function under certain assumptions. For instance, the direct		function under certain assumptions. For instance, the direct
	application of a hash function to to the concatenation of the "key"		application of a hash function to to the concatenation of the "key"
	and the "text" may be appropriate, provided that "text" has		and the "text" may be appropriate, provided that "text" has
	appropriate structure to prevent certain attacks. HMAC-SHA-1 is		appropriate structure to prevent certain attacks. HMAC-SHA-1 is
	preferable, however, because it treats "key" and "text" as separate		preferable, however, because it treats "key" and "text" as separate
	arguments and does not require "text" to have any structure.		arguments and does not require "text" to have any structure.
	During 2004 and 2005 there were a number of attacks on SHA-1 that		During 2004 and 2005 there were a number of attacks on SHA-1 that
	reduced its perceived effective strength against collision attacks to		reduced its perceived effective strength against collision attacks to
	62 bits instead of the expected 80 bits (e.g. Wang et al. [30],		62 bits instead of the expected 80 bits (e.g. Wang et al. [WANG],
	confirmed by M. Cochran [5]). However, since these attacks centered		confirmed by M. Cochran [COCHRAN]). However, since these attacks
	on finding collisions between values they are not a direct security		centered on finding collisions between values they are not a direct
	consideration here because the collision-resistant property is not		security consideration here because the collision-resistant property
	required by the HMAC authentication scheme.		is not required by the HMAC authentication scheme.
	B.1.2. HMAC-SHA-2		B.1.2. HMAC-SHA-2
	HMAC-SHA-2 refers to the set of pseudo-random functions corresponding		HMAC-SHA-2 refers to the set of pseudo-random functions corresponding
	to the HMAC message authentication code (now a FIPS standard [19])		to the HMAC message authentication code (now a FIPS standard
	based on the new SHA-2 functions (FIPS 180-4 [17]). HMAC-SHA-2 has a		[NIST198]) based on the new SHA-2 functions (FIPS 180-4 [NIST180]).
	variable key length and variable output value depending on the hash		HMAC-SHA-2 has a variable key length and variable output value
	function chosen (SHA-224, SHA-256, SHA-384, SHA-512, SHA -512/224,or		depending on the hash function chosen (SHA-224, SHA-256, SHA-384,
	SHA-512/256), that is 28, 32, 48, or 64 octets.		SHA-512, SHA -512/224, or SHA-512/256), that is 28, 32, 48, or 64
			octets.
	Using the new hash functions extends the search space for the		Using the new hash functions extends the search space for the
	produced keys. Where SHA-1 limits the search space to 20 octets,		produced keys. Where SHA-1 limits the search space to 20 octets,
	SHA-2 sets new limits of 28, 32, 48 and 64 octets.		SHA-2 sets new limits of 28, 32, 48 and 64 octets.
	Object identifiers for HMAC are defined as follows:		Object identifiers for HMAC are defined as follows:
	id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8}		id-hmacWithSHA224 OBJECT IDENTIFIER ::= {digestAlgorithm 8}
	id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9}		id-hmacWithSHA256 OBJECT IDENTIFIER ::= {digestAlgorithm 9}
	id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10}		id-hmacWithSHA384 OBJECT IDENTIFIER ::= {digestAlgorithm 10}
	id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11}		id-hmacWithSHA512 OBJECT IDENTIFIER ::= {digestAlgorithm 11}
	id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12}		id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= {digestAlgorithm 12}
	id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13}		id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= {digestAlgorithm 13}
	B.2. Encryption Schemes		B.2. Encryption Schemes
	An example encryption scheme for PBES2 (Section 6.2) is AES-CBC-Pad.		An example encryption scheme for PBES2 (Section 6.2) is AES-CBC-Pad.
	The schemes defined in PKCS #5 v2.0 [28], DES-CBC-Pad, DES-EDE3-CBC-		The schemes defined in PKCS #5 v2.0 [RFC2898], DES-CBC-Pad, DES-EDE3-
	Pad, RC2-CBC-Pad, and RC5-CBC-Pad, are still supported, but DES-CBC-		CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad, are still supported, but
	Pad, DES-EDE3-CBC-Pad, RC2-CBC-Pad are now considered legacy and		DES-CBC-Pad, DES-EDE3-CBC-Pad, RC2-CBC-Pad are now considered legacy
	should only be used for backwards compatibility reasons.		and should only be used for backwards compatibility reasons.
	The object identifiers given in this section are intended to be		The object identifiers given in this section are intended to be
	employed in the object set PBES2-Encs (Appendix A.4).		employed in the object set PBES2-Encs (Appendix A.4).
	B.2.1. DES-CBC-Pad		B.2.1. DES-CBC-Pad
	DES-CBC-Pad is single-key DES [15] in CBC mode [16] with the RFC 1423		DES-CBC-Pad is single-key DES [NIST46] in CBC mode [NIST81] with the
	[3] padding operation (see Section 6.1.1). DES-CBC-Pad has an eight-		RFC 1423 [RFC1423] padding operation (see Section 6.1.1). DES-CBC-Pad
	octet encryption key and an eight-octet initialization vector. The		has an eight- octet encryption key and an eight-octet initialization
	key is considered as a 64-bit encoding of a 56-bit DES key with		vector. The key is considered as a 64-bit encoding of a 56-bit DES
	parity bits ignored.		key with parity bits ignored.
	The object identifier desCBC (defined in the NIST/OSI Implementors'		The object identifier desCBC (defined in the NIST/OSI Implementors'
	Workshop agreements) identifies the DES-CBC-Pad encryption scheme:		Workshop agreements) identifies the DES-CBC-Pad encryption scheme:
	desCBC OBJECT IDENTIFIER ::=		desCBC OBJECT IDENTIFIER ::=
	{iso(1) identified-organization(3) oiw(14) secsig(3)		{iso(1) identified-organization(3) oiw(14) secsig(3)
	algorithms(2) 7}		algorithms(2) 7}
	The parameters field associated with this OID in an		The parameters field associated with this OID in an
	AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)),		AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)),
	specifying the initialization vector for CBC mode.		specifying the initialization vector for CBC mode.
	B.2.2. DES-EDE3-CBC-Pad		B.2.2. DES-EDE3-CBC-Pad
	DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [1] with the RFC		DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [ANSIX952] with
	1423 [3] padding operation. DES-EDE3-CBC-Pad has a 24-octet		the RFC 1423 [RFC1423] padding operation. DES-EDE3-CBC-Pad has a
	encryption key and an eight-octet initialization vector. The key is		24-octet encryption key and an eight-octet initialization vector. The
	considered as the concatenation of three eight-octet keys, each of		key is considered as the concatenation of three eight-octet keys,
	which is a 64-bit encoding of a 56-bit DES key with parity bits		each of which is a 64-bit encoding of a 56-bit DES key with parity
	ignored.		bits ignored.
	The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad		The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad
	encryption scheme:		encryption scheme:
	des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7}		des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7}
	The parameters field associated with this OID in an		The parameters field associated with this OID in an
	AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)),		AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)),
	specifying the initialization vector for CBC mode.		specifying the initialization vector for CBC mode.
	Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52		Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52
	[1]; the one given here is preferred since it specifies padding.		[ANSIX952]; the one given here is preferred since it specifies
			padding.
	B.2.3. RC2-CBC-Pad		B.2.3. RC2-CBC-Pad
	RC2-CBC-Pad is the RC2(tm) encryption algorithm [24] in CBC mode with		RC2-CBC-Pad is the RC2(tm) encryption algorithm [RFC2268] in CBC mode
	the RFC 1423 [3] padding operation. RC2-CBC-Pad has a variable key		with the RFC 1423 [RFC1423] padding operation. RC2-CBC-Pad has a
	length, from one to 128 octets, a separate "effective key bits"		variable key length, from one to 128 octets, a separate "effective
	parameter from one to 1024 bits that limits the effective search		key bits" parameter from one to 1024 bits that limits the effective
	space independent of the key length, and an eight-octet		search space independent of the key length, and an eight-octet
	initialization vector.		initialization vector.
	The object identifier rc2CBC identifies the RC2-CBC-Pad encryption		The object identifier rc2CBC identifies the RC2-CBC-Pad encryption
	scheme:		scheme:
	rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2}		rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2}
	The parameters field associated with OID in an AlgorithmIdentifier		The parameters field associated with OID in an AlgorithmIdentifier
	shall have type RC2-CBC-Parameter:		shall have type RC2-CBC-Parameter:
	skipping to change at line 1220 ¶		skipping to change at line 1225 ¶
	b >= 256 b		b >= 256 b
	If the rc2ParameterVersion field is omitted, the "effective key bits"		If the rc2ParameterVersion field is omitted, the "effective key bits"
	defaults to 32. (This is for backward compatibility with certain very		defaults to 32. (This is for backward compatibility with certain very
	old implementations.)		old implementations.)
	- iv is the eight-octet initialization vector.		- iv is the eight-octet initialization vector.
	B.2.4. RC5-CBC-Pad		B.2.4. RC5-CBC-Pad
	RC5-CBC-Pad is the RC5(tm) encryption algorithm [23] in CBC mode with		RC5-CBC-Pad is the RC5(tm) encryption algorithm [RC5] in CBC mode
	RFC 5652 [6] padding operation, which is a generalization of the RFC		with RFC 5652 [RFC5652] padding operation, which is a generalization
	1423 [3] padding operation. The scheme is fully specified in [2].		of the RFC 1423 [RFC1423] padding operation. The scheme is fully
	RC5-CBC-Pad has a variable key length, from 0 to 256 octets, and		specified in [RFC2040]. RC5-CBC-Pad has a variable key length, from 0
	supports both a 64-bit block size and a 128-bit block size. For the		to 256 octets, and supports both a 64-bit block size and a 128-bit
	former, it has an eight-octet initialization vector, and for the		block size. For the former, it has an eight-octet initialization
	latter, a 16-octet initialization vector. RC5-CBC-Pad also has a		vector, and for the latter, a 16-octet initialization vector.
	variable number of "rounds" in the encryption operation, from 8 to		RC5-CBC-Pad also has a variable number of "rounds" in the encryption
	127.		operation, from 8 to 127.
	Note: For RC5 with a 64-bit block size, the padding string is as		Note: For RC5 with a 64-bit block size, the padding string is as
	defined in RFC 1423 [3]. For RC5 with a 128-bit block size, the		defined in RFC 1423 [RFC1423]. For RC5 with a 128-bit block size, the
	padding string consists of 16-(||M|| mod 16) octets each with value		padding string consists of 16-(||M|| mod 16) octets each with value
	16-(||M|| mod 16).		16-(||M|| mod 16).
	The object identifier rc5-CBC-PAD [2] identifies RC5-CBC-Pad		The object identifier rc5-CBC-PAD [RFC2040] identifies RC5-CBC-Pad
	encryption scheme:		encryption scheme:
	rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9}		rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9}
	The parameters field associated with this OID in an		The parameters field associated with this OID in an
	AlgorithmIdentifier shall have type RC5-CBC-Parameters:		AlgorithmIdentifier shall have type RC5-CBC-Parameters:
	RC5-CBC-Parameters ::= SEQUENCE {		RC5-CBC-Parameters ::= SEQUENCE {
	version INTEGER {v1-0(16)} (v1-0),		version INTEGER {v1-0(16)} (v1-0),
	rounds INTEGER (8..127),		rounds INTEGER (8..127),
	skipping to change at line 1266 ¶		skipping to change at line 1271 ¶
	- blockSizeInBits is the block size in bits, which shall be 64 or		- blockSizeInBits is the block size in bits, which shall be 64 or
	128.		128.
	- iv is the initialization vector, an eight-octet string for		- iv is the initialization vector, an eight-octet string for
	64-bit RC5 and a 16-octet string for 128-bit RC5. The default		64-bit RC5 and a 16-octet string for 128-bit RC5. The default
	is a string of the appropriate length consisting of zero		is a string of the appropriate length consisting of zero
	octets.		octets.
	B.2.5. AES-CBC-Pad		B.2.5. AES-CBC-Pad
	AES-CBC-Pad is the AES encryption algorithm [18] in CBC mode with RFC		AES-CBC-Pad is the AES encryption algorithm [NIST197] in CBC mode
	5652 [6] padding operation. AES-CBC-Pad has a variable key length of		with RFC 5652 [RFC5652] padding operation. AES-CBC-Pad has a variable
	16, 24, or 32 octets and has a 16-octet block size. It has a 16-octet		key length of 16, 24, or 32 octets and has a 16-octet block size. It
	initialization vector.		has a 16-octet initialization vector.
	Note: For AES, the padding string consists of 16-(||M|| mod 16)		Note: For AES, the padding string consists of 16-(||M|| mod 16)
	octets each with value 16-(||M|| mod 16).		octets each with value 16-(||M|| mod 16).
	For AES, object identifiers are defined depending on key size and		For AES, object identifiers are defined depending on key size and
	operation mode. For example, the 16-octet (128 bit) key AES		operation mode. For example, the 16-octet (128 bit) key AES
	encryption scheme in CBC mode would be aes128-CBC-Pad identifying the		encryption scheme in CBC mode would be aes128-CBC-Pad identifying the
	AES-CBC-PAD encryption scheme using a 16-octet key:		AES-CBC-PAD encryption scheme using a 16-octet key:
	aes128-CBC-PAD OBJECT IDENTIFIER ::= {aes 2}		aes128-CBC-PAD OBJECT IDENTIFIER ::= {aes 2}
	skipping to change at line 1294 ¶		skipping to change at line 1299 ¶
	AlgorithmIdentifier shall have type OCTET STRING (SIZE(16)),		AlgorithmIdentifier shall have type OCTET STRING (SIZE(16)),
	specifying the initialization vector for CBC mode.		specifying the initialization vector for CBC mode.
	B.3. Message Authentication Schemes		B.3. Message Authentication Schemes
	An example message authentication scheme for PBMAC1 (Section 7.1) is		An example message authentication scheme for PBMAC1 (Section 7.1) is
	HMAC-SHA-1.		HMAC-SHA-1.
	B.3.1. HMAC-SHA-1		B.3.1. HMAC-SHA-1
	HMAC-SHA-1 is the HMAC message authentication scheme [13] based on		HMAC-SHA-1 is the HMAC message authentication scheme [RFC2104] based
	the SHA-1 hash function [17]. HMAC-SHA-1 has a variable key length		on the SHA-1 hash function [NIST180]. HMAC-SHA-1 has a variable key
	and a 20-octet (160-bit) message authentication code.		length and a 20-octet (160-bit) message authentication code.
	The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies		The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies
	the HMAC-SHA-1 message authentication scheme. (The object identifier		the HMAC-SHA-1 message authentication scheme. (The object identifier
	is the same for both the pseudorandom function and the message		is the same for both the pseudorandom function and the message
	authentication scheme; the distinction is to be understood by		authentication scheme; the distinction is to be understood by
	context.) This object identifier is intended to be employed in the		context.) This object identifier is intended to be employed in the
	object set PBMAC1-Macs (Appendix A.5).		object set PBMAC1-Macs (Appendix A.5).
	B.3.2. HMAC-SHA-2		B.3.2. HMAC-SHA-2
	HMAC-SHA-2 refers to the set of HMAC message authentication schemes		HMAC-SHA-2 refers to the set of HMAC message authentication schemes
	[19] based on the SHA-2 functions [17]. HMAC-SHA-2 has a variable key		[NIST198] based on the SHA-2 functions [NIST180]. HMAC-SHA-2 has a
	length and a message authentication code whose length is based on		variable key length and a message authentication code whose length
	the hash function chosen (SHA-224, SHA-256, SHA-384, SHA-512,		is based on the hash function chosen (SHA-224, SHA-256, SHA-384,
	SHA-512/224, or SHA-512/256giving 28, 32, 48 or 64 octets).		SHA-512, SHA-512/224, or SHA-512/256giving 28, 32, 48 or 64 octets).
	The object identifiers id-hmacWithSHA224, id-hmacWithSHA256, id-		The object identifiers id-hmacWithSHA224, id-hmacWithSHA256, id-
	hmacWithSHA384, id-hmacWithSHA512, id-hmacWithSHA512-224,and id-		hmacWithSHA384, id-hmacWithSHA512, id-hmacWithSHA512-224,and id-
	hmacWithSHA512-256 (see Appendix B.1.2) identify the HMAC-SHA-2		hmacWithSHA512-256 (see Appendix B.1.2) identify the HMAC-SHA-2
	schemes. The object identifiers are the same for both the		schemes. The object identifiers are the same for both the
	pseudo-random functions and the message authentication schemes; the		pseudo-random functions and the message authentication schemes; the
	distinction is to be understood by context. These object identifiers		distinction is to be understood by context. These object identifiers
	are intended to be employed in the object set PBMAC1-Macs (Appendix		are intended to be employed in the object set PBMAC1-Macs (Appendix
	A.5)		A.5)
	skipping to change at line 1537 ¶		skipping to change at line 1542 ¶
	aes256-CBC-PAD OBJECT IDENTIFIER ::= { aes 42 }		aes256-CBC-PAD OBJECT IDENTIFIER ::= { aes 42 }
	END		END
	D. Intellectual Property Considerations		D. Intellectual Property Considerations
	EMC Corporation makes no patent claims on the general constructions		EMC Corporation makes no patent claims on the general constructions
	described in this document, although specific underlying techniques		described in this document, although specific underlying techniques
	may be covered. Among the underlying techniques, the RC5 encryption		may be covered. Among the underlying techniques, the RC5 encryption
	algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428		algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428
	[25] and 5,835,600 [26].		[RBLOCK1] and 5,835,600 [RBLOCK2].
	RC2 and RC5 are trademarks of EMC Corporation.		RC2 and RC5 are trademarks of EMC Corporation.
	EMC Corporation makes no representation regarding intellectual		EMC Corporation makes no representation regarding intellectual
	property claims by other parties. Such determination is the		property claims by other parties. Such determination is the
	responsibility of the user.		responsibility of the user.
	E. Revision History		E. Revision History
	Versions 1.0-1.3		Versions 1.0-1.3
	skipping to change at line 1588 ¶		skipping to change at line 1593 ¶
	with the hash functions SHA-224, SHA-256, SHA-384, SHA-512,		with the hash functions SHA-224, SHA-256, SHA-384, SHA-512,
	SHA-512/224, and SHA512/256 as pseudo-random functions for PBKDF2		SHA-512/224, and SHA512/256 as pseudo-random functions for PBKDF2
	and message authentication schemes for PBMAC1.		and message authentication schemes for PBMAC1.
	o Replacement of RSA with EMC in the "Intellectual Property		o Replacement of RSA with EMC in the "Intellectual Property
	Considerations".		Considerations".
	o Changes references to PKCS #5 and PKCS #8 to RSA 2898 and RFC		o Changes references to PKCS #5 and PKCS #8 to RSA 2898 and RFC
	5208/5898.		5208/5898.
	o Incorporates two editorial errata reported on PKCS #5 [28].		o Incorporates two editorial errata reported on PKCS #5 [RFC2898].
	o Added security considerations for MD2, MD5, and SHA-1.		o Added security considerations for MD2, MD5, and SHA-1.
	F. References		F. References
	F.1 Normative References		F.1 Normative References
	[1] American National Standard X9.52 - 1998, Triple Data Encryption		[ANSIX952]
			American National Standard X9.52 - 1998, Triple Data Encryption
	Algorithm Modes of Operation. Working draft, Accredited		Algorithm Modes of Operation. Working draft, Accredited
	Standards Committee X9, July 27, 1998.		Standards Committee X9, July 27, 1998.
	[2] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and		[BELLOV]
	RC5-CTS Algorithms", RFC 2040, October 1996.		S.M. Bellovin and M. Merritt. Encrypted key exchange: Password-
	[3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
	Part III: Algorithms, Modes, and Identifiers", RFC 1423,
	February 1993.
	[4] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password-
	based protocols secure against dictionary attacks. In		based protocols secure against dictionary attacks. In
	Proceedings of the 1992 IEEE Computer Society Conference on		Proceedings of the 1992 IEEE Computer Society Conference on
	Research in Security and Privacy, pages 72-84, IEEE Computer		Research in Security and Privacy, pages 72-84, IEEE Computer
	Society, 1992.		Society, 1992.
	[5] M. Cochran. Notes on the Wang et al. 2^63 SHA-1 Differential		[COCHRAN]
			M. Cochran. Notes on the Wang et al. 2^63 SHA-1 Differential
	Path. International Association for Cryptologic Research, ePrint		Path. International Association for Cryptologic Research, ePrint
	Archive. August 2008. Available from		Archive. August 2008. Available from
	http://eprint.iacr.org/2007/474		<http://eprint.iacr.org/2007/474>
	[6] R. Housley. RFC 5652: Cryptographic Message Syntax. IETF,
	September 2009.
	[7] ISO/IEC 8824-1: 2008: Information technology - Abstract Syntax		[ISO8824-1]
			ISO/IEC 8824-1: 2008: Information technology - Abstract Syntax
	Notation One (ASN.1) - Specification of basic notation. 2008.		Notation One (ASN.1) - Specification of basic notation. 2008.
	[8] ISO/IEC 8824-2: 2008: Information technology - Abstract Syntax		[ISO8824-2]
			ISO/IEC 8824-2: 2008: Information technology - Abstract Syntax
	Notation One (ASN.1) - Information object specification. 2008.		Notation One (ASN.1) - Information object specification. 2008.
	[9] ISO/IEC 8824-3: 2008: Information technology - Abstract Syntax		[ISO8824-3]
			ISO/IEC 8824-3: 2008: Information technology - Abstract Syntax
	Notation One (ASN.1) - Constraint specification. 2008.		Notation One (ASN.1) - Constraint specification. 2008.
	[10] ISO/IEC 8824-4: 2008: Information technology - Abstract Syntax		[ISO8824-4]
			ISO/IEC 8824-4: 2008: Information technology - Abstract Syntax
	Notation One (ASN.1) - Parameterization of ASN.1 specifications.		Notation One (ASN.1) - Parameterization of ASN.1 specifications.
	2008.		2008.
	[11] D. Jablon. Strong password-only authenticated key exchange. ACM		[JABLON]
			D. Jablon. Strong password-only authenticated key exchange. ACM
	Computer Communications Review, October 1996.		Computer Communications Review, October 1996.
	[12] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April		[MORRIS]
	1992.		Robert Morris and Ken Thompson. Password security: A case
	[13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
	for Message Authentication", RFC 2104, February 1997.
	[14] Robert Morris and Ken Thompson. Password security: A case
	history. Communications of the ACM, 22(11):594-597, November		history. Communications of the ACM, 22(11):594-597, November
	1979.		1979.
	[15] National Institute of Standards and Technology (NIST). FIPS PUB		[NIST46]
			National Institute of Standards and Technology (NIST). FIPS PUB
	46-3: Data Encryption Standard. October 1999.		46-3: Data Encryption Standard. October 1999.
	[16] National Institute of Standards and Technology (NIST). FIPS PUB		[NIST81]
			National Institute of Standards and Technology (NIST). FIPS PUB
	81: DES Modes of Operation. December 2, 1980.		81: DES Modes of Operation. December 2, 1980.
	[17] National Institute of Standards and Technology (NIST). FIPS PUB		[NIST180]
			National Institute of Standards and Technology (NIST). FIPS PUB
	180-4: Secure Hash Standard. March 2012.		180-4: Secure Hash Standard. March 2012.
	[18] National Institute of Standards and Technology (NIST). FIPS		[NIST197]
	Publication 197: Advance Encryption Standard (AES). November		National Institute of Standards and Technology (NIST). FIPS PUB
	2001.		197: Advance Encryption Standard (AES). November 2001.
	[19] National Institute of Standards and Technology (NIST). FIPS		[NIST198]
			National Institute of Standards and Technology (NIST). FIPS
	Publication 198-1: The Keyed - Hash Message Authentication Code		Publication 198-1: The Keyed - Hash Message Authentication Code
	(HMAC). July 2008.		(HMAC). July 2008.
	[20] National Institute of Standards and Technology (NIST). Special		[NISTSP63]
			National Institute of Standards and Technology (NIST). Special
	Publication 800-63-2: Electronic Authentication Guideline,		Publication 800-63-2: Electronic Authentication Guideline,
	Appendix A. August 2013.		Appendix A. August 2013.
	[21] National Institute of Standards and Technology (NIST). Special		[NISTSP132]
			National Institute of Standards and Technology (NIST). Special
	Publication 800-132: Recommendation for Password - Based Key		Publication 800-132: Recommendation for Password - Based Key
	Derivation, Part 1: Storage Applications. December 2010.		Derivation, Part 1: Storage Applications. December 2010.
	[22] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April		[PKCS5_15]
	1992.		RSA Laboratories. PKCS #5: Password-Based Encryption Standard
			Version 1.5, November 1993.
	[23] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the		[PKCS8]
			RSA Laboratories. "PKCS #8: Private-Key Information Syntax
			Standard Version 1.2", RFC 5208, May 2008.
			[RBLOCK1]
			R.L. Rivest. Block-Encryption Algorithm with Data-Dependent
			Rotations. U.S. Patent No. 5,724,428, March 3, 1998.
			[RBLOCK2]
			R.L. Rivest. Block Encryption Algorithm with Data-Dependent
			Rotations. U.S. Patent No. 5,835,600, November 10, 1998.
			[RC5]
			R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the
	Second International Workshop on Fast Software Encryption, pages		Second International Workshop on Fast Software Encryption, pages
	86-96, Springer-Verlag, 1994.		86-96, Springer-Verlag, 1994.
	[24] Rivest, R., "A Description of the RC2(r) Encryption Algorithm",		[RFC1319]
	RFC 2268, March 1998.		Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April
			1992,
			<http://www.rfc-editor.org/info/rfc1319>.
	[25] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent		[RFC1321]
	Rotations. U.S. Patent No. 5,724,428, March 3, 1998.		Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
			1992,
			<http://www.rfc-editor.org/info/rfc1321>.
	[26] R.L. Rivest. Block Encryption Algorithm with Data-Dependent		[RFC1423]
	Rotations. U.S. Patent No. 5,835,600, November 10, 1998.		Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
			Part III: Algorithms, Modes, and Identifiers", RFC 1423,
			February 1993,
			<http://www.rfc-editor.org/info/rfc1423>.
	[27] RSA Laboratories. PKCS #5: Password-Based Encryption Standard		[RFC2040]
	Version 1.5, November 1993.		Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
			RC5-CTS Algorithms", RFC 2040, October 1996,
			<http://www.rfc-editor.org/info/rfc2040>.
	[28] B. Kaliski., "PKCS #5: Password-Based Encryption Standard		[RFC2104]
	Version 2.0", RFC 2898, September 2000.		Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
			for Message Authentication", RFC 2104, February 1997,
			<http://www.rfc-editor.org/info/rfc2104>.
	[29] RSA Laboratories. "PKCS #8: Private-Key Information Syntax		[RFC2268]
	Standard Version 1.2", RFC 5208, May 2008.		Rivest, R., "A Description of the RC2(r) Encryption Algorithm",
			RFC 2268, March 1998,
			<http://www.rfc-editor.org/info/rfc2268>.
	[30] X. Wang, A.C. Yao, and F. Yao. Cryptanalysis on SHA-1.		[RFC2279]
	Presented by Adi Shamir at the rump session of CRYPTO 2005.		Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
	Slides may be found currently at		2279, January 1998,
	http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-		<http://www.rfc-editor.org/info/rfc2279>.
	Result.pdf
	[31] T. Wu. The Secure Remote Password protocol. In Proceedings of		[RFC2898]
	the 1998 Internet Society Network and Distributed System		B. Kaliski., "PKCS #5: Password-Based Encryption Standard
	Security Symposium, pages 97-111, Internet Society, 1998.		Version 2.0", RFC 2898, September 2000,
			<http://www.rfc-editor.org/info/rfc2898>.
	[32] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC		[RFC5652]
	2279, January 1998.		R. Housley. RFC 5652: Cryptographic Message Syntax. IETF,
			September 2009,
			<http://www.rfc-editor.org/info/rfc5652>.
	[33] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.		[RFC5958]
			Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010,
			<http://www.rfc-editor.org/info/rfc5958>.
	[34] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149,		[RFC6149]
	March 2011.		Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149,
			March 2011,
			<http://www.rfc-editor.org/info/rfc6149>.
	[35] Turner, S. and L. Chen, "Updated Security Considerations for the		[RFC6151]
			Turner, S. and L. Chen, "Updated Security Considerations for the
	MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March		MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March
	2011.		2011,
			<http://www.rfc-editor.org/info/rfc6151>.
	[36] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security		[RFC6194]
			Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
	Considerations for the SHA-0 and SHA-1 Message-Digest		Considerations for the SHA-0 and SHA-1 Message-Digest
	Algorithms", RFC 6194, March 2011.		Algorithms", RFC 6194, March 2011,
			<http://www.rfc-editor.org/info/rfc6194>.
			[WANG]
			X. Wang, A.C. Yao, and F. Yao. Cryptanalysis on SHA-1.
			Presented by Adi Shamir at the rump session of CRYPTO 2005.
			Slides may be found currently at
			<http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-
			Result.pdf>
			[WU]
			T. Wu. The Secure Remote Password protocol. In Proceedings of
			the 1998 Internet Society Network and Distributed System
			Security Symposium, pages 97-111, Internet Society, 1998.
	G. About PKCS		G. About PKCS
	The Public-Key Cryptography Standards are specifications produced by		The Public-Key Cryptography Standards are specifications produced by
	RSA Laboratories in cooperation with secure systems developers		RSA Laboratories in cooperation with secure systems developers
	worldwide for the purpose of accelerating the deployment of public-		worldwide for the purpose of accelerating the deployment of public-
	key cryptography. First published in 1991 as a result of meetings		key cryptography. First published in 1991 as a result of meetings
	with a small group of early adopters of public-key technology, the		with a small group of early adopters of public-key technology, the
	PKCS documents have become widely referenced and implemented.		PKCS documents have become widely referenced and implemented.
	Contributions from the PKCS series have become part of many formal		Contributions from the PKCS series have become part of many formal
	and de facto standards, including ANSI X9 documents, PKIX, SET,		and de facto standards, including ANSI X9 documents, PKIX, SET,
	S/MIME, and SSL.		S/MIME, and SSL.
	Further development of PKCS occurs through the IETF. Suggestions for		Further development of most PKCS documents occurs through the IETF.
	improvement are welcome.		Suggestions for improvement are welcome.
			H. Acknowledgements
			This document is based on a contribution of RSA Laboratories, the
			research center of RSA Security Inc.
	Authors' Addresses		Authors' Addresses
	Kathleen M. Moriarty (editor)		Kathleen M. Moriarty (editor)
	EMC Corporation		EMC Corporation
	176 South Street		176 South Street
	Hopkinton, MA		Hopkinton, MA 01748
	United States		US
	Email: Kathleen.Moriarty@emc.com
	Andreas Rusch
	RSA Security Inc.
	345 Queen Street
	Brisbane, QLD, 4000
	Australia
	EMail: Andreas.Rusch@rsa.com		Email: kathleen.moriarty@emc.com
	Burt Kaliski		Burt Kaliski
	Verisign		Verisign
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA		Reston, VA 20190
	United States		US
	EMail: bkaliski@verisign.com		Email: bkaliski@verisign.com
			URI: http://verisignlabs.com
			Andreas Rusch
			RSA
			345 Queen Street
			Brisbane, QLD 4000
			AU
			Email: andreas.rusch@rsa.com
End of changes. 70 change blocks.
	187 lines changed or deleted		237 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/