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

[David McGrew <[e-mail]>]

Hi Peter,

thanks for your comments - I am returning to them to pick up on one of  
the side topics:

On Jul 19, 2011, at 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.
>
> Getting back to the draft, it'd be nice to recommend some single  
> standard way
> of dealing with IVs (with an accompanying "AND STICK WITH IT!").   
> Did you
> notice, in Table 1, that every single protocol that uses them has  
> invented
> their own incompatible way of handling them?  Ugh.

Right.  Even ones that follow RFC 5116 recommendations do it  
differently :-)

> You can't even provide a
> standard implementation ("encrypt this message with AES-GCM")  
> because each
> protocol has its own incompatible way of applying it.  This also  
> means that,
> for section 6, you're going to need test vectors not to exercise AES- 
> GCM but
> to exercise AES-GCM as used in ESP, AES-GCM as used in IKE, AES-GCM  
> as used in
> TLS, AES- GCM as used in ...
>
> Peter.
>

Like you suggest, it would be valuable to define a user-oriented API  
for encryption, which hides all of the crypto details from the user  
and thus minimizes the demands that it places on their knowledge.  I  
would like to see an AEAD API developed that keeps the IV-management  
complexity away from the user, and I think that it would not be hard  
to write a new interface that builds on top of RFC 5116, perhaps cites  
the iv-generation draft as well.

Most protocols that use crypto have a packet format that includes an  
IV, a ciphertext, and a separate authentication tag.   That is, the  
protocol is aware of the crypto data types, and thus needs to be aware  
of the cryptography.  With RFC 5116, we got rid of the separate  
authentication tag.  What would really be good would be to put the IV  
into the crypto-data as well, so that the interface between the  
protocol and the crypto engine is as simple as possible.  This  
interface would meet your goal of keeping the non-crypto-expert  
developer insulated from the IV-details, and changing the encryption  
to meet the expectations of the user.   The challenging part of this  
exercise will be in getting compatibility with existing protocols,  
like TLS and ESP.  Perhaps a more modest goal would be to have the  
"user-proof" API have an IV as an ouput of the crypto algorithm,  
instead of an input.  It might be easier to get that to be backwards  
compatible.

What do you think?  Any chance that I can talk you into contributing,  
or at least reviewing, a draft defining an API like this?

David