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

Reply via email to