More info in my AES128-CBC question

[Geoffrey Hird]

Leichter, Jerry wrote:

> Suppose we use AES128-CBC with a fixed IV.  It's clear that the only
> vulnerability of concern occurs when a key is reused.  OK, where do

No, remember that if the IV is in the clear, an attacker can
make some controlled bit changes in the first plaintext block.
(There has been no assumption of integrity enforcement.)

I wonder how Adam Perez is communicating the IV.

gh

> -----Original Message-----
> From: owner-cryptography at metzdowd.com 
> [mailto:owner-cryptography at metzdowd.com] On Behalf Of Leichter, Jerry
> Sent: Monday, April 23, 2007 11:41 AM
> To: cryptography at metzdowd.com
> Subject: Re: More info in my AES128-CBC question
> 
> Some of the messages in this stream have demonstrated why it can be
> difficult to get non-crypto people to listen to advice from crypto
> experts:  Cryptography research is, by its nature, a pretty absolute
> thing.  We find attacks, we try to eliminate them.  There's a strong
> tendency to view *any* attack as significant, so *any* use of a
> technique "known to be weak" is frowned on.
> 
> However, the issue isn't cryptography, it's security; and security
> is a cost/benefit tradeoff.  Some of the other messages in this
> thread have already made that point, by looking at some of the
> specific tradeoffs that have to be made (usability, efficiency,
> time to market, etc.)  However, in this particular case, one can
> even analyze the threat quite directly.
> 
> Suppose we use AES128-CBC with a fixed IV.  It's clear that the only
> vulnerability of concern occurs when a key is reused.  OK, where do
> the keys come from?  We're told that they are session keys.  Assuming
> that these are generated *correctly* - they are effectively random
> independent variables - then you'd need to see 2^64 sessions to get
> a 50% chance of a repeated key.  Note:  Note 2^64 *blocks* - something
> you might actually get in a reasonable amount of time on the fastest
> links - but 2^64 *sessions*.  Is that within the realm of interest
> for this protocol?  Maybe, maybe not.  (Most likely not.)
> 
> A decent protocol will have authentication and some kind of 
> anti-replay
> mechanism.  Even if someone gets hold of two sessions that used the
> same key, the authentication mechanism will block attempts to
> merge data from the two sessions.  Alternatively, any anti-replay
> mechanism will require carrying a nonce of some sort in the stream.
> Realistically, this will be sent very early in the session, pretty
> much ensuring that even with common keys and a common IV, there will
> be little common data.  In fact, a practical recommendation might be
> to put the nonce in the first block, in which case it ends up playing
> the role of an IV and the whole discussion disappears.
> 
> In summary:  Yes, ideally one uses a random IV.  In practice, 
> what this
> adds - in many common protocol styles - is robustness of a sort, not
> real additional security.  (However, actual robustness of 
> cryptosystems -
> robustness against all the common kinds of errors that people make in
> design, implementation, fielding, and use - doesn't appear to 
> be within
> reach of current techniques.)  If possible, it's certainly 
> better to use
> the best practices known - and random or nonce IV's are among those - 
> but getting defensive about how "no one is listening to the crypto
> experts" is not appropriate here.  Save that for the really egregious
> mistakes - of which there are plenty.
> 							-- Jerry
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com