draft-ietf-smime-password-02.txt   draft-ietf-smime-password-03.txt 
Internet Draft Editor: Peter Gutmann Internet Draft Editor: Peter Gutmann
draft-ietf-smime-password-02.txt University of Auckland draft-ietf-smime-password-03.txt University of Auckland
March 2, 2000 October 21, 2000
Expires September 2000 Expires April 2001
Password-based Encryption for S/MIME Password-based Encryption for S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 30 skipping to change at line 31
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Cryptographic Message Syntax data format doesn't currently contain The Cryptographic Message Syntax data format doesn't currently
any provisions for password-based data encryption. This document contain any provisions for password-based data encryption. This
provides a method of encrypting data using user-supplied passwords and, document provides a method of encrypting data using user-supplied
by extension, any form of variable-length keying material which isn't passwords and, by extension, any form of variable-length keying
necessarily an algorithm-specific fixed-format key. material which isn't necessarily an algorithm-specific fixed-format
key.
This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with the
single word "subscribe" in the body of the message. Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime>.
1. Introduction 1. Introduction
This document describes a password-based content encryption mechanism This document describes a password-based content encryption mechanism
for S/MIME. This is implemented as a new RecipientInfo type and is an for S/MIME. This is implemented as a new RecipientInfo type and is
extension to the RecipientInfo types currently defined in RFC 2640 an extension to the RecipientInfo types currently defined in RFC 2640
[RFC2640]. [RFC2640].
The format of the messages are described in ASN.1:1994 [ASN1]. The format of the messages are described in ASN.1 [ASN1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.1 Password-based Content Encryption 1.1 Password-based Content Encryption
CMS currently defined three recipient information types for public-key CMS currently defined three recipient information types for public-
key wrapping (KeyTransRecipientInfo), conventional key wrapping key key wrapping (KeyTransRecipientInfo), conventional key wrapping
(KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The
recipient information described here adds a fourth type, recipient information described here adds a fourth type,
PasswordRecipientInfo, which provides for password-based key wrapping. PasswordRecipientInfo, which provides for password-based key
wrapping.
1.2 RecipientInfo Types 1.2 RecipientInfo Types
The new recipient information type is an extension to the RecipientInfo The new recipient information type is an extension to the
type defined in section 6.2 of CMS, extending the types to: RecipientInfo type defined in section 6.2 of CMS, extending the types
to:
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo, kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type pwri [3] PasswordRecipientinfo -- New RecipientInfo type
} }
Although the recipient information generation process is described in Although the recipient information generation process is described in
terms of a password-based operation (since this will be its most common terms of a password-based operation (since this will be its most
use), the transformation employed is a general-purpose key derivation common use), the transformation employed is a general-purpose key
one which allows any type of keying material to be converted into a key derivation one which allows any type of keying material to be
specific to a particular content-encryption algorithm. Since the most converted into a key specific to a particular content-encryption
common use for password-based encryption is to encrypt files which are algorithm. Since the most common use for password-based encryption
stored locally (rather than being transmitted across a network), the is to encrypt files which are stored locally (rather than being
term "recipient" is somewhat misleading, but is used here because the transmitted across a network), the term "recipient" is somewhat
other key transport mechanisms have always been described in similar misleading, but is used here because the other key transport
terms. mechanisms have always been described in similar terms.
1.2.1 PasswordRecipientInfo Type 1.2.1 PasswordRecipientInfo Type
Recipient information using a user-supplied password or previously Recipient information using a user-supplied password or previously
agreed-upon key is represented in the type PasswordRecipientInfo. Each agreed-upon key is represented in the type PasswordRecipientInfo.
instance of PasswordRecipientInfo will transfer the content-encryption Each instance of PasswordRecipientInfo will transfer the content-
key (CEK) to one or more recipients who have the previously agreed-upon encryption key (CEK) to one or more recipients who have the
password or key-encryption key (KEK). previously agreed-upon password or key-encryption key (KEK).
PasswordRecipientInfo ::= SEQUENCE { PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0 version CMSVersion, -- Always set to 0
keyDerivationAlgorithm keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL, [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
The fields of type PasswordRecipientInfo have the following meanings: The fields of type PasswordRecipientInfo have the following meanings:
version is the syntax version number. It shall always be 0. version is the syntax version number. It shall always be 0.
keyDerivationAlgorithm identifies the key-derivation algorithm, and keyDerivationAlgorithm identifies the key-derivation algorithm, and
any associated parameters, used to derive the KEK from the any associated parameters, used to derive the KEK from the user-
user-supplied password. If this field is absent, the KEK is supplied supplied password. If this field is absent, the KEK is supplied
from an external source, for example a crypto token such as a smart from an external source, for example a crypto token such as a smart
card. card.
keyEncryptionAlgorithm identifies the content-encryption algorithm, keyEncryptionAlgorithm identifies the content-encryption algorithm,
and any associated parameters, used to encrypt the CEK with the KEK. and any associated parameters, used to encrypt the CEK with the
KEK.
encryptedKey is the result of encrypting the content-encryption key encryptedKey is the result of encrypting the content-encryption key
with the KEK. with the KEK.
1.2.2 Rationale 1.2.2 Rationale
Password-based key wrapping is a two-stage process, a first stage in Password-based key wrapping is a two-stage process, a first stage in
which a user-supplied password is converted into a KEK if required, and which a user-supplied password is converted into a KEK if required,
a second stage in which the KEK is used to encrypt a CEK. These two and a second stage in which the KEK is used to encrypt a CEK. These
stages are identified by the two algorithm identifiers. Although the two stages are identified by the two algorithm identifiers. Although
PKCS #5 standard goes one step further to wrap these up into a single the PKCS #5v2 standard [RFC 2898] goes one step further to wrap these
algorithm identifier, this design is particular to that standard and up into a single algorithm identifier, this design is particular to
may not be applicable for other key wrapping mechanisms. For this that standard and may not be applicable for other key wrapping
reason the two steps are specified separately. mechanisms. For this reason the two steps are specified separately.
2 Supported Algorithms 2 Supported Algorithms
This section lists the algorithms that must be implemented. Additional This section lists the algorithms that must be implemented.
algorithms that should be implemented are also included. Additional algorithms that should be implemented are also included.
2.1 Key Derivation Algorithms 2.1 Key Derivation Algorithms
These algorithms are used to convert the password into a KEK. The key These algorithms are used to convert the password into a KEK. The
derivation algorithms are: key derivation algorithms are:
KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
{ SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
...
}
CMS implementations MUST include PBKDF2 [PKCS5v2]. CMS implementations MUST include PBKDF2 [RFC2898]. Appendix B
contains a more precise definition of the allowed algorithm type than
is possible using 1988 ASN.1.
2.2 Key Encryption Algorithms 2.2 Key Encryption Algorithms
These algorithms are used to encrypt the content (the key) using the These algorithms are used to encrypt the content (the key) using the
derived KEK. The content encryption algorithms are: derived KEK. The content encryption algorithms are PBES2-Encs [RFC
2898]. Appendix B contains a more precise definition of the allowed
KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs algorithm types than is possible using 1988 ASN.1.
CMS implementations MUST include Triple-DES in CBC mode, SHOULD include CMS implementations MUST include Triple-DES in CBC mode, SHOULD
RC2 in CBC mode, and MAY include other algorithms such as CAST-128, include RC2 in CBC mode, and MAY include other algorithms such as
RC5, IDEA, Skipjack, and encryption modes as required. CMS AES, CAST-128, RC5, IDEA, Skipjack, Blowfish, and encryption modes as
implementations SHOULD NOT include any KSG ciphers such as RC4 or a required. CMS implementations SHOULD NOT include any KSG ciphers
block cipher in OFB mode, and SHOULD NOT include a block cipher in ECB such as RC4 or a block cipher in OFB mode, and SHOULD NOT include a
mode. The use of RC2 has special requirements, see section 2.4 for block cipher in ECB mode. The use of RC2 has special requirements,
details. see section 2.4 for details.
2.3 Symmetric Key Encryption Algorithms 2.3 Symmetric Key Encryption Algorithms
The key wrap algorithm is used to wrap the CEK with the KEK. There is The key wrap algorithm is used to wrap the CEK with the KEK. There
no requirement that the content-encryption algorithm match the KEK is no requirement that the content-encryption algorithm match the KEK
algorithm, although care should be taken to ensure that, if different algorithm, although care should be taken to ensure that, if different
algorithms are used, they offer an equivalent level of security (for algorithms are used, they offer an equivalent level of security (for
example wrapping a Triple-DES key with an RC2/40 key leads to a severe example wrapping a Triple-DES key with an RC2/40 key leads to a
impedance mismatch in encryption strength). severe impedance mismatch in encryption strength).
The key wrap algorithm specified below is independent of the The key wrap algorithm specified below is independent of the content-
content-encryption or wrapping algorithms, relying only on the use of a encryption or wrapping algorithms, relying only on the use of a block
block cipher to perform the wrapping. cipher to perform the wrapping.
2.3.1 Key Wrap 2.3.1 Key Wrap
The key wrap algorithm encrypts a CEK with a KEK in a manner which The key wrap algorithm encrypts a CEK with a KEK in a manner which
ensures that every bit of plaintext effects every bit of ciphertext. ensures that every bit of plaintext effects every bit of ciphertext.
This makes it equivalent in function to the package transform [PACKAGE] This makes it equivalent in function to the package transform
without requiring additional mechanisms or resources such as hash [PACKAGE] without requiring additional mechanisms or resources such
functions or cryptographically strong random numbers. The key wrap as hash functions or cryptographically strong random numbers. The
algorithm is performed in two phases, a first phase which formats the key wrap algorithm is performed in two phases, a first phase which
CEK into a form suitable for encryption by the KEK, and a second phase formats the CEK into a form suitable for encryption by the KEK, and a
which wraps the formatted CEK using the KEK. second phase which wraps the formatted CEK using the KEK.
Key formatting: Create a formatted CEK block consisting of the Key formatting: Create a formatted CEK block consisting of the
following: following:
1. A one-byte count of the number of bytes in the CEK. 1. A one-byte count of the number of bytes in the CEK.
2. A check value containing the bitwise complement of the first three 2. A check value containing the bitwise complement of the first
bytes of the CEK. three bytes of the CEK.
3. The CEK. 3. The CEK.
4. Enough random padding data to make the CEK data block at least two 4. Enough random padding data to make the CEK data block at least
KEK cipher blocks long (the fact that 32 bits of count+check value two KEK cipher blocks long (the fact that 32 bits of count+check
are used means that even with a 40-bit CEK, the resulting data value are used means that even with a 40-bit CEK, the resulting
size will always be at least two (64-bit) cipher blocks long). data size will always be at least two (64-bit) cipher blocks
The padding data does not have to be cryptographically strong, long). The padding data does not have to be cryptographically
although unpredictability helps. strong, although unpredictability helps.
The formatted CEK block then looks as follows: The formatted CEK block then looks as follows:
CEK byte count || check value || CEK || padding (if required) CEK byte count || check value || CEK || padding (if required)
Key wrapping: Key wrapping:
1. Encrypt the padded key using the KEK. 1. Encrypt the padded key using the KEK.
2. Without resetting the IV (that is, using the last ciphertext block 2. Without resetting the IV (that is, using the last ciphertext
as the IV), encrypt the encrypted padded key a second time. block as the IV), encrypt the encrypted padded key a second
time.
The resulting double-encrypted data is the EncryptedKey. The resulting double-encrypted data is the EncryptedKey.
2.3.2 Key Unwrap 2.3.2 Key Unwrap
Key unwrapping: Key unwrapping:
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
ciphertext block. ciphertext block.
2. Using the decrypted n'th ciphertext block as the IV, decrypt the 2. Using the decrypted n'th ciphertext block as the IV, decrypt the
1st ... n-1'th ciphertext blocks. This strips the outer layer of 1st ... n-1'th ciphertext blocks. This strips the outer layer
encryption. of encryption.
3. Decrypt the inner layer of encryption using the KEK. 3. Decrypt the inner layer of encryption using the KEK.
Key format verification: Key format verification:
1a.If the CEK byte count is less than the minimum allowed key size 1a.If the CEK byte count is less than the minimum allowed key size
(usually 5 bytes for 40-bit keys) or greater than the wrapped CEK (usually 5 bytes for 40-bit keys) or greater than the wrapped
length or not valid for the CEK algorithm (eg not 16 or 24 bytes CEK length or not valid for the CEK algorithm (eg not 16 or 24
for triple DES), the KEK was invalid. bytes for triple DES), the KEK was invalid.
1b.If the bitwise complement of the key check value doesn't match 1b.If the bitwise complement of the key check value doesn't match
the first three bytes of the key, the KEK was invalid. the first three bytes of the key, the KEK was invalid.
2.3.3 Example 2.3.3 Example
Given a content-encryption algorithm of Skipjack and a KEK algorithm of Given a content-encryption algorithm of Skipjack and a KEK algorithm
Triple-DES, the wrap steps are as follows: of Triple-DES, the wrap steps are as follows:
1. Set the first 4 bytes of the CEK block to the Skipjack key size 1. Set the first 4 bytes of the CEK block to the Skipjack key size
(10 bytes) and the bitwise complement of the first three bytes of (10 bytes) and the bitwise complement of the first three bytes
the CEK. of the CEK.
2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16 2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16
bytes (two triple-DES blocks) using 2 bytes of random data. bytes (two triple-DES blocks) using 2 bytes of random data.
2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, 2. Using the IV given in the KeyEncryptionAlgorithmIdentifer,
encrypted the padded Skipjack key. encrypted the padded Skipjack key.
3. Without resetting the IV, encrypt the encrypted padded key a 3. Without resetting the IV, encrypt the encrypted padded key a
second time. second time.
The unwrap steps are as follows: The unwrap steps are as follows:
1. Using the first 8 bytes of the double-encrypted key as the IV, 1. Using the first 8 bytes of the double-encrypted key as the IV,
decrypt the second 8 bytes. decrypt the second 8 bytes.
2. Without resetting the IV, decrypt the first 8 bytes. 2. Without resetting the IV, decrypt the first 8 bytes.
3. Decrypt the inner layer of encryption using the the IV given in 3. Decrypt the inner layer of encryption using the the IV given in
the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack the KeyEncryptionAlgorithmIdentifer to recover the padded
key. Skipjack key.
4. If the length byte isn't equal to the Skipjack key size (80 bits 4. If the length byte isn't equal to the Skipjack key size (80 bits
or 10 bytes) or the bitwise complement of the check bytes doesn't or 10 bytes) or the bitwise complement of the check bytes
match the first three bytes of the CEK, the KEK was invalid. doesn't match the first three bytes of the CEK, the KEK was
invalid.
2.3.4 Rationale for the Double Wrapping 2.3.4 Rationale for the Double Wrapping
If many CEK's are encrypted in a standard way with the same KEK and the If many CEK's are encrypted in a standard way with the same KEK and
KEK has a 64-bit block size then after about 2^32 encryptions there is the KEK has a 64-bit block size then after about 2^32 encryptions
a high probability of a collision between different blocks of encrypted there is a high probability of a collision between different blocks
CEK's. If an opponent manages to obtain a CEK, they may be able to of encrypted CEK's. If an opponent manages to obtain a CEK, they may
solve for other CEK's. The double-encryption wrapping process, which be able to solve for other CEK's. The double-encryption wrapping
makes every bit of ciphertext dependent on every bit of the CEK, process, which makes every bit of ciphertext dependent on every bit
eliminates this collision problem (as well as preventing other of the CEK, eliminates this collision problem (as well as preventing
potential problems such as bit-flipping attacks). Since the IV is other potential problems such as bit-flipping attacks). Since the IV
applied to the inner layer of encryption, even wrapping the same CEK is applied to the inner layer of encryption, even wrapping the same
with the same KEK will result in a completely different wrapped key CEK with the same KEK will result in a completely different wrapped
each time. key each time.
An additional feature of the double wrapping is that it doens't
require the use of any extra algorithms such as hash algorithms in
addition to the wrapping algorithm itself, allowing it to be
implemented in devices which only support one type of encryption
algorithm. A typical example of such a device is a crypto token such
as a smart card which often only supports a single block cipher and a
single public-key algorithm, making it impossible to wrap keys if the
use of an additional algorithm were required.
2.4 Special Handling for RC2 Keys 2.4 Special Handling for RC2 Keys
For a variety of historical, political, and software-peculiarity For a variety of historical, political, and software-peculiarity
reasons which are beyond the scope of this document, the handling of reasons which are beyond the scope of this document, the handling of
keys for the RC2 algorithm [RFC2268] by different implementations is keys for the RC2 algorithm [RFC2268] by different implementations is
somewhat arbitrary. In particular, the choice of actual vs effective somewhat arbitrary. In particular, the choice of actual vs effective
key bits used in the algorithm is often unclear. The standard RC2 key bits used in the algorithm is often unclear. The standard RC2
AlgorithmIdentifier only allows the effective key bits to be specified, AlgorithmIdentifier only allows the effective key bits to be
leaving the actual key bits to be communicated via out-of-band means, specified, leaving the actual key bits to be communicated via out-of-
which in some cases means hardcoding them into applications. Solving band means, which in some cases means hardcoding them into
this problem requires two things, a precise definition of how keys applications. Solving this problem requires two things, a precise
represented with the standard RC2 AlgorithmIdentifier are handled, and definition of how keys represented with the standard RC2
a new RC2 AlgorithmIdentifier which allows keys currently in use by AlgorithmIdentifier are handled, and a new RC2 AlgorithmIdentifier
different applications to be handled. which allows keys currently in use by different applications to be
handled.
2.4.1 Handling of RC2 with RFC 2268 AlgorithmIdentifier 2.4.1 Handling of RC2 with RFC 2268 AlgorithmIdentifier
RFC 2268 defines the following AlgorithmIdentifier for RC2: RFC 2268 defines the following AlgorithmIdentifier for RC2:
rc2CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840) rc2CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840)
rsadsi(113549) encryptionAlgorithm(3) 2} rsadsi(113549) encryptionAlgorithm(3) 2}
RC2-CBCParameter ::= CHOICE { RC2-CBCParameter ::= CHOICE {
iv IV, iv IV,
params SEQUENCE { params SEQUENCE {
version INTEGER, version INTEGER,
iv OCTET STRING iv OCTET STRING
} }
} }
where the version field encodes the effective key size in a complex where the version field encodes the effective key size in a complex
manner specified in the RFC. Where this algorithm identifier is used, manner specified in the RFC. Where this algorithm identifier is
the actual key size shall be the same size as the effective key size as used, the actual key size shall be the same size as the effective key
given by the version field. When RC2 is to be used, implementations size as given by the version field. When RC2 is to be used,
should use this AlgorithmIdentifier and parameters, and when this implementations should use this AlgorithmIdentifier and parameters,
AlgorithmIdentifier is used the actual key size MUST NOT be a value and when this AlgorithmIdentifier is used the actual key size MUST
other than the effective key size (to use a different size, see section NOT be a value other than the effective key size (to use a different
2.4.2). size, see section 2.4.2).
2.4.2 Handling of RC2 with Other Key Sizes 2.4.2 Handling of RC2 with Other Key Sizes
If the use of an actual key size of other than the effective key size If the use of an actual key size of other than the effective key size
is required, implementations MUST use the following is required, implementations MUST use the following
AlgorithmIdentifier: AlgorithmIdentifier:
rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13} id-alg-pwri-rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13}
RC2-CBCParameter ::= SEQUENCE { pwri-rc2CBCParameter ::= SEQUENCE {
actualKeySize INTEGER, -- Actual key size in bits actualKeySize INTEGER, -- Actual key size in bits
effectiveKeySize INTEGER, -- Effective key size in bits effectiveKeySize INTEGER, -- Effective key size in bits
iv OCTET STRING iv OCTET STRING
} }
This allows arbitrary actual and effective key sizes to be specified This allows arbitrary actual and effective key sizes to be specified
for compatibility with existing usage. Although implementations SHOULD for compatibility with existing usage. Although implementations
NOT use this alternative (using instead the one in section 2.4.1) SHOULD NOT use this alternative (using instead the one in section
experience has shown that implementors will continue to use oddball RC2 2.4.1) experience has shown that implementors will continue to use
parameters anyway, so new implementations should be prepared to oddball RC2 parameters anyway, so new implementations should be
encounter and handle actual and effective key sizes ranging from 40 up prepared to encounter and handle actual and effective key sizes
to around 200 bits. ranging from 40 up to around 200 bits.
2.4.3 Rationale 2.4.3 Rationale
The reason for providing for the handling of oddball key sizes is The reason for providing for the handling of oddball key sizes is
compatibility with existing applications, for example a mailing-list compatibility with existing applications, for example a mailing-list
exploder or mail gateway may take an RSA-wrapped CEK generated by a exploder or mail gateway may take an RSA-wrapped CEK generated by a
current application and repackage it with a KEK, so we need a mechanism current application and repackage it with a KEK, so we need a
for handling strange key lengths in a manner which is compatible with mechanism for handling strange key lengths in a manner which is
existing usage. The alternative RC2 AlgorithmIdentifier, although not compatible with existing usage. The alternative RC2
recommended, provides a means of ensuring this compatibility. AlgorithmIdentifier, although not recommended, provides a means of
ensuring this compatibility.
3. Test Vectors 3. Test Vectors
The following values are obtained when wrapping a 256-bit Blowfish-CFB This section contains two sets of test vectors, a very basic set for
key using a triple DES-CBC key derived from the passphrase "All DES which can be used to verify correctness and which uses an
n-entities must communicate with other n-entities via n-1 algorithm which is freely exportable from the US, and a stress-test
entiteeheehees" with salt { 12 34 56 78 78 56 34 12 } using 500 version which uses very long passphrase and key sizes and a mixture
iterations of PBKDF2. of algorithms which can be used to verify the behaviour in extreme
cases.
The basic test contains two subtests, a known-answer test for the key
derivation stage and a full test of the key wrapping. Both tests use
a DES-CBC key derived from the password "password" with salt { 12 34
56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known
answer test the IV is set to all zeroes (equivalent to using ECB) and
used to encrypt an all-zero data block.
The following values are obtained for the known-answer test:
PKCS #5v2 values:
input 70 61 73 73 77 6f 72 64
passphrase: "password"
input salt: 12 34 56 78 78 56 34 12
iterations: 5
output key: D1 DA A7 86 15 F2 87 E6
known answer: 9B BD 78 FC 11 A3 A9 08
The following values are obtained when wrapping a 64-bit (parity-
adjusted) DES-EBC key:
PKCS #5v2 values:
input 70 61 73 73 77 6f 72 64
passphrase: "password"
input salt: 12 34 56 78 78 56 34 12
iterations: 5
output key: D1 DA A7 86 15 F2 87 E6
CEK formatting phase:
length byte: 08
key check: 73 9D 83
CEK: 8C 62 7C 89 73 23 A2 F8
padding: C4 36 F5 41
complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41
CEK block:
Key wrap phase (wrap CEK block using 3DES key):
IV: EF E5 98 EF 21 B3 3D 6D
first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4
pass output:
second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
pass output:
ASN.1 encoded PasswordRecipientInfo:
0 A3 68: [3] {
2 02 1: INTEGER 0
5 A0 26: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 13: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 1: INTEGER 5
: }
: }
33 30 17: SEQUENCE {
35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7)
42 04 8: OCTET STRING
: EF E5 98 EF 21 B3 3D 6D
: }
52 04 16: OCTET STRING
: B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
: }
The following values are obtained when wrapping a 256-bit key (for
example one for AES or Blowfish) using a triple DES-CBC key derived
from the passphrase "All n-entities must communicate with other n-
entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12}
using 500 iterations of PBKDF2.
PKCS #5v2 values: PKCS #5v2 values:
input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D
passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20
77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74 77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74
69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E
74 69 74 65 65 68 65 65 68 65 65 73 74 69 74 65 65 68 65 65 68 65 65 73
"All n-entities must communicate with other " "All n-entities must communicate with other "
"n-entities via n-1 entiteeheehees" "n-entities via n-1 entiteeheehees"
skipping to change at line 384 skipping to change at line 474
3DES key: 07 12 63 80 CC 47 AB 2D 3DES key: 07 12 63 80 CC 47 AB 2D
CEK formatting phase: CEK formatting phase:
length byte: 20 length byte: 20
key check: 73 9C 82 key check: 73 9C 82
CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5
D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B
padding: FA 06 0A 45 padding: FA 06 0A 45
complete 20 93 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB
CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03
C7 1B AF 3B FA 06 0A 45 C7 1B AF 3B FA 06 0A 45
Key wrap phase (wrap CEK block using 3DES key): Key wrap phase (wrap CEK block using 3DES key):
IV: BA F1 CA 79 31 21 3C 4E IV: BA F1 CA 79 31 21 3C 4E
first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD
pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80
96 9E 65 27 9E 12 6A EB 96 9E 65 27 9E 12 6A EB
skipping to change at line 427 skipping to change at line 517
56 04 40: OCTET STRING 56 04 40: OCTET STRING
: C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
: EC 74 E6 CA D7 DB 26 0C : EC 74 E6 CA D7 DB 26 0C
: } : }
4. Security Considerations 4. Security Considerations
The security of this recipient information type rests on the security The security of this recipient information type rests on the security
of the underlying mechanisms employed, for which further information of the underlying mechanisms employed, for which further information
can be found in RFC 2640 and PKCS5v2. More importantly, however, when can be found in RFC 2640 and PKCS5v2. More importantly, however,
used with a password the security of this information type rests on the when used with a password the security of this information type rests
entropy of the user-selected password, which is typically quite low. on the entropy of the user-selected password, which is typically
Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, quite low. Pass phrases (as opposed to simple passwords) are STRONGLY
although it should be recognized that even with pass phrases it will be RECOMMENDED, although it should be recognized that even with pass
difficult to use this recipient information type to derive a KEK with phrases it will be difficult to use this recipient information type
sufficient entropy to properly protect a 128-bit (or higher) CEK. to derive a KEK with sufficient entropy to properly protect a 128-bit
(or higher) CEK.
5. Changes Since the Last Version
- Added length count due to concerns over odd-length RC2 keys
- Added check value to allow better error reporting and balance
out the single-byte length value
- Included test vectors
Author Address Author Address
Peter Gutmann Peter Gutmann
University of Auckland University of Auckland
Private Bag 92019 Private Bag 92019
Auckland, New Zealand Auckland, New Zealand
pgut001@cs.auckland.ac.nz pgut001@cs.auckland.ac.nz
References References
ASN1 Recommendation X.680: Specification of Abstract Syntax Notation ASN1 Recommendation X.680: Specification of Abstract Syntax
One (ASN.1), 1994. Notation One (ASN.1), 1994.
PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, RSA
Laboratories, 25 March 1999.
RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels,
S.Bradner, March 1997. S.Bradner, March 1997.
RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest, RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest,
March 1998. March 1998.
RFC2640 Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ RFC2630 Cryptographic Message Syntax, R.Housley, June 1999.
Housley, April 1999.
RFC2898 PKCS #5: Password-Based Cryptography Specification, Version
2.0, B.Kaliski, September 2000.
PACKAGE All-or-Nothing Encryption and the Package Transform, PACKAGE All-or-Nothing Encryption and the Package Transform,
R.Rivest, Proceedings of Fast Software Encryption '97, Haifa, R.Rivest, Proceedings of Fast Software Encryption '97, Haifa,
Israel, January 1997. Israel, January 1997.
Appendix A: ASN.1 Module Appendix A: ASN.1:1988 Module
PasswordRecipientInfo PasswordRecipientInfo
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(n+1) } smime(16) modules(0) pwri(12) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-5(5) }
PBKDF2-params, PBES2-Encs;
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifer ::= AlgorithmIdentifier
END
Appendix B: ASN.1:1994 Module
This appendix contains the same information as Appendix A in a more
recent (and precise) ASN.1 notation, however Appendix A takes
precedence in case of conflict.
PasswordRecipientInfo
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(12) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-5(5) } pkcs-5(5) }
PBKDF2-params, PBES2-Encs; PBKDF2-params, PBES2-Encs;
skipping to change at line 504 skipping to change at line 619
{ SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
... ...
} }
KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs
END END
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved. Copyright (C) The Internet Society 2000. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it
assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the document itself may not be modified in any way, such as by removing
copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of
Internet standards in which case the procedures for copyrights defined developing Internet standards in which case the procedures for
in the Internet Standards process must be followed, or as required to copyrights defined in the Internet Standards process must be
translate it into languages other than English. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/