More info in my AES128-CBC question

Nicolas Williams Nicolas.Williams at sun.com
Tue Apr 24 19:18:43 EDT 2007


On Mon, Apr 23, 2007 at 11:23:54AM -0700, Aram Perez wrote:
> On Apr 23, 2007, at 8:11 AM, Nicolas Williams wrote:
> >On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
> >>No, there will be message integrity. For those of you asking, here's
> >>a high level overview of the protocol is as follows:
> >
> >>[...]
> >
> >>3) Data needing confidentiality is encrypted with the SK in the mode
> >>selected in step 1. The message is integrity protected with MK. A new
> >>MK is generated after a message is sent using MK(i+1) = H[MK(i)]
> >
> >You don't necessarily have to change the integrity protection key for
> >every message.  One thing this says is that the protocol involves an
> >ordered stream of messages.
> 
> You need to change the integrity key if you want to prevent replay  
> attacks.

Or construct your MAC so that there is a sequence number in it.

E.g., SSHv2 uses HMAC without changing the integrity key.

If deriving a new key is slower than adding a sequence number into the
input of HMAC (which it most likely is) then you're likely to prefer the
latter.

If there isn't a good reason for rejecting what I suggest then one might
worry that changing the integrity key on every message (but not the
confidentiality key?) is something that a non-expert might do and that
there may be other problems with this protocol.  Much experience has
been gained with other protocols in these areas; do leverage it.

> >But be careful.  Simply chaining the IV from message to message will
> >create problems (see SSH).
> 
> The intention would be a new IV with each message begin sent.

As long as it doesn't repeat.  Also, if it's not random then make that
IV the first block of plaintext (with a fixed IV) -- that is, use a
confounder, and make sure it doesn't repeat.

> >What is the concern with using random IVs/confounders anyways?  The
> >need for an entropy source?  If so keep in mind that a PRNG will be
> >sufficient for generating the IVs/confounders and that you'll
> >generally need some source of entropy for at least some protocol
> >elements (e.g., nonces).
> 
> The concern was that "that's the way SD cards do it today". Another  
> response was "you haven't heard of anyone breaking SD cards have you?"

Fallacious responses, those.

A legitimate response w.r.t. confounders might be "but that wastes a
cipher block's worth of bits on the wire," which it certainly does, and
if you're really hard pressed for bandwidth and use mostly small
messages then you'd mind the confounder.  But I see no reason not to use
a random or pseudo-random IV -- a device that can do crypto can and
should have a decent PRNG (and a true, if low-bandwidth RNG to seed it).

Nico
-- 

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



More information about the cryptography mailing list