Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces"

["Dan Harkins" <[e-mail]>]

On Tue, July 19, 2011 8:32 am, Peter Gutmann wrote:
> David McGrew <[e-mail]> writes:
>
>>I wrote up a draft describing how deterministic IVs should be generated,
>> and
>>reviewing how they are used in different protocols:
>>
>>http://tools.ietf.org/html//draft-mcgrew-iv-gen-00
>
> From a quick read, it looks good, with comprehensive coverage of all the
> issues.  However (and you knew there was going to be a 'however' :-), it
> depends on who the target audience is.  I'm concerned that, as with advice
> on
> the correct use of RC4, the people who will be reading this (security
> people)
> will probably be the ones who don't need it, and those who need it
> (J.Random
> software developer) won't be reading it, or even know that it exists.  The
> problem is that CTR mode (and derived modes) don't work the way that
> (most)
> people think they do, and as 15-odd years of RC4 have shown, user
> education is
> unlikely to be effective in dealing with this.  Developers don't even
> understand how to use IVs, with all-zero IVs being frighteningly popular
> when
> they're forced to use a mode like CBC ("I kept getting the first 8/16
> bytes
> scrambled, but it's OK now, when you set the IV to zeroes everything
> works").
> In CBC mode it's..., well not good, but also not instantly fatal like it
> is in
> CTR mode and derived modes.
>
> If the goal is to "fix the IV problem" then I think that the solution
> isn't to
> try and change the users to match the encryption (RC4 has shown that that
> doesn't work so well), but to change the encryption to match the users'
> expectations.  So start by assuming that an all-zero IV will be used and
> design defensively around that.  What we'd then need, when the cipher is
> used
> by non-cryptographers (which is what virtually all programmers are) is CBC
> or
> CFB instead of CTR, and GCFBM or GCBCM instead of GCM.

  Let me remind everyone of SIV mode*. It's a CTR mode derivative but is
resistant to nonce misuse. Unlike CBC, the nonce doesn't need to be
unguessable. And it even provides a strong assurance of security if
the nonce is reused.

  One of the drawbacks of CBC (as opposed to SIV) is that it does not
do authenticated encryption and something like an HMAC-xxx is required.
Now if the real problem is, as you suggest, that J.Random Software
Developer won't be reading the literature he won't know whether he should
be doing authenticate-then-encrypt or encrypt-then-authenticate or even
encrypt-and-authenticate. With SIV it's all integrated. J.Random doesn't
need to worry about any of that. And he doesn't need to worry about
whether the nonce he's supplying is random, unguessable, or deterministic.

  regards,

  Dan.

[*] http://www.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf
[*] RFC 5297