draft-ietf-smime-password-06.txt   rfc3211.txt 
Internet Draft Editor: Peter Gutmann Network Working Group P. Gutmann
draft-ietf-smime-password-06.txt University of Auckland Request for Comments: 3211 University of Auckland
October 16, 2001 Category: Standards Track December 2001
Expires April 2002
Password-based Encryption for CMS
Status of this memo
This document is an Internet-Draft and is in full conformance with all Password-based Encryption for CMS
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Status of this Memo
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet- Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
The Cryptographic Message Syntax data format doesn't currently contain This document provides a method of encrypting data using user-
any provisions for password-based data encryption. This document supplied passwords and, by extension, any form of variable-length
provides a method of encrypting data using user-supplied passwords and, keying material which is not necessarily an algorithm-specific
by extension, any form of variable-length keying material which isn't fixed-format key. The Cryptographic Message Syntax data format does
necessarily an algorithm-specific fixed-format key. not currently contain any provisions for password-based data
encryption.
1. Introduction 1. Introduction
This document describes a password-based content encryption mechanism This document describes a password-based content encryption mechanism
for CMS. This is implemented as a new RecipientInfo type and is an for CMS. This is implemented as a new RecipientInfo type and is an
extension to the RecipientInfo types currently defined in RFC 2630 extension to the RecipientInfo types currently defined in RFC 2630.
[RFC2630].
The format of the messages are described in ASN.1 [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 RFC 2119.
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 terms of Although the recipient information generation process is described in
a password-based operation (since this will be its most common use), the terms of a password-based operation (since this will be its most
transformation employed is a general-purpose key derivation one which allows common use), the transformation employed is a general-purpose key
any type of keying material to be converted into a key specific to a particular derivation one which allows any type of keying material to be
content-encryption algorithm. Since the most common use for password-based converted into a key specific to a particular content-encryption
encryption is to encrypt files which are stored locally (rather than being algorithm. Since the most common use for password-based encryption
transmitted across a network), the term "recipient" is somewhat misleading, but is to encrypt files which are stored locally (rather than being
is used here because the other key transport mechanisms have always been transmitted across a network), the term "recipient" is somewhat
described in similar terms. misleading, but is used here because the other key transport
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 MUST be 0. Details of the version is the syntax version number. It MUST be 0. Details of
CMSVersion type are discussed in CMS [RFC2630], section 10.2.5. the CMSVersion type are discussed in CMS [RFC2630], section
10.2.5.
keyDerivationAlgorithm identifies the key-derivation algorithm, and keyDerivationAlgorithm identifies the key-derivation algorithm,
any associated parameters, used to derive the KEK from the user- and any associated parameters, used to derive the KEK from the
supplied password. If this field is absent, the KEK is supplied from user-supplied password. If this field is absent, the KEK is
an external source, for example a crypto token such as a smart card. supplied from an external source, for example a crypto token such
as a smart card.
keyEncryptionAlgorithm identifies the key-encryption algorithm, and keyEncryptionAlgorithm identifies the key-encryption algorithm,
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
with the KEK. key 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 #5v2 standard [RFC2898] goes one step further to wrap these up the PKCS #5v2 standard [RFC2898] goes one step further to wrap these
into a single algorithm identifier, this design is particular to that up into a single algorithm identifier, this design is particular to
standard and may not be applicable for other key wrapping mechanisms. that standard and may not be applicable for other key wrapping
For this reason the two steps are specified separately. mechanisms. For this reason the two steps are specified separately.
The current format doesn't provide any means of differentiating between The current format doesn't provide any means of differentiating
multiple password recipient infos, which would occur for example if between multiple password recipient infos, which would occur for
two passwords are used to encrypt the same data. Unfortunately there example if two passwords are used to encrypt the same data.
is a lack of existing practice in this area, since typical applications Unfortunately there is a lack of existing practice in this area,
follow the model of encrypting data such as a file with a single since typical applications follow the model of encrypting data such
password obtained from the user. Without any clear requirements, an as a file with a single password obtained from the user. Without any
appropriate multiple password mechanism would be difficult clear requirements, an appropriate multiple password mechanism would
(perhaps impossible) to define at this time. If sufficient demand be difficult (perhaps impossible) to define at this time. If
emerges then this may be addressed in a future version of this sufficient demand emerges then this may be addressed in a future
document, for example by adding an optional identification field of an version of this document, for example by adding an optional
appropriate form. identification field of an appropriate form.
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 ::= AlgorithmIdentifier KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B
contains a more precise definition of the allowed algorithm type than contains a more precise definition of the allowed algorithm type than
is possible using 1988 ASN.1. is possible using 1988 ASN.1.
2.2 Key Encryption Algorithms 2.2 Key Encryption Algorithms
These algorithms are used to encrypt the CEK using the derived KEK. These algorithms are used to encrypt the CEK using the derived KEK.
The key encryption algorithms are: The key encryption algorithms are:
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
The PasswordRecipientInfo key encryption algorithm identifier is: The PasswordRecipientInfo key encryption algorithm identifier is:
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
The AlgorithmIdentifier parameters field for this algorithm contains The AlgorithmIdentifier parameters field for this algorithm contains
the KEK encryption algorithm used with the the key wrap algorithm the KEK encryption algorithm used with the the key wrap algorithm
specified in section 2.3. specified in section 2.3.
There is no requirement that the CEK algorithm match the KEK encryption There is no requirement that the CEK algorithm match the KEK
algorithm, although care should be taken to ensure that, if different encryption algorithm, although care should be taken to ensure that,
algorithms are used, they offer an equivalent level of security (for if different algorithms are used, they offer an equivalent level of
example wrapping a Triple-DES key with an RC2/40 key leads to a severe security (for example wrapping a Triple-DES key with an RC2/40 key
impedance mismatch in encryption strength). leads to a severe impedance mismatch in encryption strength).
Conforming implementations MUST implement the id-alg-PWRI-KEK key wrap Conforming implementations MUST implement the id-alg-PWRI-KEK key
algorithm. For the KEK encryption algorithms used by id-alg-PWRI-KEK, wrap algorithm. For the KEK encryption algorithms used by id-alg-
conforming implementations MUST include Triple-DES in CBC mode and MAY PWRI-KEK, conforming implementations MUST include Triple-DES in CBC
include other algorithms such as AES, CAST-128, RC5, IDEA, Skipjack, mode and MAY include other algorithms such as AES, CAST-128, RC5,
Blowfish, and encryption modes as required. Implementations SHOULD NOT IDEA, Skipjack, Blowfish, and encryption modes as required.
include any KSG (keystream generator) ciphers such as RC4 or a block Implementations SHOULD NOT include any KSG (keystream generator)
cipher in OFB mode, and SHOULD NOT include a block cipher in ECB mode. ciphers such as RC4 or a block cipher in OFB mode, and SHOULD NOT
include a block cipher in ECB mode.
2.2.1 Rationale 2.2.1 Rationale
The use of a level of indirection in specifying the The use of a level of indirection in specifying the
KeyEncryptionAlgorithmIdentifier allows alternative wrapping algorithms KeyEncryptionAlgorithmIdentifier allows alternative wrapping
to be used in the future. If the KEK algorithm were specified directly algorithms to be used in the future. If the KEK algorithm were
in this field then any use of an alternative wrapping algorithm would specified directly in this field then any use of an alternative
require a change to the PasswordRecipientInfo structure rather than wrapping algorithm would require a change to the
simply a change to the key encryption algorithm identifier. PasswordRecipientInfo structure rather than simply a change to the
key encryption algorithm identifier.
The parameter field for this algorithm identifier could be specified to The parameter field for this algorithm identifier could be specified
default to triple-DES, however due to the confusion over NULL vs absent to default to triple-DES, however due to the confusion over NULL vs
parameters in algorithm identifiers it's left explicit with no default absent parameters in algorithm identifiers it's left explicit with no
value. default value.
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 a multiple 4. Enough random padding data to make the CEK data block a
of the KEK block length and at least two KEK cipher blocks long multiple of the KEK block length and at least two KEK cipher
(the fact that 32 bits of count+check value are used means that blocks long (the fact that 32 bits of count+check value are
even with a 40-bit CEK, the resulting data size will always be at used means that even with a 40-bit CEK, the resulting data size
least two (64-bit) cipher blocks long). The padding data does not will always be at least two (64-bit) cipher blocks long). The
have to be cryptographically strong, although unpredictability padding data does not have to be cryptographically strong,
helps. Note that PKCS #5 padding is not used, since the length of although unpredictability helps. Note that PKCS #5 padding is
the data is already known. not used, since the length of the data is already known.
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
1st ... n-1'th ciphertext blocks. This strips the outer layer of the 1st ... n-1'th ciphertext blocks. This strips the outer
encryption. layer 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
(usually 5 bytes for 40-bit keys) or greater than the wrapped CEK size (usually 5 bytes for 40-bit keys) or greater than the
length or not valid for the CEK algorithm (eg not 16 or 24 bytes wrapped CEK length or not valid for the CEK algorithm (eg not
for triple DES), the KEK was invalid. 16 or 24 bytes for triple DES), the KEK was invalid.
1b.If the bitwise complement of the key check value doesn't match the 1b. If the bitwise complement of the key check value doesn't match
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
bytes (two triple-DES blocks) using 2 bytes of random data. 16 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 second time. 3. Without resetting the IV, encrypt the encrypted padded key a
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
or 10 bytes) or the bitwise complement of the check bytes doesn't bits 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 CEKs are encrypted in a standard way with the same KEK and the If many CEKs 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
CEKs. If an opponent manages to obtain a CEK, they may be able to of encrypted CEKs. If an opponent manages to obtain a CEK, they may
solve for other CEKs. The double-encryption wrapping process, which be able to solve for other CEKs. 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 An additional feature of the double wrapping is that it doesn't
the use of any extra algorithms such as hash algorithms in addition to require the use of any extra algorithms such as hash algorithms in
the wrapping algorithm itself, allowing it to be implemented in devices addition to the wrapping algorithm itself, allowing it to be
which only support one type of encryption algorithm. A typical example implemented in devices which only support one type of encryption
of such a device is a crypto token such as a smart card which often algorithm. A typical example of such a device is a crypto token such
only supports a single block cipher and a single public-key algorithm, as a smart card which often only supports a single block cipher and a
making it impossible to wrap keys if the use of an additional algorithm single public-key algorithm, making it impossible to wrap keys if the
were required. use of an additional algorithm were required.
3. Test Vectors 3. Test Vectors
This section contains two sets of test vectors, a very basic set for This section contains two sets of test vectors, a very basic set for
DES which can be used to verify correctness and which uses an algorithm DES which can be used to verify correctness and which uses an
which is freely exportable from the US, and a stress-test version which algorithm which is freely exportable from the US, and a stress-test
uses very long passphrase and key sizes and a mixture of algorithms version which uses very long passphrase and key sizes and a mixture
which can be used to verify the behaviour in extreme cases. 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 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 derivation stage and a full test of the key wrapping. Both tests use
DES-CBC key derived from the password "password" with salt { 12 34 56 a DES-CBC key derived from the password "password" with salt { 12 34
78 78 56 34 12 } using 5 iterations of PBKDF2. In the known answer 56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known
test the IV is set to all zeroes (equivalent to using ECB) and used to answer test the IV is set to all zeroes (equivalent to using ECB) and
encrypt an all-zero data block. used to encrypt an all-zero data block.
The following values are obtained for the known-answer test: The following values are obtained for the known-answer test:
PKCS #5v2 values: PKCS #5v2 values:
input 70 61 73 73 77 6f 72 64 input 70 61 73 73 77 6f 72 64
passphrase: "password" passphrase: "password"
input salt: 12 34 56 78 78 56 34 12 input salt: 12 34 56 78 78 56 34 12
iterations: 5 iterations: 5
output key: D1 DA A7 86 15 F2 87 E6 output key: D1 DA A7 86 15 F2 87 E6
known answer: 9B BD 78 FC 11 A3 A9 08 known answer: 9B BD 78 FC 11 A3 A9 08
The following values are obtained when wrapping a 64-bit (parity- The following values are obtained when wrapping a 64-bit (parity-
adjusted) DES-EBC key: adjusted) DES-EBC key:
PKCS #5v2 values: PKCS #5v2 values:
input 70 61 73 73 77 6f 72 64 input 70 61 73 73 77 6f 72 64
passphrase: "password" passphrase: "password"
input salt: 12 34 56 78 78 56 34 12 input salt: 12 34 56 78 78 56 34 12
iterations: 5 iterations: 5
output key: D1 DA A7 86 15 F2 87 E6 output key: D1 DA A7 86 15 F2 87 E6
CEK formatting phase: CEK formatting phase:
length byte: 08 length byte: 08
key check: 73 9D 83 key check: 73 9D 83
CEK: 8C 62 7C 89 73 23 A2 F8 CEK: 8C 62 7C 89 73 23 A2 F8
padding: C4 36 F5 41 padding: C4 36 F5 41
complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41
CEK block: CEK block:
Key wrap phase (wrap CEK block using 3DES key): Key wrap phase (wrap CEK block using DES key):
IV: EF E5 98 EF 21 B3 3D 6D 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 first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4
pass output: pass output:
second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
pass output: pass output:
ASN.1 encoded PasswordRecipientInfo: ASN.1 encoded PasswordRecipientInfo:
0 A3 68: [3] { 0 A3 68: [3] {
2 02 1: INTEGER 0 2 02 1: INTEGER 0
5 A0 26: [0] { 5 A0 26: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 13: SEQUENCE { 18 30 13: SEQUENCE {
20 04 8: OCTET STRING 20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12 : 12 34 56 78 78 56 34 12
30 02 1: INTEGER 5 30 02 1: INTEGER 5
: } : }
: } : }
34 30 32: SEQUENCE { 34 30 32: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK (1 2 840 113549 1 9 16 3 9) 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
33 30 17: SEQUENCE { : (1 2 840 113549 1 9 16 3 9)
35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7) 33 30 17: SEQUENCE {
42 04 8: OCTET STRING 35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7)
: EF E5 98 EF 21 B3 3D 6D 42 04 8: OCTET STRING
: } : EF E5 98 EF 21 B3 3D 6D
: } : }
68 04 16: OCTET STRING : }
: B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 68 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 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 example one for AES or Blowfish) using a triple DES-CBC key derived
from the passphrase "All n-entities must communicate with other n- from the passphrase "All n-entities must communicate with other
entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12} n-entities via n-1 entiteeheehees" with salt
using 500 iterations of PBKDF2. { 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"
input input
salt: 12 34 56 78 78 56 34 12 salt: 12 34 56 78 78 56 34 12
iterations: 500 iterations: 500
output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86
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 73 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
second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 pass output: 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
ASN.1 encoded PasswordRecipientInfo: ASN.1 encoded PasswordRecipientInfo:
0 A3 96: [3] { 0 A3 96: [3] {
2 02 1: INTEGER 0 2 02 1: INTEGER 0
5 A0 27: [0] { 5 A0 27: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 14: SEQUENCE { 18 30 14: SEQUENCE {
20 04 8: OCTET STRING 20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12 : 12 34 56 78 78 56 34 12
30 02 2: INTEGER 500 30 02 2: INTEGER 500
: } : }
: } : }
34 30 35: SEQUENCE { 34 30 35: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK (1 2 840 113549 1 9 16 3 9) 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
34 30 20: SEQUENCE { : (1 2 840 113549 1 9 16 3 9)
36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) 34 30 20: SEQUENCE {
46 04 8: OCTET STRING 36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
: BA F1 CA 79 31 21 3C 4E 46 04 8: OCTET STRING
: } : BA F1 CA 79 31 21 3C 4E
: } : }
71 04 40: OCTET STRING : }
: C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 71 04 40: OCTET STRING
: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
: EC 74 E6 CA D7 DB 26 0C : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
: } : 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 2630 and PKCS5v2. More importantly, however, when can be found in RFC 2630 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
although it should be recognized that even with pass phrases it will be STRONGLY RECOMMENDED, although it should be recognized that even with
difficult to use this recipient information type to derive a KEK with pass phrases it will be difficult to use this recipient information
sufficient entropy to properly protect a 128-bit (or higher) CEK. type to derive a KEK with sufficient entropy to properly protect a
128-bit (or higher) CEK.
5. IANA Considerations 5. IANA Considerations
The PasswordRecipientInfo key encryption algorithms are identified by The PasswordRecipientInfo key encryption algorithms are identified by
object identifiers (OIDs). OIDs were assigned from an arc contributed object identifiers (OIDs). OIDs were assigned from an arc
to the S/MIME Working Group by the RSA Security. Should additional contributed to the S/MIME Working Group by the RSA Security. Should
compression algorithms be introduced, the advocates for such algorithms additional encryption algorithms be introduced, the advocates for
are expected to assign the necessary OIDs from their own arcs. No such algorithms are expected to assign the necessary OIDs from their
action by the IANA is necessary for this document or any anticipated own arcs. No action by the IANA is necessary for this document or
updates. any anticipated updates.
Acknowledgments Acknowledgments
The author would like to thank Jim Schaad, Phil Griffin, and the The author would like to thank Jim Schaad, Phil Griffin, and the
members of the S/MIME Working Group for their comments and feedback on members of the S/MIME Working Group for their comments and feedback
this document. on this document.
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
EMail: pgut001@cs.auckland.ac.nz
References References
ASN1 CCITT Recommendation X.208: Specification of Abstract Syntax [ASN1] CCITT Recommendation X.208: Specification of Abstract
Notation One (ASN.1), 1988. Syntax Notation One (ASN.1), 1988.
RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels, [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
S.Bradner, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC2630 Cryptographic Message Syntax, R.Housley, June 1999. [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
RFC2898 PKCS #5: Password-Based Cryptography Specification, Version [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
2.0, B.Kaliski, September 2000. Specification, Version 2.0", RFC 2898, September 2000.
PACKAGE All-or-Nothing Encryption and the Package Transform, [PACKAGE] All-or-Nothing Encryption and the Package Transform, R.
R.Rivest, Proceedings of Fast Software Encryption '97, Haifa, Rivest, Proceedings of Fast Software Encryption '97, Haifa,
Israel, January 1997. Israel, January 1997.
Appendix A: ASN.1:1988 Module Appendix A: ASN.1:1988 Module
PasswordRecipientInfo-88 PasswordRecipientInfo-88
{ 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(17) } smime(16) modules(0) pwri(17) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at line 672 skipping to change at page 17, line 4
parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
} }
ALGORITHM ::= CLASS { ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE, &id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL &Type OPTIONAL
} }
WITH SYNTAX { OID &id [PARMS &Type] } WITH SYNTAX { OID &id [PARMS &Type] }
END -- PasswordRecipientInfo-97 -- END -- PasswordRecipientInfo-97 --
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 2001. All Rights Reserved. Copyright (C) The Internet Society (2001). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 112 change blocks. 
389 lines changed or deleted 397 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/