Subject: RE: New Triple-DES Key Wrap Algorithm Section

From: Paul Van Oorschot <[email-masked]>
Date: Fri, 5 Mar 1999 10:50:48 -0500

Russ - does this mean that you have chosen a new, non-standard algorithm?

Paul.

> ----------
> From: 	Russ Housley[SMTP:[email-masked]]
> Sent: 	Thursday, March 04, 1999 11:51 AM
> To: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: 	New Triple-DES Key Wrap Algorithm Section
> 
> All:
> 
> I greatly appreciate the work that everyone has put into the open debate
> on
> key wrapping.
> 
> The 44th IETF meeting is coming up rapidly, and I would like to close this
> debate prior to the meeting.  To that end, I selected the
> double-encryption
> algorithm.  An updated CMS document has not been posted yet, so I have
> attached the text associated with key wrapping.
> 
> Based on the discussion on this list, I believe that the double-encryption
> algorithm meet the security requirements, and it is easily implemented
> with
> building blocks that are otherwise needed to implement CMS.
> 
> I will gladly facilitate the further discussion of the general wrapping
> algorithm if the participants are interested.  I do not think that
> discussion should occur on the IETF S/MIME Working Group mail list, but I
> will arrange for a separate list to be created if you want to pursue the
> general wrap algorithm.
> 
> Russ
> 
> 
> = = = = = = = = = =
> 
> 12.6  Triple-DES and RC2 Key Wrap Algorithms
> 
>    CMS implementations must include encryption of a Triple-DES content-
>    encryption key with a Triple-DES key-encryption key using the
>    algorithm specified in Sections 12.6.2 and 12.6.3.  CMS
>    implementations should include encryption of a RC2 content-encryption
>    key with a RC2 key-encryption key using the algorithm specified in
>    Sections 12.6.4 and 12.6.5.  Triple-DES and RC2 content-encryption
>    keys are encrypted in Cipher Block Chaining (CBC) mode [MODES].
> 
>    Key Transport algorithms allow for the content-encryption key to be
>    directly encrypted; however, key agreement and symmetric key-
>    encryption key algorithms encrypt the content-encryption key with a
>    second symmetric encryption algorithm.  This section describes how
>    the Triple-DES or RC2 content-encryption key is formatted and
>    encrypted.
> 
>    Key agreement algorithms generate a pairwise key-encryption key, and
>    a key wrap algorithm is used to encrypt the content-encryption key
>    with the pairwise key-encryption key.  Similarly, a key wrap
>    algorithm is used to encrypt the content-encryption key in a
>    previously distributed key-encryption key.
> 
>    The key-encryption key is generated by the key agreement algorithm or
>    distributed out of band.  For key agreement of RC2 key-encryption
>    keys, 128 bits must be generated as input to the key expansion
>    process used to compute the RC2 effective key [RC2].
> 
>    The same algorithm identifier is used for both 2-key and 3-key
>    Triple-DES.  When the length of the content-encryption key to be
>    wrapped is a 2-key Triple-DES key, a third key with the same value as
>    the first key is created.  Thus, all Triple-DES content-encryption
>    keys are wrapped like 3-key Triple-DES keys.
> 
> 12.6.1  Key Checksum
> 
>    The CMS Checksum Algorithm is used to provide a content-encryption
>    key integrity check value.  The algorithm is:
> 
>    1.  Compute a 20 octet SHA-1 [SHA1] message digest on the
>        content-encryption key.
>    2.  Use the most significant (first) eight octets of the message
>        digest value as the checksum value.
> 
> 12.6.2  Triple-DES Key Wrap
> 
>    The Triple-DES key wrap algorithm encrypts a Triple-DES content-
>    encryption key with a 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 content-encryption key, call the result CEK.
>    2.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1, call the result ICV.
>    3.  Let CEKICV = CEK || ICV.
>    4.  Generate 8 octets at random, call the result IV.
>    5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>        the random value generated in the previous step as the
>        initialization vector (IV).  Call the ciphertext TEMP1.
>    6.  Let TEMP2 = IV || TEMP1.
>    7.  Reverse the order of the octets in TEMP2.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP3.
>    8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
>        an initialization vector (IV) of 0x4adda22c79e82105.
>        The ciphertext is 40 octets long.
> 
>    Note:  When the same content-encryption key is wrapped in different
>    key-encryption keys, a fresh initialization vector (IV) must be
>    generated for each invocation of the key wrap algorithm.
> 
> 12.6.3  Triple-DES Key Unwrap
> 
>    The Triple-DES key unwrap algorithm decrypts a Triple-DES content-
>    encryption key using a Triple-DES key-encryption key.  The Triple-DES
>    key unwrap algorithm is:
> 
>    1.  If the wrapped content-encryption key is not 40 octets, then
>        error.
>    2.  Decrypt the wrapped content-encryption key in CBC mode using
>        the key-encryption key.  Use an initialization vector (IV)
>        of 0x4adda22c79e82105.  Call the output TEMP3.
>    3.  Reverse the order of the octets in TEMP3.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP2.
>    4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
>        significant (first) 8 octets, and TEMP1 is the least significant
>        (last) 32 octets.
>    5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
>        the IV value from the previous step as the initialization vector.
>        Call the ciphertext CEKICV.
>    6.  Decompose the CEKICV into CEK and ICV. CEK is the most significant
>        (first) 24 octets, and ICV is the least significant (last) 8
> octets.
>    7.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1.  If the computed key checksum value does not
>        match the decrypted key checksum value, ICV, then error.
>    8.  Check for odd parity each of the DES key octets comprising CEK.
>        If parity is incorrect, then there is an error.
>    9. Use CEK as the content-encryption key.
> 
> 12.6.4  RC2 Key Wrap
> 
>    The RC2 key wrap algorithm encrypts a RC2 content-encryption key with a
> 
>    RC2 key-encryption key.  The RC2 key wrap algorithm is:
> 
>    1.  Let the content-encryption key be called CEK, and let the length
>        of the content-encryption key in octets be called LENGTH.
>    2.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1, call the result ICV.
>    3.  Let CEKICV = LENGTH || CEK || ICV.  LENGTH is a single octet.
>    4.  Let CEKICVPAD = CEKICV || PAD.  If the length of CEKICV is a
>        multiple of 8, the PAD has a length of zero.  If the length of
>        CEKICV is not a multiple of 8, then PAD contains the fewest
>        number of random octets to make CEKICVPAD a multiple of 8.
>    5.  Generate 8 octets at random, call the result IV.
>    5.  Encrypt CEKICVPAD in CBC mode using the key-encryption key.
>        Use the random value generated in the previous step as the
>        initialization vector (IV).  Call the ciphertext TEMP1.
>    6.  Let TEMP2 = IV || TEMP1.
>    7.  Reverse the order of the octets in TEMP2.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP3.
>    8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
>        an initialization vector (IV) of 0x4adda22c79e82105.
> 
>    Note:  When the same content-encryption key is wrapped in different
>    key-encryption keys, a fresh initialization vector (IV) must be
>    generated for each invocation of the key wrap algorithm.
> 
> 12.6.5  RC2 Key Unwrap
> 
>    The RC2 key unwrap algorithm decrypts a RC2 content-encryption key
>    using a RC2 key-encryption key.  The RC2 key unwrap algorithm is:
> 
>    1.  If the wrapped content-encryption key is not a multiple of 8
>        octets, then error.
>    2.  Decrypt the wrapped content-encryption key in CBC mode using
>        the key-encryption key.  Use an initialization vector (IV)
>        of 0x4adda22c79e82105.  Call the output TEMP3.
>    3.  Reverse the order of the octets in TEMP3.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP2.
>    4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
>        significant (first) 8 octets, and TEMP1 is the remaining octets.
>    5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
>        the IV value from the previous step as the initialization vector.
>        Call the ciphertext CEKICVPAD.
>    6.  Decompose the CEKICVPAD into LENGTH, CEK, ICV, and PAD.  LENGTH is
>        the most significant (first) octet.  CEK is the following LENGTH
>        octets.  ICV is the following 8 octets.  PAD is the remaining
>        octets, if any.
>    7.  If PAD is more than 7 octets, then error.
>    8.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1.  If the computed key checksum value does not
>        match the decrypted key checksum value, ICV, then error.
>    9.  Use CEK as the content-encryption key.
> 
> Security Considerations
> 
>    Section 12.6 specifies key wrap algorithms used to encrypt a Triple-
>    DES [3DES] content-encryption key with a Triple-DES key-encryption
>    key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
>    encryption key.  The key wrap algorithms make use of CBC mode
>    [MODES].  These key wrap algorithms have been reviewed for use with
>    Triple and RC2.  They have not been reviewed for use with other
>    cryptographic modes or other encryption algorithms.  Therefore, if a
>    CMS implementation wishes to support ciphers in addition to Triple-
>    DES or RC2, then additional key wrap algorithms need to be defined to
>    support the additional ciphers.
> 
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 05 Mar 1999 13:38:45 -0500

