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

[David Jacobson <[e-mail]>]

I looked at David McGrew's IV draft.  Here are some comments.

Section 5 is about implementation.  The scope is limited to 
deterministic IVs.  One of the premises is that IV generation is a 
crypto operation that needs skill and care to be correct, and should not 
be left to application developers.  Two methods are indicated:  generate 
the IV in the crypto module, and (for backward compatibility) the 
application generates the IV, but the crypto module verifies that the 
supplied IVs satisfy the requirements.  I'll address only the case of 
generating IVs in the crypto module.

If IVs are generated without a source of random numbers, then there must 
be non-volatile memory if keys last across reboots or power cycles.  Yet 
most designers of crypto modules want to stay away from as much system 
dependency as possible.   In addition, many systems do not have reliable 
non-volatile memory with sufficiently fine grain.  Suppose the system 
has just booted.  It reads the counter from a file in the file system, 
increments it, writes it back, and then encrypts and transmits the first 
message using the new counter to derive the IV.  Then power is lost or 
the system crashes.  If the writes are buffered, the new counter value 
may not have made it to the storage medium.  This illustrates that an 
entanglement between crypto and systems issues is difficult to avoid, 
and just putting the IV generation in the crypto module does not 
guarantee that everything is right.   In addition, if the crypto module 
uses the file system to store the counter, then the crypto module must 
have code to access the file system (system dependent) and there must be 
a pre-agreed file name (more system dependency), or it must be some sort 
of parameter.  In any case the file name has to be managed correctly so 
the file is not shared between different subsystems with their own 
encryption.

One minor comment is that the proposed scheme shows the IV going back to 
the application.  It is not obvious why the application needs to know 
the IV.

Finally, the draft is limited to deterministic IVs.  It might be good to 
address both deterministic and random IVs in the same document.  Since 
random numbers are already needed for crypto, there should a facility 
inside the crypto module for getting them, and using it for IV 
generation would add almost no complexity.  Addressing random IVs would 
allow you to educate the readers about the need to limit the number of 
messages to avoid collisions due to the birthday bound.

   --David Jacobson


On 7/19/2011 6:22 AM, David McGrew wrote:
> Hi Peter,
>
> your note seems like a good introduction for this topic.  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
>
> Comments welcome.  You have a lot of experience with the 
> implementation of robust crypto software, so if you have additions or 
> improvements to Section 5 that would be great.
>
> Side note: I was somewhat surprised that I was able to write a 24 page 
> document on a topic as narrow as IV generation, and your reminder to 
> everyone of how important a topic it is makes me feel a bit better :-)
>
> David
>
> On Jul 18, 2011, at 10:02 PM, Peter Gutmann wrote:
>
>> =?iso-8859-1?Q?J=E9r=E9mie_Crenne?= <[e-mail]> writes:
>>
>>> What is the feeling of the community about the recent potential AES-GCM
>>> weakness due to weak keys ?
>>
>> GCM's problem isn't the weak keys in AES-GCM, it's that it's a KSG 
>> rather than
>> a standard block cipher.  It's RC4 all over again, and we're going to 
>> see the
>> same problems with GCM that we've already seen with RC4.  There have 
>> been
>> several already, and the only reason why we haven't seen more is that 
>> GCM
>> isn't used that much (that is, it's used in a small number of 
>> widely-deployed
>> applications, but hasn't become the universal algorithm of choice 
>> that RC4
>> was.  Once, or if, it does, we'll see exactly the same problems that 
>> plagued
>> RC4 throughout its effective lifetime).
>>
>> Peter.
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3773 - Release Date: 07/18/11
>
>