Question w.r.t. AES-CBC IV

[Jerry Leichter]

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 majordomo at metzdowd.com