I don't think we should be overly concerned about performance or code size.
We are primarily talking about user orientated clients where another x hundred
milliseconds is not going to be a significant problem and Microsoft seem to be
doing their best to ensure that we have oodles of RAM available if needed.
When one considers the ever increasing speed of processors, what is not
lightning fast now probably will be tomorrow and, perhaps more importantly, the
processors used to attack the messages encrypted today definitely will be much,
much faster in the future.
Our primary goal should be security, with ease of implementation next.
Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England
Tel +44-171-500-6473
Fax +44-171-500-8880
----Original Message-----
From: owner-ietf-smime(a)imc.org
Sent: Saturday, February 06, 1999 7:18 AM
To: BJUENEMAN(a)novell.com; ietf-smime(a)imc.org
Cc: pgut001(a)cs.aucKland.ac.nz
Subject: Re: A New Triple-DES Key Wrap Algorithm
djohnson(_at_)certicom(_dot_)com,
TACAR(_dot_)PRV-7(_dot_)PROVO(_at_)novell(_dot_)com, burt(_at_)RSA(_dot_)COM,
housley(_at_)spyrus(_dot_)com
The only [small] problem I have with your approach is performance, as double
encryption with triple-DES is relatively expensive, especially if you don't
save and reuse the state after the three key expansions step in DES. In
addition, I would like to have a key wrapper format that is completely
independent of the KEK algorithm, soi that I can use the same wrapper whether
I use DES, RSA, elliptic curves, etc. And I don't think you want to propose
doing double encryption with an asymmetric cipher!
I chose it because two passes of whatever cipher was being used seemed the
simplest way to do it. There are many alternative to this, my immediate
reaction when I saw the original analysis was to use the cipher to generate a
pseudorandom stream, hash 128-bit chunks of it with SHA-1, and then XOR the
20-byte blocks into the data to be encrypted, but it's a bit of an ad hoc
approach and requires many applications of SHA-1 which are probably less
efficient than the block cipher. In any case I doubt that a handful of extra
en/decryption operations for the two-pass crypt are going to add much
overhead. This is the same scheme suggested by Don Johnson, I wasn't sure
initially whether we were talking about the same thing.
Historical note: I first used something like this for a sector-level
encrypting disk device driver where there wasn't any room for storing the IV,
so the encryption made two passes, the first to generate the IV and the second
to perform the encryption. The first pass used:
P[ i ] ^= P[ i-K1 ] ^ P[ i-K2 ]
(K1 and K2 are appropriate constants), the second pass used the output as the
IV. This is a nice lightweight function (it's extremely efficient on a RISC
CPU), the design was by Colin Plumb and was inspired by the (then brand-new)
SHA. In the KEK case you don't need this since the data is so short that two
applications of the block cipher will carry virtually no overhead.
Peter.
<< File: UnXhrds.txt >>