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

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Sat, 20 Feb 1999 18:26:11 -0800

I agree with the amount of time that it takes to implement with a good
library.  It took me about 1.5 hours, but I was listing to A Prairie Home
Companion rather than watching a Jimmy Stewart movie.

The most difficult part of the process was convencing my decode routines
that PKCS#1 padding was not required to exist on the object.

Before you start producing test vectors, I want to see the expansion of the
algorithm to deal with the problems of encryption key material which does
not pad out to 8 byte boundries. What are you planning to do with lengths or
known padding for doing 40-bit RC2 keys.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Saturday, February 20, 1999 1:18 PM
To: [email-masked]

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

>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.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 23 Feb 1999 13:25:13 +0000

I originally put this forward as a throw away comment but since Burt
Kaliski seemed to like the idea (it was me that made the initial
suggestion: I think the quoting got messed up somewhere) I'll suggest it
again a bit more formally as a possible alternative.

The idea is very simple. Treat the mailing list key (MLK) exactly as if
it was a S-S DH shared secret ZZ. In particular a salt is mandatory and
the KEK is derived using X9.42.

IMHO this has several things in its favour.

1. Any conformant CMS implementation will already have implemented the
key derivation algorithm and test vectors already exist: which have been
independently checked.

2. The problem of using the same KEK a large number of times is avoided
because the mandatory use of a salt ensures the KEK is different each
time for a given MLK (assuming the salts are different of course).

3. The same MLK can be used with algortihms with different key sizes.

4. If there is a weakness with this algortithm then I would suggest
there must also be a weakness in S-S DH in which case we shouldn't be
using either.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
NOTE NEW (13/12/98) PGP key: via homepage.

---

From: EKR <[email-masked]>
Date: 23 Feb 1999 08:04:22 -0800

> the KEK is derived using X9.42.
I think this is a good idea. I second it.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]