Subject: Re: A New Triple-DES Key Wrap Algorithm

From: Russ Housley <[email-masked]>
Date: Tue, 16 Feb 1999 11:24:56 -0500

All:

As the open and public debate continues, I see no one supporting the second
approach described in my 7 Feb 1999 message.  I think we can abandon that
approach, leaving two approaches to Triple-DES key wrapping.  Changes
(hopefully they are improvements) have been suggested for both remaining
approaches.  In this note, I list two updated approaches that are still being
considered.  To keep this note short, I have omitted the unwrap algorithm
description.  The double encryption approach has a shorter result, but the
OAEP-based approach has the all-or-nothing-transform (AONT) property that seems
quite useful.

A MAC-and-Encrypt alternative was suggested.  I am not willing to pursue this
approach due a potential patent issue.  For people who are interested, see
Patent Number 5,673,319.

The S/MIME v3 specifications will include the selected Triple-DES key wrap
algorithm as well as a variant for wrapping RC2 keys (40-128 bit keys).

Please review the algorithms.  Please do not propose improvements that are
covered by any issued or pending patents.

I would like to hear from anyone who has a preference regarding these two
alternatives.

Thanks for your assistance,
  Russ

= = = = = = = = = = 

WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION

Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the 
    content-encryption key.
2.  Use the most significant (first) eight octets of the 
    message digest value as the checksum value.

Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key, call the result CEK.
2.  Compute a 8 octet key checksum value on CEK as described above,
    call the result ICV.
3.  Let CEKICV = CEK || ICV.
4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
    an IV of 0xc302e3c1ad8bb738.
5.  Reverse the order of the ciphertext octets.  That is, the most
    significant (first) octet is swapped with the least significant
    (last) octet, and so on.  Call the result TEMP.
6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.

WRAP ALOGRITHM #2:  MASK AND ENCRYPT

This algorithm is no longer being considered.

WRAP ALOGRITHM #3:  OAEP AND ENCRYPT

Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key, call the result CEK.
2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
3.  Generate a 160-bit random value, called RAND.
4.  Let H1 = SHA-1 ( RAND ).
5.  Let H2 = SHA-1 ( H1 ).
6.  Let MASK1 equal the most significant (first) 36 octets of H2 || H1.
7.  Let MKEY = CEKPAD XOR MASK1.
8.  Let MASK2 = SHA-1 ( MKEY ).
9.  Let MRAND = MASK2 XOR RAND.
10. Let MDATA = MRAND || MKEY.
11. Encrypt MDATA in CBC mode using the key-encryption key.  Use 
    an IV of 0x61a197e5b132e196.  The ciphertext is 56 octets long.

---

From: Russ Housley <[email-masked]>
Date: Sat, 20 Feb 1999 16:17:39 -0500

All:

Right now, I am leaning toward the double encryption wrap algorithm.  I
think it will be easy to implement, and it yeilds a shorter result that the
OAEP method.  To convince myself that it was easy to implement, I did an
implementation.  It took me about two hours while watching an old Jimmy
Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
routines.  S/MIME v3 will require these algorithms for other capabilities
besides key wrapping.

If someone else is willing to do an implementation, I would like to compare
results.  This will allow a test vector to be included with the algorithm
description.

Does anyone have any strong objections to the double encryption wrap
algorithm being selected?

Russ