On Jul 9, 2010, at 1:55 PM, Jonathan Katz wrote:
CTR mode seems a better choice here. Without getting too technical,
security of CTR mode holds as long as the IVs used are "fresh"
whereas security of CBC mode requires IVs to be random.
In either case, a problem with a short IV (no matter what you do) is
the possibility of IVs repeating. If you are picking 32-bit IVs at
random, you expect a repeat after only (roughly) 2^16 encryptions
(which is not very many).
CTR mode is dangerous unless you're also doing message authentication,
which will require an additional block or thereabouts - so if the goal
is to minimize bit overhead, it's not really appropriate here (unless
it's being included anyway).
The small number of encryptions before the IV repeats is the principle
problem I see. But there are a number of ways around it depending
on overall system details we don't have. Two examples:
- If each pair of communicating endpoints can keep state information,
you don't even have to send the IV: Agree once on a secret key, then
use CTR mode to generate an IV by encrypting the message sequence
number (which might or might not be included in the message itself).
- "Widen" the 32-bit IV you send with other information. If you
include the end-point ID's, then you only have to worry about possible
clashes between IV's generated for the same pair of endpoints, or even
for the pair in the same direction. (That's not *quite* true, but
it's close to true.) If the two ends can agree on the date and time
even roughly - say to the nearest minute - then you can mix that in as
well. Now you have to worry about a 50% chance of a clash if the same
pair starts up 2^16 connections within in a minute - probably not
likely enough to worry about.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
