draft-ietf-smime-key-wrap-01.txt   rfc3217.txt 
S/MIME Working Group R. Housley Network Working Group R. Housley
Internet Draft RSA Laboratories Request for Comments: 3217 RSA Laboratories
expires in six months September 2001 Category: Informational December 2001
Triple-DES and RC2 Key Wrapping Triple-DES and RC2 Key Wrapping
<draft-ietf-smime-key-wrap-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. Internet-Drafts are working not specify an Internet standard of any kind. Distribution of this
documents of the Internet Engineering Task Force (IETF), its areas, memo is unlimited.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the Copyright (C) The Internet Society (2001). All Rights Reserved.
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document specifies the algorithm for wrapping one Triple-DES This document specifies the algorithm for wrapping one Triple-DES key
[3DES] key with another Triple-DES key and the algorithm for wrapping with another Triple-DES key and the algorithm for wrapping one RC2
one RC2 [RC2] key with another RC2 key. These key wrap algorithms key with another RC2 key. These key wrap algorithms were originally
were originally published in section 12.6 of RFC 2630 [CMS]. They published in section 12.6 of RFC 2630. They are republished since
are republished since these key wrap algorithms have been found to be these key wrap algorithms have been found to be useful in contexts
useful in contexts beyond those supported by RFC 2630. beyond those supported by RFC 2630.
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
Management of symmetric cryptographic keys often leads to situations Management of symmetric cryptographic keys often leads to situations
where one symmetric key is used to encrypt (or wrap) another. Key where one symmetric key is used to encrypt (or wrap) another. Key
wrap algorithms are commonly used in two situations. First, key wrap algorithms are commonly used in two situations. First, key
agreement algorithms (such as Diffie-Hellman [DH-X9.42]) generate a agreement algorithms (such as Diffie-Hellman [DH-X9.42]) generate a
pairwise key-encryption key, and a key wrap algorithm is used to pairwise key-encryption key, and a key wrap algorithm is used to
encrypt the content-encryption key or a multicast key with the encrypt the content-encryption key or a multicast key with the
pairwise key-encryption key. Second, a key wrap algorithm is used to pairwise key-encryption key. Second, a key wrap algorithm is used to
skipping to change at page 2, line 37 skipping to change at page 2, line 14
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described
by Scott Bradner in [STDWORDS]. by Scott Bradner in [STDWORDS].
2 Key Checksum 2 Key Checksum
The key checksum algorithm is used to provide a key integrity check The key checksum algorithm is used to provide a key integrity check
value. The algorithm is: value. The algorithm is:
1. Compute a 20 octet SHA-1 [SHA1] message digest on the key 1. Compute a 20 octet SHA-1 [SHA1] message digest on the key that is
that is to be wrapped. to be wrapped.
2. Use the most significant (first) eight octets of the message 2. Use the most significant (first) eight octets of the message
digest value as the checksum value. digest value as the checksum value.
3 Triple-DES Key Wrapping and Unwrapping 3 Triple-DES Key Wrapping and Unwrapping
This section specifies the algorithms for wrapping and unwrapping one This section specifies the algorithms for wrapping and unwrapping one
Triple-DES key with another Triple-DES key [3DES]. Triple-DES key with another Triple-DES key [3DES].
The same key wrap algorithm is used for both Two-key Triple-DES and The same key wrap algorithm is used for both Two-key Triple-DES and
Three-key Triple-DES keys. When a Two-key Triple-DES key is to be Three-key Triple-DES keys. When a Two-key Triple-DES key is to be
skipping to change at page 3, line 13 skipping to change at page 2, line 39
key Triple-DES key that is comprised of three unique DES keys. key Triple-DES key that is comprised of three unique DES keys.
3.1 Triple-DES Key Wrap 3.1 Triple-DES Key Wrap
The Triple-DES key wrap algorithm encrypts a Triple-DES key with a The Triple-DES key wrap algorithm encrypts a Triple-DES key with a
Triple-DES key-encryption key. The Triple-DES key wrap algorithm is: Triple-DES key-encryption key. The Triple-DES key wrap algorithm is:
1. Set odd parity for each of the DES key octets comprising the 1. Set odd parity for each of the DES key octets comprising the
Three-Key Triple-DES key that is to be wrapped, call the result Three-Key Triple-DES key that is to be wrapped, call the result
CEK. CEK.
2. Compute an 8 octet key checksum value on CEK as described above 2. Compute an 8 octet key checksum value on CEK as described above in
in Section 2, call the result ICV. Section 2, call the result ICV.
3. Let CEKICV = CEK || ICV. 3. Let CEKICV = CEK || ICV.
4. Generate 8 octets at random, call the result IV. 4. Generate 8 octets at random, call the result IV.
5. Encrypt CEKICV in CBC mode using the key-encryption key. Use 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use the
the random value generated in the previous step as the random value generated in the previous step as the initialization
initialization vector (IV). Call the ciphertext TEMP1. vector (IV). Call the ciphertext TEMP1.
6. Let TEMP2 = IV || TEMP1. 6. Let TEMP2 = IV || TEMP1.
7. Reverse the order of the octets in TEMP2. That is, the most 7. Reverse the order of the octets in TEMP2. That is, the most
significant (first) octet is swapped with the least significant significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP3. (last) octet, and so on. Call the result TEMP3.
8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use an
an initialization vector (IV) of 0x4adda22c79e82105. initialization vector (IV) of 0x4adda22c79e82105. The ciphertext
The ciphertext is 40 octets long. is 40 octets long.
Note: When the same Three-Key Triple-DES key is wrapped in different Note: When the same Three-Key Triple-DES key is wrapped in different
key-encryption keys, a fresh initialization vector (IV) must be key-encryption keys, a fresh initialization vector (IV) must be
generated for each invocation of the key wrap algorithm. generated for each invocation of the key wrap algorithm.
3.2 Triple-DES Key Unwrap 3.2 Triple-DES Key Unwrap
The Triple-DES key unwrap algorithm decrypts a Triple-DES key using a The Triple-DES key unwrap algorithm decrypts a Triple-DES key using a
Triple-DES key-encryption key. The Triple-DES key unwrap algorithm Triple-DES key-encryption key. The Triple-DES key unwrap algorithm
is: is:
1. If the wrapped key is not 40 octets, then error. 1. If the wrapped key is not 40 octets, then error.
2. Decrypt the wrapped key in CBC mode using the key-encryption 2. Decrypt the wrapped key in CBC mode using the key-encryption key.
key. Use an initialization vector (IV) of 0x4adda22c79e82105. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the
Call the output TEMP3. output TEMP3.
3. Reverse the order of the octets in TEMP3. That is, the most 3. Reverse the order of the octets in TEMP3. That is, the most
significant (first) octet is swapped with the least significant significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP2. (last) octet, and so on. Call the result TEMP2.
4. Decompose TEMP2 into IV and TEMP1. IV is the most significant 4. Decompose TEMP2 into IV and TEMP1. IV is the most significant
(first) 8 octets, and TEMP1 is the least significant (last) (first) 8 octets, and TEMP1 is the least significant (last) 32
32 octets. octets.
5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use the
the IV value from the previous step as the initialization vector. IV value from the previous step as the initialization vector.
Call the ciphertext CEKICV. Call the ciphertext CEKICV.
6. Decompose CEKICV into CEK and ICV. CEK is the most significant 6. Decompose CEKICV into CEK and ICV. CEK is the most significant
(first) 24 octets, and ICV is the least significant (last) (first) 24 octets, and ICV is the least significant (last) 8
8 octets. octets.
7. Compute an 8 octet key checksum value on CEK as described above 7. Compute an 8 octet key checksum value on CEK as described above in
in Section 2. If the computed key checksum value does not Section 2. If the computed key checksum value does not match the
match the decrypted key checksum value, ICV, then error. decrypted key checksum value, ICV, then error.
8. Check for odd parity each of the DES key octets comprising CEK. 8. Check for odd parity each of the DES key octets comprising CEK.
If parity is incorrect, then error. If parity is incorrect, then error.
9. Use CEK as a Triple-DES key. 9. Use CEK as a Triple-DES key.
3.3 Triple-DES Key Wrap Algorithm Identifier 3.3 Triple-DES Key Wrap Algorithm Identifier
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these Some security protocols employ ASN.1 [X.208-88, X.209-88], and these
protocols employ algorithm identifiers to name cryptographic protocols employ algorithm identifiers to name cryptographic
algorithms. To support these protocols, the Triple-DES key wrap algorithms. To support these protocols, the Triple-DES key wrap
algorithm has been assigned the following algorithm identifier: algorithm has been assigned the following algorithm identifier:
skipping to change at page 4, line 36 skipping to change at page 4, line 17
This section contains a Triple-DES Key Wrap example. Intermediate This section contains a Triple-DES Key Wrap example. Intermediate
values corresponding to the named items in section 3.1 are given in values corresponding to the named items in section 3.1 are given in
hexadecimal. hexadecimal.
CEK: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 CEK: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
KEK: 255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838 251f KEK: 255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838 251f
ICV: 181b 7e96 86e0 4a4e ICV: 181b 7e96 86e0 4a4e
CEKICV: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 CEKICV: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
181b 7e96 86e0 4a4e 181b 7e96 86e0 4a4e
IV: 5dd4 cbfc 96f5 453b IV: 5dd4 cbfc 96f5 453b
TEMP1: cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 3b97 7a79 60f6 TEMP1: cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 973b 7a79 60f6
a44d cc5f 729d 8449 a44d cc5f 729d 8449
TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03
5c1f 3b97 7a79 60f6 a44d cc5f 729d 8449 5c1f 973b 7a79 60f6 a44d cc5f 729d 8449
TEMP3: 4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4 TEMP3: 4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4
2add 75c6 89a7 c1cf 3b45 f596 fccb d45d 2add 75c6 89a7 c1cf 3b45 f596 fccb d45d
RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403 RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403
7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4 7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4
4 RC2 Key Wrapping and Unwrapping 4 RC2 Key Wrapping and Unwrapping
This section specifies the algorithms for wrapping and unwrapping one This section specifies the algorithms for wrapping and unwrapping one
RC2 key with another RC2 key [RC2]. RC2 key with another RC2 key [RC2].
skipping to change at page 5, line 14 skipping to change at page 4, line 43
4.1 RC2 Key Wrap 4.1 RC2 Key Wrap
The RC2 key wrap algorithm encrypts a RC2 key with a RC2 key- The RC2 key wrap algorithm encrypts a RC2 key with a RC2 key-
encryption key. The RC2 key wrap algorithm is: encryption key. The RC2 key wrap algorithm is:
1. Let the RC2 key be called CEK, and let the length of CEK in 1. Let the RC2 key be called CEK, and let the length of CEK in
octets be called LENGTH. LENGTH is a single octet. octets be called LENGTH. LENGTH is a single octet.
2. Let LCEK = LENGTH || CEK. 2. Let LCEK = LENGTH || CEK.
3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple
of 8, the PAD has a length of zero. If the length of LCEK is of 8, the PAD has a length of zero. If the length of LCEK is not
not a multiple of 8, then PAD contains the fewest number of a multiple of 8, then PAD contains the fewest number of random
random octets to make the length of LCEKPAD a multiple of 8. octets to make the length of LCEKPAD a multiple of 8.
4. Compute an 8 octet key checksum value on LCEKPAD as described 4. Compute an 8 octet key checksum value on LCEKPAD as described
above in Section 2, call the result ICV. above in Section 2, call the result ICV.
5. Let LCEKPADICV = LCEKPAD || ICV. 5. Let LCEKPADICV = LCEKPAD || ICV.
6. Generate 8 octets at random, call the result IV. 6. Generate 8 octets at random, call the result IV.
7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. Use
Use the random value generated in the previous step as the the random value generated in the previous step as the
initialization vector (IV). Call the ciphertext TEMP1. initialization vector (IV). Call the ciphertext TEMP1.
8. Let TEMP2 = IV || TEMP1. 8. Let TEMP2 = IV || TEMP1.
9. Reverse the order of the octets in TEMP2. That is, the most 9. Reverse the order of the octets in TEMP2. That is, the most
significant (first) octet is swapped with the least significant significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP3. (last) octet, and so on. Call the result TEMP3.
10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use an
an initialization vector (IV) of 0x4adda22c79e82105. initialization vector (IV) of 0x4adda22c79e82105.
Note: When the same RC2 key is wrapped in different key-encryption Note: When the same RC2 key is wrapped in different key-encryption
keys, a fresh initialization vector (IV) must be generated for each keys, a fresh initialization vector (IV) must be generated for each
invocation of the key wrap algorithm. invocation of the key wrap algorithm.
4.2 RC2 Key Unwrap 4.2 RC2 Key Unwrap
The RC2 key unwrap algorithm decrypts a RC2 key using a RC2 key- The RC2 key unwrap algorithm decrypts a RC2 key using a RC2 key-
encryption key. The RC2 key unwrap algorithm is: encryption key. The RC2 key unwrap algorithm is:
1. If the wrapped key is not a multiple of 8 octets, then error. 1. If the wrapped key is not a multiple of 8 octets, then error.
2. Decrypt the wrapped key in CBC mode using the key-encryption key. 2. Decrypt the wrapped key in CBC mode using the key-encryption key.
Use an initialization vector (IV) of 0x4adda22c79e82105. Call Use an initialization vector (IV) of 0x4adda22c79e82105. Call
the output TEMP3. the output TEMP3.
3. Reverse the order of the octets in TEMP3. That is, the most 3. Reverse the order of the octets in TEMP3. That is, the most
significant (first) octet is swapped with the least significant significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP2. (last) octet, and so on. Call the result TEMP2.
4. Decompose the TEMP2 into IV and TEMP1. IV is the most 4. Decompose the TEMP2 into IV and TEMP1. IV is the most
significant (first) 8 octets, and TEMP1 is the remaining octets. significant (first) 8 octets, and TEMP1 is the remaining octets.
5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use the
the IV value from the previous step as the initialization vector. IV value from the previous step as the initialization vector.
Call the plaintext LCEKPADICV. Call the plaintext LCEKPADICV.
6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the least
least significant (last) octet 8 octets. LCEKPAD is the significant (last) octet 8 octets. LCEKPAD is the remaining
remaining octets. octets.
7. Compute an 8 octet key checksum value on LCEKPAD as described 7. Compute an 8 octet key checksum value on LCEKPAD as described
above in Section 2. If the computed key checksum value does above in Section 2. If the computed key checksum value does not
not match the decrypted key checksum value, ICV, then error. match the decrypted key checksum value, ICV, then error.
8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the
most significant (first) octet. CEK is the following LENGTH most significant (first) octet. CEK is the following LENGTH
octets. PAD is the remaining octets, if any. octets. PAD is the remaining octets, if any.
9. If the length of PAD is more than 7 octets, then error. 9. If the length of PAD is more than 7 octets, then error.
10. Use CEK as an RC2 key. 10. Use CEK as an RC2 key.
4.3 RC2 Key Wrap Algorithm Identifier 4.3 RC2 Key Wrap Algorithm Identifier
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these Some security protocols employ ASN.1 [X.208-88, X.209-88], and these
protocols employ algorithm identifiers to name cryptographic protocols employ algorithm identifiers to name cryptographic
skipping to change at page 6, line 38 skipping to change at page 6, line 21
RC2ParameterVersion ::= INTEGER RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than The RC2 effective-key-bits (key size) greater than 32 and less than
256 is encoded in the RC2ParameterVersion. For the effective-key- 256 is encoded in the RC2ParameterVersion. For the effective-key-
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length. and 58 respectively. These values are not simply the RC2 key length.
Note that the value 160 must be encoded as two octets (00 A0), Note that the value 160 must be encoded as two octets (00 A0),
because the one octet (A0) encoding represents a negative number. because the one octet (A0) encoding represents a negative number.
3.4 RC2 Key Wrap Example 4.4 RC2 Key Wrap Example
This section contains a RC2 Key Wrap example. Intermediate values This section contains a RC2 Key Wrap example. Intermediate values
corresponding to the named items in section 4.1 are given in corresponding to the named items in section 4.1 are given in
hexadecimal. hexadecimal.
CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9 CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9
KEK: fd04 fd08 0607 07fb 0003 feff fd02 fe05 KEK: fd04 fd08 0607 07fb 0003 feff fd02 fe05
LENGTH: 10 LENGTH: 10
LCEK: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9 LCEK: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9
PAD: 4845 cce7 fd12 50 PAD: 4845 cce7 fd12 50
skipping to change at page 7, line 19 skipping to change at page 7, line 5
TEMP2: c7d9 0059 b29e 97f7 a01d a259 3793 1260 TEMP2: c7d9 0059 b29e 97f7 a01d a259 3793 1260
e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932 e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932
9fa9 8a07 a31f f7a7 9fa9 8a07 a31f f7a7
TEMP3: a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac TEMP3: a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac
b870 ce04 f555 8ce4 6012 9337 59a2 1da0 b870 ce04 f555 8ce4 6012 9337 59a2 1da0
f797 9eb2 5900 d9c7 f797 9eb2 5900 d9c7
RESULT: 70e6 99fb 5701 f783 3330 fb71 e87c 85a4 RESULT: 70e6 99fb 5701 f783 3330 fb71 e87c 85a4
20bd c99a f05d 22af 5a0e 48d3 5f31 3898 20bd c99a f05d 22af 5a0e 48d3 5f31 3898
6cba afb4 b28d 4f35 6cba afb4 b28d 4f35
References 5 References
3DES American National Standards Institute. ANSI X9.52-1998, [3DES] American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation. 1998. Triple Data Encryption Algorithm Modes of Operation.
1998.
CMS Housley, R., "Cryptographic Message Syntax", RFC 2630, [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
DES American National Standards Institute. ANSI X3.106, [DES] American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems - Data "American National Standard for Information Systems - Data
Link Encryption". 1983. Link Encryption". 1983.
DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. [DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
RFC 2631. June 1999. 2631, June 1999.
DSS National Institute of Standards and Technology. [DSS] National Institute of Standards and Technology. FIPS Pub
FIPS Pub 186: Digital Signature Standard. 19 May 1994. 186: Digital Signature Standard. 19 May 1994.
MODES National Institute of Standards and Technology. [MODES] National Institute of Standards and Technology. FIPS Pub
FIPS Pub 81: DES Modes of Operation. 2 December 1980. 81: DES Modes of Operation. 2 December 1980.
RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security. RFC 1750. December 1994. Recommendations for Security", RFC 1750, December 1994.
RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. [RC2] Rivest, R., "A Description of the RC2 (r) Encryption
RFC 2268. March 1998. Algorithm", RFC 2268, March 1998.
SHA1 National Institute of Standards and Technology. [SHA1] National Institute of Standards and Technology. FIPS Pub
FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 180-1: Secure Hash Standard. 17 April 1995.
STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels. RFC2119. March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
X.208-88 CCITT. Recommendation X.208: Specification of Abstract [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Rules for Abstract Syntax Notation One (ASN.1). 1988. Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
Security Considerations 6 Security Considerations
Implementations must protect the key-encryption key. Compromise of Implementations must protect the key-encryption key. Compromise of
the key-encryption key may result in the disclosure of all keys that the key-encryption key may result in the disclosure of all keys that
have been wrapped with the key-encryption key, which may lead to the have been wrapped with the key-encryption key, which may lead to the
disclosure of all traffic protected with those wrapped key. disclosure of all traffic protected with those wrapped key.
Implementations must randomly generate initialization vectors (IVs) Implementations must randomly generate initialization vectors (IVs)
and padding. The generation of quality random numbers is difficult. and padding. The generation of quality random numbers is difficult.
RFC 1750 [RANDOM] offers important guidance in this area, and RFC 1750 [RANDOM] offers important guidance in this area, and
Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique. Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
skipping to change at page 8, line 41 skipping to change at page 8, line 35
decrypt the content. Therefore, implementers must ensure that key- decrypt the content. Therefore, implementers must ensure that key-
encryption algorithms are as strong or stronger than content- encryption algorithms are as strong or stronger than content-
encryption algorithms. encryption algorithms.
These key wrap algorithms specified in this document have been These key wrap algorithms specified in this document have been
reviewed for use with Triple-DES and RC2, and they have not been reviewed for use with Triple-DES and RC2, and they have not been
reviewed for use with other encryption algorithms. Similarly, the reviewed for use with other encryption algorithms. Similarly, the
key wrap algorithms make use of CBC mode [MODES], and they have not key wrap algorithms make use of CBC mode [MODES], and they have not
been reviewed for use with other cryptographic modes. been reviewed for use with other cryptographic modes.
Acknowledgments 7 Acknowledgments
This document is the result of contributions from many professionals. This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Carl Ellison, Peter Gutmann, Bob Group. I extend a special thanks to Carl Ellison, Peter Gutmann, Bob
Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for
their support in defining these algorithms and generating this their support in defining these algorithms and generating this
specification. specification.
Author Address 8 Author Address
Russell Housley Russell Housley
RSA Laboratories RSA Laboratories
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
rhousley@rsasecurity.com EMail: rhousley@rsasecurity.com
Full Copyright Statement 9 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 others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, 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. In addition, the included on all such copies and derivative works. However, this
ASN.1 module presented in Appendix A may be used in whole or in part document itself may not be modified in any way, such as by removing
without inclusion of the copyright notice. However, this document the copyright notice or references to the Internet Society or other
itself may not be modified in any way, such as by removing the
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 Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to 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. This revoked by the Internet Society or its successors or assigns.
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK This document and the information contained herein is provided on an
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
OR FITNESS FOR A PARTICULAR PURPOSE. HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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