Paul:

I would not be going through this effort at all if there was a standard way
to encrypt one Triple-DES key with another.  This effort is defining the
standard....

Russ

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Fri, 12 Mar 1999 10:00:21 -0800

Russ,

I would like to see some changes to the RC2 key wrap algorithm to make it
easier to implement both the RC2 and 3DES wrapping using the same code.  The
core change is that the formatting and padding are done PRIOR to computing
the ICV value and thus all the code from step 4 on is the same for both the
RC2 Key wrap and the 3DES key wrap.

1.  LENGTH = sizeof(CEK)
2.  PAD = random(8 - (LENGTH + 1) % 8)
3.  TMP1 = LENGHT || CEK || PAD
4.  ICV = SHA_8(TMP1)
5.  TMP2 = ENC(TMP1 || ICV, IV)
6.  TMP3 = IV || TMP2
7.  TMP4 = REVERSE(TMP3)
8.  TMP5 = ENC(TMP4, constantIV)

This means that the KEK wrap routine is on constant data and the padding
also happens to be protected.  I suppose there is a possible attack with the
padding, but if the verification routine checks the pad length I doubt it is
possible.  However this means that I have one method of doing KEK rather
than 2.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, March 04, 1999 8:52 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; Josh Benaloh; Barb Fox (Exchange);
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: New Triple-DES Key Wrap Algorithm Section

All:

I greatly appreciate the work that everyone has put into the open debate on
key wrapping.

The 44th IETF meeting is coming up rapidly, and I would like to close this
debate prior to the meeting.  To that end, I selected the double-encryption
algorithm.  An updated CMS document has not been posted yet, so I have
attached the text associated with key wrapping.

Based on the discussion on this list, I believe that the double-encryption
algorithm meet the security requirements, and it is easily implemented with
building blocks that are otherwise needed to implement CMS.

Russ

= = = = = = = = = =

12.6.1  Key Checksum

       (first) 24 octets, and ICV is the least significant (last) 8 octets.

12.6.4  RC2 Key Wrap

12.6.5  RC2 Key Unwrap

Security Considerations