 1/draftietfsmimekeywrap00.txt 20060205 01:51:41.000000000 +0100
+++ 2/draftietfsmimekeywrap01.txt 20060205 01:51:41.000000000 +0100
@@ 1,18 +1,18 @@
S/MIME Working Group R. Housley
Internet Draft RSA Laboratories
expires in six months September 2001
TripleDES and RC2 Key Wrapping

+
Status of this Memo
This document is an InternetDraft and is in full conformance with
all provisions of Section 10 of RFC2026. InternetDrafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as InternetDrafts.
InternetDrafts are draft documents valid for a maximum of six months
@@ 54,58 +54,55 @@
wrap algorithms are commonly used in two situations. First, key
agreement algorithms (such as DiffieHellman [DHX9.42]) generate a
pairwise keyencryption key, and a key wrap algorithm is used to
encrypt the contentencryption key or a multicast key with the
pairwise keyencryption key. Second, a key wrap algorithm is used to
encrypt the contentencryption key, multicast key, or session key in
a locally generated storage keyencryption key or a keyencryption
key that was distributed outofband.
This document specifies the algorithm for wrapping one TripleDES key
 with another TripleDES key [3DES] and specifies the algorithm for
 wrapping one RC2 key with another RC2 key [RC2]. Encryption of a
+ with another TripleDES key [3DES], and it specifies the algorithm
+ for wrapping one RC2 key with another RC2 key [RC2]. Encryption of a
TripleDES key with another TripleDES key uses the algorithm
specified in section 3. Encryption of a RC2 key with another RC2 key
uses the algorithm specified in section 4. Both of these algorithms
rely on the key checksum algorithm specified in section 2. Triple
DES and RC2 contentencryption keys are encrypted in Cipher Block
Chaining (CBC) mode [MODES].
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described
by Scott Bradner in [STDWORDS].
 The same key wrap algorithm is used for both Twokey TripleDES and
 Threekey TripleDES keys. When a Twokey TripleDES key is to be
 wrapped, a third DES key with the same value as the first DES key is
 created. Thus, all wrapped TripleDES keys include three DES keys.
 However, a Twokey TripleDES key MUST NOT be used to wrap a Three
 key TripleDES key that is comprised of three unique DES keys.

 RC2 supports variable length keys. RC2 128bit keys MUST be used as
 keyencryption keys; however, the wrapped RC2 key MAY be of any size.

2 Key Checksum
The key checksum algorithm is used to provide a key integrity check
value. The algorithm is:
1. Compute a 20 octet SHA1 [SHA1] message digest on the key
that is to be wrapped.
2. Use the most significant (first) eight octets of the message
digest value as the checksum value.
3 TripleDES Key Wrapping and Unwrapping
This section specifies the algorithms for wrapping and unwrapping one
TripleDES key with another TripleDES key [3DES].
+ The same key wrap algorithm is used for both Twokey TripleDES and
+ Threekey TripleDES keys. When a Twokey TripleDES key is to be
+ wrapped, a third DES key with the same value as the first DES key is
+ created. Thus, all wrapped TripleDES keys include three DES keys.
+ However, a Twokey TripleDES key MUST NOT be used to wrap a Three
+ key TripleDES key that is comprised of three unique DES keys.
+
3.1 TripleDES Key Wrap
The TripleDES key wrap algorithm encrypts a TripleDES key with a
TripleDES keyencryption key. The TripleDES key wrap algorithm is:
1. Set odd parity for each of the DES key octets comprising the
ThreeKey TripleDES key that is to be wrapped, call the result
CEK.
2. Compute an 8 octet key checksum value on CEK as described above
in Section 2, call the result ICV.
@@ 161,25 +157,49 @@
Some security protocols employ ASN.1 [X.20888, X.20988], and these
protocols employ algorithm identifiers to name cryptographic
algorithms. To support these protocols, the TripleDES key wrap
algorithm has been assigned the following algorithm identifier:
idalgCMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field MUST be NULL.
+3.4 TripleDES Key Wrap Example
+
+ This section contains a TripleDES Key Wrap example. Intermediate
+ values corresponding to the named items in section 3.1 are given in
+ hexadecimal.
+
+ 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
+ ICV: 181b 7e96 86e0 4a4e
+ CEKICV: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
+ 181b 7e96 86e0 4a4e
+ IV: 5dd4 cbfc 96f5 453b
+ TEMP1: cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 3b97 7a79 60f6
+ a44d cc5f 729d 8449
+ TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03
+ 5c1f 3b97 7a79 60f6 a44d cc5f 729d 8449
+ TEMP3: 4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4
+ 2add 75c6 89a7 c1cf 3b45 f596 fccb d45d
+ RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403
+ 7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4
+
4 RC2 Key Wrapping and Unwrapping
This section specifies the algorithms for wrapping and unwrapping one
RC2 key with another RC2 key [RC2].
+ RC2 supports variable length keys. RC2 128bit keys MUST be used as
+ keyencryption keys; however, the wrapped RC2 key MAY be of any size.
+
4.1 RC2 Key Wrap
The RC2 key wrap algorithm encrypts a RC2 key with a RC2 key
encryption key. The RC2 key wrap algorithm is:
1. Let the RC2 key be called CEK, and let the length of CEK in
octets be called LENGTH. LENGTH is a single octet.
2. Let LCEK = LENGTH  CEK.
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
@@ 248,20 +268,49 @@
RC2ParameterVersion ::= INTEGER
The RC2 effectivekeybits (key size) greater than 32 and less than
256 is encoded in the RC2ParameterVersion. For the effectivekey
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
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),
because the one octet (A0) encoding represents a negative number.
+3.4 RC2 Key Wrap Example
+
+ This section contains a RC2 Key Wrap example. Intermediate values
+ corresponding to the named items in section 4.1 are given in
+ hexadecimal.
+
+ CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9
+ KEK: fd04 fd08 0607 07fb 0003 feff fd02 fe05
+ LENGTH: 10
+ LCEK: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9
+ PAD: 4845 cce7 fd12 50
+ LCEKPAD: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
+ d948 45cc e7fd 1250
+ ICV: 0a6f f19f db40 4988
+ LCEKPADICV: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
+ d948 45cc e7fd 1250 0a6f f19f db40 4988
+ IV: c7d9 0059 b29e 97f7
+ TEMP1: a01d a259 3793 1260 e48c 55f5 04ce 70b8
+ ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7
+ TEMP2: c7d9 0059 b29e 97f7 a01d a259 3793 1260
+ e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932
+ 9fa9 8a07 a31f f7a7
+ TEMP3: a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac
+ b870 ce04 f555 8ce4 6012 9337 59a2 1da0
+ f797 9eb2 5900 d9c7
+ RESULT: 70e6 99fb 5701 f783 3330 fb71 e87c 85a4
+ 20bd c99a f05d 22af 5a0e 48d3 5f31 3898
+ 6cba afb4 b28d 4f35
+
References
3DES American National Standards Institute. ANSI X9.521998,
Triple Data Encryption Algorithm Modes of Operation. 1998.
CMS Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
DES American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems  Data
@@ 322,22 +371,23 @@
reviewed for use with TripleDES and RC2, and they have not been
reviewed for use with other encryption algorithms. Similarly, the
key wrap algorithms make use of CBC mode [MODES], and they have not
been reviewed for use with other cryptographic modes.
Acknowledgments
This document is the result of contributions from many professionals.
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
 Jueneman, Don Johnson, and Burt Kaliski for their support in defining
 these algorithms.
+ Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for
+ their support in defining these algorithms and generating this
+ specification.
Author Address
Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA
rhousley@rsasecurity.com