[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Size of IV field in DES-CBC mode
> I think that Jim is refering to the Birthday Paradox, so given an evenly
> distributed population of 2**32, the probability that a match will be found
> exceeds 50% with a sample of sqrt(2**32) = 2**16. If we assume randomly
> distributed IVs, then the expected sample should go to 1/2*(2**32)=2**31.
> Furthermore if we are talking about CBC, a one-up counter works just as well
> as a random value (the only property of interest is change, not magnitude of
> change) and we can use all 32 bits. (Again this is for CBC, other modes have
> other concerns.)
A counter works better for CFB than CBC. Consider: if x[] are the plaintext
blocks and y[] are the ciphertext blocks, then y[0] = CRYPT(x[0] ^ IV).
We want to be reasonably sure that the y[0]'s always differ, which means making
sure that the x[0] ^ IV pattern always differs. Since the x[0] pattern is
difficult to predicy (although maybe some things can be said about it),
you have to get your variation from the IV. If the IV follows a simple
pattern, and the x[0] happens to follow a parallel pattern, you can get
"cancellation" of the changes and all of a sudden you have, for two messages
M and M', y[0] == y'[0] so x[0] ^ x'[0] == IV ^ IV'.
Can you make guarantees about the contents of x[0]? If it is random, or the
bits which overlap the variable part of the IV don't change, then things
work well. But if it is correlated with the IV, things are bad.
That's why I suggested expanding a sequence number with a CRC-32: it's a cheap
and well-understood bit-mixing function which is unlikely to occur in the
header by accident.
(An alternative is to incerment the IV by an odd number which is *not* 1.)
> reduce the amount of bit shuffling if we put the SAID directly before the IV
> (with no intervening bits).
If you specify a source of bits to use to extend the IV, then the IV size can
be easily varied by negotiation.
--
-Colin