[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IV treatment in esp-des-md5-01.txt
Hi John,
I pulled down a copy of your "draft-ietf-ipsec-esp-des-md5-01.txt".
I wanted to pass on a comment concerning the way which in you use the IV.
It seems to be almost a tradition, but it is NOT correct in DES CBC encryption
to use an adversarially-predictable IV (when the IV is used in the usual way).
Nor is it correct if any two IVs differ by an adversarially-predictable amount.
As a simple illustration, suppose the IV is a counter, initially 0. Then the
length-2 sequence of encrypted messages whose plaintext blocks are
0, 0
is easy to differentiate from the length-2 sequence of encrypted messages
whose plaintext blocks are
0, 1
(here 0 and 1 representing integers 0 and 1 encoded into 64 bits).
Assume the adversary has a. priori. knowledge that the sequence of plaintexts
will be one of the above. Then no "good" encryption scheme should be leaking
which one; a "good" encryption scheme leaks only the length of each plaintext,
even when the adversary has partial information about some of the plaintexts.
A clean way to get around this is to define DES-CBC_{k,IV}(x_1 ... x_n) by
y_i = DES_k(y_{i-1} xor x_i)
where
y_0 = DES_k(IV) // instead of y_0 = IV
This would make a counter (or any other nonce) fine for an IV, releasing the
burden on the user to construct a good-enough IV. It would also make 32 bits
adequate for the IV. Under this change I don't know of a cryptographic justification
in support of having both the long and short IVs of esp-DES-IV32 and esp-DES-IV64.
Also, you could simply consider the replay prevention field as the IV in esp-DES-HMAC-RP.
As it currently stands, you'd need to demand that the IV in esp-DES-IV32 and esp-DES-IV64
meet a property which is extremely hard to explain to the user of this document; and in
esp-DES-HMAC-RP it looks like the IP isn't going to be right no matter what.
Kind regards,
Phil Rogaway