Russ,
My comments imbedded in your note and prefixed with an *.
Don J.
Russ Housley <housley(_at_)spyrus(_dot_)com> on 02/01/99 02:48:01 PM
To: Don Johnson/Certicom
cc: ietf-smime(_at_)imc(_dot_)org, 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,
mjmarkowitz(_at_)attmail(_dot_)com,
smatyas(_at_)vnet(_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, 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,
jlinn(_at_)securitydynamics(_dot_)com,
smid(_at_)csmes(_dot_)ncsl(_dot_)nist(_dot_)gov
Subject: Re: A New Triple-DES Key Wrap Algorithm
Don:
1. An integrity value of 16 bits is not enough to thwart a determined
attacker, especially if using a integrity verification oracle, that is,
toss values at it until success.
A slight restructuring could lead to 32 bits. This would eliminate the
Length value and the Pad octet. Any additional would lead to an additional
block. This is already six blocks to protect three blocks of data.
* I like the length field, it allows for future flexibility if needed and
is a simple way to strengthen an integrity check. It is best if the length
field is in a fixed location, that way there is no ambiguity, which as we
know is bad for security.
2. Given that TDES CBC is being done for messages, why not do two-pass
TDES
CBC for the key wrapping (that is, do CBC over the key block and then do
it
again)? This avoids the need for code for a formatting method. This
forms
a block where every bit is dependent on every other bit. A triple-DES key
is 168 bits of key; with parity bits, it is 192 bits. Given a block of
384, this gives 192 bits for other stuff. Put in some random bits, put in
a longer checksum, put in a length of the block, put in other stuff,
depending on what attributes are desired. The TDES blocksize being
64-bits, text attacks are not relevant as 2**32 blocks of key data will
not
get encrypted under one set of TDES keys, and as it is random-appearing
data, is the best thing to encrypt anyway.
Are you saying that the original formatting with double encryption would be
a cheaper way to resolve the problems raised by Burt kaliski?
* I think so or something like that. I think it would be cheaper in code
size as TDES CBC already needs to exist in the code.
Would the IV
for the second encryption be the ciphertext of the last block from the
first encryption pass?
* Yes.
If so, it needs to be carried somewhere.
* No, it does not, if a 64-bit random number is put first in the block,
this is due to self syncronizing property of CBC mode. Alternately, the
first block could be seen at a random IV.
Is disclosure an issue?
* Not sure what you mean by this. Please explain more. Disclosure of the
IV? Disclosure of the text or key? What?
Alternatively, can a differnt constant IV be used for
the second pass?
* If you use an IV of 0, the first block is damaged, if you do not care as
it is random, then you do not care.
Thanks for the speedy review,
Russ