draft-ietf-smime-password-03.txt   draft-ietf-smime-password-04.txt 
Internet Draft Editor: Peter Gutmann Internet Draft Editor: Peter Gutmann
draft-ietf-smime-password-03.txt University of Auckland draft-ietf-smime-password-04.txt University of Auckland
October 21, 2000 July 17, 2001
Expires April 2001 Expires January 2002
Password-based Encryption for S/MIME Password-based Encryption for CMS
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
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 29 skipping to change at line 29
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
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.
Copyright (C) The Internet Society July 2001. All Rights Reserved.
Abstract Abstract
The Cryptographic Message Syntax data format doesn't currently The Cryptographic Message Syntax data format doesn't currently contain
contain any provisions for password-based data encryption. This any provisions for password-based data encryption. This document
document provides a method of encrypting data using user-supplied provides a method of encrypting data using user-supplied passwords and,
passwords and, by extension, any form of variable-length keying by extension, any form of variable-length keying material which isn't
material which isn't necessarily an algorithm-specific fixed-format necessarily an algorithm-specific fixed-format key.
key.
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 for S/MIME. This is implemented as a new RecipientInfo type and is an
an extension to the RecipientInfo types currently defined in RFC 2640 extension to the RecipientInfo types currently defined in RFC 2640
[RFC2640]. [RFC2640].
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 [RFC2119].
1.1 Password-based Content Encryption 1.1 Password-based Content Encryption
CMS currently defined three recipient information types for public- CMS currently defined three recipient information types for public- key
key key wrapping (KeyTransRecipientInfo), conventional key wrapping 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 PasswordRecipientInfo, which provides for password- based key wrapping.
wrapping.
1.2 RecipientInfo Types 1.2 RecipientInfo Types
The new recipient information type is an extension to the The new recipient information type is an extension to the RecipientInfo
RecipientInfo type defined in section 6.2 of CMS, extending the types type defined in section 6.2 of CMS, extending the types to:
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
terms of a password-based operation (since this will be its most a password-based operation (since this will be its most common use), the
common use), the transformation employed is a general-purpose key transformation employed is a general-purpose key derivation one which allows
derivation one which allows any type of keying material to be any type of keying material to be converted into a key specific to a particular
converted into a key specific to a particular content-encryption content-encryption algorithm. Since the most common use for password-based
algorithm. Since the most common use for password-based encryption encryption is to encrypt files which are stored locally (rather than being
is to encrypt files which are stored locally (rather than being transmitted across a network), the term "recipient" is somewhat misleading, but
transmitted across a network), the term "recipient" is somewhat is used here because the other key transport mechanisms have always been
misleading, but is used here because the other key transport described in similar 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. agreed-upon key is represented in the type PasswordRecipientInfo. Each
Each instance of PasswordRecipientInfo will transfer the content- instance of PasswordRecipientInfo will transfer the content-encryption
encryption key (CEK) to one or more recipients who have the key (CEK) to one or more recipients who have the previously agreed-upon
previously agreed-upon password or key-encryption key (KEK). 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 MUST be 0. Details of 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, and
any associated parameters, used to derive the KEK from the user- any associated parameters, used to derive the KEK from the user-
supplied password. If this field is absent, the KEK is supplied supplied password. If this field is absent, the KEK is supplied from
from an external source, for example a crypto token such as a smart an external source, for example a crypto token such as a smart card.
card.
keyEncryptionAlgorithm identifies the content-encryption algorithm, keyEncryptionAlgorithm identifies the key-encryption algorithm, and
and any associated parameters, used to encrypt the CEK with the any associated parameters, used to encrypt the CEK with the KEK.
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, which a user-supplied password is converted into a KEK if required, and
and a second stage in which the KEK is used to encrypt a CEK. These a second stage in which the KEK is used to encrypt a CEK. These two
two stages are identified by the two algorithm identifiers. Although stages are identified by the two algorithm identifiers. Although the
the PKCS #5v2 standard [RFC 2898] goes one step further to wrap these PKCS #5v2 standard [RFC2898] goes one step further to wrap these up
up into a single algorithm identifier, this design is particular to into a single algorithm identifier, this design is particular to that
that standard and may not be applicable for other key wrapping standard and may not be applicable for other key wrapping mechanisms.
mechanisms. For this reason the two steps are specified separately. For this reason the two steps are specified separately.
The current format doesn't provide any means of differentiating between
multiple password recipient info's, which would occur for example if
two passwords are used to encrypt the same data. Unfortunately there
is a lack of existing practice in this area, since typical applications
follow the model of encrypting data such as a file with a single
password obtained from the user. Two possible options would be to use
an OCTET STRING hole or a SEQUENCE OF everything-imaginable OPTIONAL,
however without any clear indication of what's required it's probable
that every implementation will choose to interpret the field
differently, leading to non-interoperability between applications.
Given this incompleteness, an appropriate mechanism would be difficult
(perhaps impossible) to define at this time. If sufficient demand
emerges then this may be addressed in a future version of this
document, for example by adding an optional identification field of an
appropriate form.
2 Supported Algorithms 2 Supported Algorithms
This section lists the algorithms that must be implemented. This section lists the algorithms that must be implemented. Additional
Additional algorithms that should be implemented are also included. 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 These algorithms are used to convert the password into a KEK. The key
key derivation algorithms are: derivation algorithms are:
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
CMS 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 content (the key) using the These algorithms are used to encrypt the CEK using the derived KEK.
derived KEK. The content encryption algorithms are PBES2-Encs [RFC The key encryption algorithms are:
2898]. Appendix B contains a more precise definition of the allowed
algorithm types than is possible using 1988 ASN.1.
CMS implementations MUST include Triple-DES in CBC mode, SHOULD KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
include RC2 in CBC mode, and MAY include other algorithms such as
AES, CAST-128, RC5, IDEA, Skipjack, Blowfish, and encryption modes as
required. CMS implementations SHOULD NOT include any KSG ciphers
such as RC4 or a block cipher in OFB mode, and SHOULD NOT include a
block cipher in ECB mode. The use of RC2 has special requirements,
see section 2.4 for details.
2.3 Symmetric Key Encryption Algorithms The PasswordRecipientInfo key encryption algorithm identifier is:
The key wrap algorithm is used to wrap the CEK with the KEK. There id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
is no requirement that the content-encryption algorithm match the KEK us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
The AlgorithmIdentifier parameters field for this algorithm contains
the KEK encryption algorithm used with the the key wrap algorithm
specified in section 2.3.
There is no requirement that the CEK algorithm match the KEK encryption
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 example wrapping a Triple-DES key with an RC2/40 key leads to a severe
severe impedance mismatch in encryption strength). impedance mismatch in encryption strength).
The key wrap algorithm specified below is independent of the content- Conforming implementations MUST implement the id-alg-PWRI-KEK key wrap
encryption or wrapping algorithms, relying only on the use of a block algorithm. For the KEK encryption algorithms used by id-alg-PWRI-KEK,
cipher to perform the wrapping. conforming implementations MUST include Triple-DES in CBC mode and MAY
include other algorithms such as AES, CAST-128, RC5, IDEA, Skipjack,
Blowfish, and encryption modes as required. Implementations SHOULD NOT
include any KSG (keystream generator) 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
The use of a level of indirection in specifying the
KeyEncryptionAlgorithmIdentifier allows alternative wrapping algorithms
to be used in the future. If the KEK algorithm were specified directly
in this field then any use of an alternative wrapping algorithm would
require a change to the PasswordRecipientInfo structure rather than
simply a change to the key encryption algorithm identifier.
The parameter field for this algorithm identifier could be specified to
default to triple-DES, however due to the confusion over NULL vs absent
parameters in algorithm identifiers it's left explicit with no 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 This makes it equivalent in function to the package transform [PACKAGE]
[PACKAGE] without requiring additional mechanisms or resources such without requiring additional mechanisms or resources such as hash
as hash functions or cryptographically strong random numbers. The functions or cryptographically strong random numbers. The key wrap
key wrap algorithm is performed in two phases, a first phase which algorithm is performed in two phases, a first phase which formats the
formats the CEK into a form suitable for encryption by the KEK, and a CEK into a form suitable for encryption by the KEK, and a second phase
second phase which wraps the formatted CEK using the KEK. 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 2. A check value containing the bitwise complement of the first three
three bytes of the CEK. bytes of the CEK.
3. The CEK. 3. The CEK.
4. Enough random padding data to make the CEK data block at least 4. Enough random padding data to make the CEK data block a multiple
two KEK cipher blocks long (the fact that 32 bits of count+check of the KEK block length and at least two KEK cipher blocks long
value are used means that even with a 40-bit CEK, the resulting (the fact that 32 bits of count+check value are used means that
data size will always be at least two (64-bit) cipher blocks even with a 40-bit CEK, the resulting data size will always be at
long). The padding data does not have to be cryptographically least two (64-bit) cipher blocks long). The padding data does not
strong, although unpredictability helps. have to be cryptographically 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 2. Without resetting the IV (that is, using the last ciphertext block
block as the IV), encrypt the encrypted padded key a second as the IV), encrypt the encrypted padded key a second time.
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 1st ... n-1'th ciphertext blocks. This strips the outer layer of
of encryption. 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 (usually 5 bytes for 40-bit keys) or greater than the wrapped CEK
CEK length or not valid for the CEK algorithm (eg not 16 or 24 length or not valid for the CEK algorithm (eg not 16 or 24 bytes
bytes for triple DES), the KEK was invalid. for triple DES), the KEK was invalid.
1b.If the bitwise complement of the key check value doesn't match
the first three bytes of the key, the KEK was invalid. 1b.If the bitwise complement of the key check value doesn't match 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 Given a content-encryption algorithm of Skipjack and a KEK algorithm of
of Triple-DES, the wrap steps are as follows: 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 (10 bytes) and the bitwise complement of the first three bytes of
of the CEK. 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 the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack
Skipjack key. 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 or 10 bytes) or the bitwise complement of the check bytes doesn't
doesn't match the first three bytes of the CEK, the KEK was match the first three bytes of the CEK, the KEK was invalid.
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 If many CEK's are encrypted in a standard way with the same KEK and the
the KEK has a 64-bit block size then after about 2^32 encryptions KEK has a 64-bit block size then after about 2^32 encryptions there is
there is a high probability of a collision between different blocks a high probability of a collision between different blocks of encrypted
of encrypted CEK's. If an opponent manages to obtain a CEK, they may CEK's. If an opponent manages to obtain a CEK, they may be able to
be able to solve for other CEK's. The double-encryption wrapping solve for other CEK's. The double-encryption wrapping process, which
process, which makes every bit of ciphertext dependent on every bit makes every bit of ciphertext dependent on every bit of the CEK,
of the CEK, eliminates this collision problem (as well as preventing eliminates this collision problem (as well as preventing other
other potential problems such as bit-flipping attacks). Since the IV potential problems such as bit-flipping attacks). Since the IV is
is applied to the inner layer of encryption, even wrapping the same applied to the inner layer of encryption, even wrapping the same CEK
CEK with the same KEK will result in a completely different wrapped with the same KEK will result in a completely different wrapped key
key each time. 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
For a variety of historical, political, and software-peculiarity
reasons which are beyond the scope of this document, the handling of
keys for the RC2 algorithm [RFC2268] by different implementations is
somewhat arbitrary. In particular, the choice of actual vs effective
key bits used in the algorithm is often unclear. The standard RC2
AlgorithmIdentifier only allows the effective key bits to be
specified, leaving the actual key bits to be communicated via out-of-
band means, which in some cases means hardcoding them into
applications. Solving this problem requires two things, a precise
definition of how keys represented with the standard RC2
AlgorithmIdentifier are handled, and a new RC2 AlgorithmIdentifier
which allows keys currently in use by different applications to be
handled.
2.4.1 Handling of RC2 with RFC 2268 AlgorithmIdentifier
RFC 2268 defines the following AlgorithmIdentifier for RC2:
rc2CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840)
rsadsi(113549) encryptionAlgorithm(3) 2}
RC2-CBCParameter ::= CHOICE {
iv IV,
params SEQUENCE {
version INTEGER,
iv OCTET STRING
}
}
where the version field encodes the effective key size in a complex
manner specified in the RFC. Where this algorithm identifier is
used, the actual key size shall be the same size as the effective key
size as given by the version field. When RC2 is to be used,
implementations should use this AlgorithmIdentifier and parameters,
and when this AlgorithmIdentifier is used the actual key size MUST
NOT be a value other than the effective key size (to use a different
size, see section 2.4.2).
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
is required, implementations MUST use the following
AlgorithmIdentifier:
id-alg-pwri-rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13}
pwri-rc2CBCParameter ::= SEQUENCE {
actualKeySize INTEGER, -- Actual key size in bits
effectiveKeySize INTEGER, -- Effective key size in bits
iv OCTET STRING
}
This allows arbitrary actual and effective key sizes to be specified
for compatibility with existing usage. Although implementations
SHOULD NOT use this alternative (using instead the one in section
2.4.1) experience has shown that implementors will continue to use
oddball RC2 parameters anyway, so new implementations should be
prepared to encounter and handle actual and effective key sizes
ranging from 40 up to around 200 bits.
2.4.3 Rationale
The reason for providing for the handling of oddball key sizes is An additional feature of the double wrapping is that it doens't require
compatibility with existing applications, for example a mailing-list the use of any extra algorithms such as hash algorithms in addition to
exploder or mail gateway may take an RSA-wrapped CEK generated by a the wrapping algorithm itself, allowing it to be implemented in devices
current application and repackage it with a KEK, so we need a which only support one type of encryption algorithm. A typical example
mechanism for handling strange key lengths in a manner which is of such a device is a crypto token such as a smart card which often
compatible with existing usage. The alternative RC2 only supports a single block cipher and a single public-key algorithm,
AlgorithmIdentifier, although not recommended, provides a means of making it impossible to wrap keys if the use of an additional algorithm
ensuring this compatibility. 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 DES which can be used to verify correctness and which uses an algorithm
algorithm which is freely exportable from the US, and a stress-test which is freely exportable from the US, and a stress-test version which
version which uses very long passphrase and key sizes and a mixture uses very long passphrase and key sizes and a mixture of algorithms
of algorithms which can be used to verify the behaviour in extreme which can be used to verify the behaviour in extreme cases.
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 derivation stage and a full test of the key wrapping. Both tests use a
a DES-CBC key derived from the password "password" with salt { 12 34 DES-CBC key derived from the password "password" with salt { 12 34 56
56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known answer
answer test the IV is set to all zeroes (equivalent to using ECB) and test the IV is set to all zeroes (equivalent to using ECB) and used to
used to encrypt an all-zero data block. 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
skipping to change at line 435 skipping to change at line 390
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 {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK (1 2 840 113549 1 9 16 3 9)
33 30 17: SEQUENCE { 33 30 17: SEQUENCE {
35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7) 35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7)
42 04 8: OCTET STRING 42 04 8: OCTET STRING
: EF E5 98 EF 21 B3 3D 6D : EF E5 98 EF 21 B3 3D 6D
: } : }
52 04 16: OCTET STRING : }
68 04 16: OCTET STRING
: B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 : 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 n-
entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12} entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12}
using 500 iterations of PBKDF2. using 500 iterations of PBKDF2.
PKCS #5v2 values: PKCS #5v2 values:
skipping to change at line 502 skipping to change at line 460
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 {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK (1 2 840 113549 1 9 16 3 9)
34 30 20: SEQUENCE { 34 30 20: SEQUENCE {
36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) 36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
46 04 8: OCTET STRING 46 04 8: OCTET STRING
: BA F1 CA 79 31 21 3C 4E : BA F1 CA 79 31 21 3C 4E
: } : }
56 04 40: OCTET STRING : }
71 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, can be found in RFC 2640 and PKCS5v2. More importantly, however, when
when used with a password the security of this information type rests used with a password the security of this information type rests on the
on the entropy of the user-selected password, which is typically entropy of the user-selected password, which is typically quite low.
quite low. Pass phrases (as opposed to simple passwords) are STRONGLY Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED,
RECOMMENDED, although it should be recognized that even with pass although it should be recognized that even with pass phrases it will be
phrases it will be difficult to use this recipient information type difficult to use this recipient information type to derive a KEK with
to derive a KEK with sufficient entropy to properly protect a 128-bit sufficient entropy to properly protect a 128-bit (or higher) CEK.
(or higher) CEK.
5. IANA Considerations
The PasswordRecipientInfo key encryption algorithms are identified by
object identifiers (OIDs). OIDs were assigned from an arc contributed
to the S/MIME Working Group by the RSA Security. Should additional
compression algorithms be introduced, the advocates for such algorithms
are expected to assign the necessary OIDs from their own arcs. No
action by the IANA is necessary for this document or any anticipated
updates.
Acknowledgments
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
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 pgut001@cs.auckland.ac.nz
References References
ASN1 Recommendation X.680: Specification of Abstract Syntax ASN1 CCITT Recommendation X.208: Specification of Abstract Syntax
Notation One (ASN.1), 1994. Notation One (ASN.1), 1988.
RFC2119 Key Words for Use in RFCs 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,
March 1998.
RFC2630 Cryptographic Message Syntax, R.Housley, June 1999. RFC2630 Cryptographic Message Syntax, R.Housley, June 1999.
RFC2898 PKCS #5: Password-Based Cryptography Specification, Version RFC2898 PKCS #5: Password-Based Cryptography Specification, Version
2.0, B.Kaliski, September 2000. 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:1988 Module Appendix A: ASN.1:1988 Module
PasswordRecipientInfo 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(12) } smime(16) modules(0) pwri(17) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) AlgorithmIdentifier
pkcs-5(5) } FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1)
PBKDF2-params, PBES2-Encs; authenticationFramework(7) 3 }
CMSVersion, EncryptedKey
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
-- The following PDU is defined in PKCS5 { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16)
-- pkcs5v2-0(1) }, however it can't be imported because because
-- it's specified in 1994/1997 ASN.1. Because of this it's copied
-- here from the source but rephrased as 1988 ASN.1. Further
-- details are given in [RFC 2898].
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }
-- The PRF algorithm is also defined in PKCS5 and can neither be
-- imported nor expressed in 1988 ASN.1, however it is encoded as
-- an AlgorithmIdentifier with the OID:
id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 7 }
-- and NULL parameters. Further details are given in [RFC 2898].
-- Implementation note: Because of the inability to precisely
-- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it is
-- likely that implementors will also encounter alternative
-- interpretations of these parameters, usually using an alternate
-- OID from the IPsec arc which is generally used for HMAC-SHA1:
--
-- hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
-- identified-organization(3) dod(6) internet(1) security(5)
-- mechanisms(5) 8 1 2 }
--
-- with absent (rather than NULL) parameters.
-- The PasswordRecipientInfo
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 }
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 }
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifer ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
END END -- PasswordRecipientInfo-88 --
Appendix B: ASN.1:1994 Module Appendix B: ASN.1:1997 Module
This appendix contains the same information as Appendix A in a more This appendix contains the same information as Appendix A in a more
recent (and precise) ASN.1 notation, however Appendix A takes recent (and precise) ASN.1 notation, however Appendix A takes
precedence in case of conflict. precedence in case of conflict.
PasswordRecipientInfo PasswordRecipientInfo-97
{ 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(12) } smime(16) modules(0) pwri(18) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
id-PBKDF2, PBKDF2-params,
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;
CMSVersion, EncryptedKey, des-ede3-cbc, CBCParameter
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
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 }
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 }
KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { KeyDerivationAlgorithmIdentifier ::=
{ SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, AlgorithmIdentifier {{ KeyDerivationAlgorithms }}
KeyDerivationAlgorithms ALGORITHM ::= {
{ OID id-PBKDF2 PARMS PBKDF2-params },
... ...
} }
KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyEncryptionAlgorithms }}
END KeyEncryptionAlgorithms ALGORITHM ::= {
{ OID id-alg-PWRI-KEK PARMS
AlgorithmIdentifier {{ PWRIAlgorithms }} },
...
}
-- Algorithm identifiers for algorithms used with the
-- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is a
-- MUST, all others are optional
PWRIAlgorithms ALGORITHM ::= {
{ OID des-ede3-cbc PARMS CBCParameter },
...
}
-- Supporting definitions. We could also pull in the
-- AlgorithmIdentifier from an appropriately recent X.500 module (or
-- wherever) but it's just as easy (and more convenient for readers)
-- to provide a definition here
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
END -- PasswordRecipientInfo-97 --
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 2000. 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 others, and derivative works that comment on or otherwise explain it or
or assist in its implementation may be prepared, copied, published assist in its implementation may be prepared, copied, published and
and distributed, in whole or in part, without restriction of any distributed, in whole or in part, without restriction of any kind,
kind, provided that the above copyright notice and this paragraph are 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 document itself may not be modified in any way, such as by removing the
the copyright notice or references to the Internet Society or other copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of developing
developing Internet standards in which case the procedures for Internet standards in which case the procedures for copyrights defined
copyrights defined in the Internet Standards process must be in the Internet Standards process must be followed, or as required to
followed, or as required to translate it into languages other than translate it into languages other than English.
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 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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/