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.