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.
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? Would the IV
for the second encryption be the ciphertext of the last block from the
first encryption pass? If so, it needs to be carried somewhere. Is
disclosure an issue? Alternatively, can a differnt constant IV be used for
the second pass?
Thanks for the speedy review,
Russ