Re: A New Triple-DES Key Wrap Algorithm

Don:

In regard to number 3, it seems like using a random IV for the first
encryption is a very good idea.

Russ

At 11:07 AM 2/22/99 -0500, Don Johnson wrote:
> Russ,
>
> Here are some thoughts.
>
> 1. Use of HMAC (using SHA-1) versus simple SHA-1 of the key may give
> security properties that are easier to show and be more conforming to
> existing stds. It can also grow easier, one never knows how these things
> might grow.
> 2. You need to indicate if the parity bits are checked or not on recovery.
> I suggest that they should be checked, since they are set.  This provides
> some more integrity.
> 3. The use of fixed IV's means that the first block of each encryption is
> less protected than the subsequent blocks.  This makes analysis more
> difficult.  If I were going to attack this method, I would concentrate on
> the less protected blocks, trying to find a match after less than 2**32
> encryptions.  This is not a complete idea but may be a start.  That is, the
> middle 2 blocks seem to collide in 2**32 encryptions, but the end blocks
> might collide sooner.
> 4. I still think you should try to list some goals for this method.  For
> example, 64 bits of integrity, every bit depends on every other bit,
> confidentiality for key, etc.
>
> Don Johnson
>
>
>
>
> Russ Housley <housley(_at_)spyrus(_dot_)com> on 02/20/99 04:17:39 PM
>
> To:   ietf-smime(_at_)imc(_dot_)org
> cc:   burt(_at_)RSA(_dot_)COM, djohnson(_at_)certicom(_dot_)ca, 
> schneier(_at_)counterpane(_dot_)com,
>      denny(_at_)tis(_dot_)com, 
> denning(_at_)cs(_dot_)cosc(_dot_)georgetown(_dot_)edu, 
> omura(_at_)cylink(_dot_)com,
>      mhetzel(_at_)bell-labs(_dot_)com, benaloh(_at_)microsoft(_dot_)com, 
> brickell(_at_)certco(_dot_)com,
>      smatyas(_at_)us(_dot_)ibm(_dot_)com, paulv(_at_)entrust(_dot_)com, 
> merkle(_at_)parc(_dot_)xerox(_dot_)com,
>      berson(_at_)anagram(_dot_)com, desmedt(_at_)uwm(_dot_)edu, 
> rivest(_at_)theory(_dot_)lcs(_dot_)mit(_dot_)edu,
>      carlisle(_dot_)adams(_at_)entrust(_dot_)com, ams(_at_)terisa(_dot_)com, 
> ekr(_at_)rtfm(_dot_)com,
>      Blake(_dot_)greenlee(_at_)greenlee(_dot_)com, cme(_at_)ACM(_dot_)ORG, 
> bfox(_at_)microsoft(_dot_)com,
>      acc(_at_)tycho(_dot_)ncsc(_dot_)mil, bschanni(_at_)BayNetworks(_dot_)com,
>      dickie(_at_)EMPIRE(_dot_)eclipse(_dot_)ncsc(_dot_)mil, 
> jhs(_at_)tycho(_dot_)ncsc(_dot_)mil, jis(_at_)mit(_dot_)edu,
>      pcain(_at_)bbn(_dot_)com, kent(_at_)bbn(_dot_)com, 
> BSnow(_at_)radium(_dot_)ncsc(_dot_)mil,
>      cjwagne(_at_)missi(_dot_)ncsc(_dot_)mil, balenson(_at_)tis(_dot_)com, 
> balenson(_at_)tis(_dot_)com,
>      jlinn(_at_)securitydynamics(_dot_)com, 
> smid(_at_)csmes(_dot_)ncsl(_dot_)nist(_dot_)gov,
>      daw(_at_)cs(_dot_)berkeley(_dot_)edu (bcc: Don Johnson/Certicom)
> Subject:  Re: A New Triple-DES Key Wrap Algorithm
>
>
>
>
> 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.