[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IVs
Phil Karn says:
> How about if we just use the outer (plaintext) IP ID field as a
> confounder/IV? After all, it's free, and when combined with the source
> IP address it's intended to make each packet relatively unique.
> I know it's only 16 bits, but that still gives us 65536 unique packet
> IVs. Simply rekeying (e.g., creating new SAIDs) more often than that
> will take care of the rest.
It will do quite nicely; as I've explained to more people than I can count
(it might be impolite to mention names, but some of their addresses are
pgut1@cs.aukuni.ac.nz and prz@acm.org) there is absolutely no requirement
for IVs to be secret; it is sufficient that they be different for each packet.
In CBC mode, it also helps if they are uncorrelated with the first block
of plaintext, because otherwise you might find that IV1 ^ x1[0] == IV2 ^ x2[0],
so y1[0] = crypt(IV1 ^ x1[0], Key) == y2[0] = crypt(IV2 ^ x2[0], Key).
You can observe that the ciphertext y1[0] == y2[0], and since you know the
IVs, you can conclude things about x1[0] and x2[0].
One technique that I came up with and works well is used in Peter Gutmann's
SFS. It requires that the message be at least two cipher blocks long.
Basically, you do two encryption passes, and use the last block of the
first pass as the IV for the second pass. On decryption, you have to
decrypt the tail (not including the first block, but including the
last block; the exact division is irrelevant) of the message to find
the IV needed to decrypt the head.
Now, before you say that this makes things twice as slow, the first pass
can be a very trivial cipher, as long as it has good cascade properties.
I use a scrambler polynomial.
In fact, you can just take any checksum of all but the last block of the
message and combine it using some invertible operation with the last
block. Use that as the IV, and after undoing the outer encryption,
recompute the checksum and undo the combination. In the case of a
scrambler polynomial, the combining operation is XOR, but you can add,
multiply in a Galois field, encrypt with the checksum as a key, or
whatever you like.
As long as the data is not deliberately constructed to defeat the inner
checksum computation, the IV is nicely random. If the data is
so constructed, you can get a chosen IV, leading to a chosen plaintext
attack, but so what? If you can construct such data, you have a
chosen plaintext attack anyway.
The two-pass nature of this is a problem for some applications, but it
does not appreciably slow down encryption and it generates a unique IV
per (distinct) packet without extra overhead.
Anyway, it's something to think about.
(Sorry I haven't been participating; I've been swamped with work. I'm going
through about a zillion messages I haven't read for two weeks.)
--
-Colin