Re: A New Triple-DES Key Wrap Algorithm

"Don Johnson" <djohnson@certicom.com> Mon, 22 February 1999 16:06 UTC

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19992 for ietf-smime-bks; Mon, 22 Feb 1999 08:06:41 -0800 (PST)
Received: from eng1.certicom.com (mailhost.certicom.com [209.121.99.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA19988 for <ietf-smime@imc.org>; Mon, 22 Feb 1999 08:06:19 -0800 (PST)
Received: from domino2.certicom.com (domino2.certicom.com [10.0.1.25]) by eng1.certicom.com (8.8.7/8.8.7) with SMTP id LAA00383; Mon, 22 Feb 1999 11:12:43 -0500 (EST) (envelope-from djohnson@certicom.com)
Received: by domino2.certicom.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 85256720.0058E324 ; Mon, 22 Feb 1999 11:10:53 -0500
X-Lotus-FromDomain: CERTICOM
From: Don Johnson <djohnson@certicom.com>
To: Russ Housley <housley@spyrus.com>
cc: ietf-smime@imc.org, burt@RSA.COM, djohnson@certicom.ca, schneier@counterpane.com, denny@tis.com, denning@cs.cosc.georgetown.edu, omura@cylink.com, mhetzel@bell-labs.com, benaloh@microsoft.com, brickell@certco.com, smatyas@us.ibm.com, paulv@entrust.com, merkle@parc.xerox.com, berson@anagram.com, desmedt@uwm.edu, rivest@theory.lcs.mit.edu, carlisle.adams@entrust.com, ams@terisa.com, ekr@rtfm.com, Blake.greenlee@greenlee.com, cme@ACM.ORG, bfox@microsoft.com, acc@tycho.ncsc.mil, bschanni@BayNetworks.com, dickie@EMPIRE.eclipse.ncsc.mil, jhs@tycho.ncsc.mil, jis@mit.edu, pcain@bbn.com, kent@bbn.com, BSnow@radium.ncsc.mil, cjwagne@missi.ncsc.mil, balenson@tis.com, jlinn@securitydynamics.com, smid@csmes.ncsl.nist.gov, daw@cs.berkeley.edu
Message-ID: <85256720.0057DF83.00@domino2.certicom.com>
Date: Mon, 22 Feb 1999 11:07:32 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Mime-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-Disposition: inline
Sender: owner-ietf-smime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

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@spyrus.com> on 02/20/99 04:17:39 PM

To:   ietf-smime@imc.org
cc:   burt@RSA.COM, djohnson@certicom.ca, schneier@counterpane.com,
      denny@tis.com, denning@cs.cosc.georgetown.edu, omura@cylink.com,
      mhetzel@bell-labs.com, benaloh@microsoft.com, brickell@certco.com,
      smatyas@us.ibm.com, paulv@entrust.com, merkle@parc.xerox.com,
      berson@anagram.com, desmedt@uwm.edu, rivest@theory.lcs.mit.edu,
      carlisle.adams@entrust.com, ams@terisa.com, ekr@rtfm.com,
      Blake.greenlee@greenlee.com, cme@ACM.ORG, bfox@microsoft.com,
      acc@tycho.ncsc.mil, bschanni@BayNetworks.com,
      dickie@EMPIRE.eclipse.ncsc.mil, jhs@tycho.ncsc.mil, jis@mit.edu,
      pcain@bbn.com, kent@bbn.com, BSnow@radium.ncsc.mil,
      cjwagne@missi.ncsc.mil, balenson@tis.com, balenson@tis.com,
      jlinn@securitydynamics.com, smid@csmes.ncsl.nist.gov,
      daw@cs.berkeley.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.