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

David Jacobson <dmjacobson@sbcglobal.net> Wed, 20 July 2011 17:45 UTC

Return-Path: <dmjacobson@sbcglobal.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1628521F8ACC for <cfrg@ietfa.amsl.com>; Wed, 20 Jul 2011 10:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRGPzJ0uvs2E for <cfrg@ietfa.amsl.com>; Wed, 20 Jul 2011 10:45:00 -0700 (PDT)
Received: from nm15.access.bullet.mail.mud.yahoo.com (nm15.access.bullet.mail.mud.yahoo.com [66.94.237.216]) by ietfa.amsl.com (Postfix) with SMTP id 3428721F8576 for <cfrg@irtf.org>; Wed, 20 Jul 2011 10:45:00 -0700 (PDT)
Received: from [66.94.237.198] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Jul 2011 17:44:56 -0000
Received: from [66.94.237.100] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Jul 2011 17:44:56 -0000
Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 20 Jul 2011 17:44:56 -0000
X-Yahoo-Newman-Id: 329523.10112.bm@omp1005.access.mail.mud.yahoo.com
Received: (qmail 49121 invoked from network); 20 Jul 2011 17:44:55 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ps9AGy9p4Duse21SsWcXKKIllHaRsqpzXObkLG/ZOoSSDcm5ec37SqN61Z9VtNAKbUpycuWEnn9jx6DzcOdhhtewOrqsLjrBNHM+IH2mnqe+c5PPHrja/AI/EiIwf6s+btiyV9afscxQh9Gx4/TO8cgafqC9zHWHAkCXJh2EVc4= ;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1311183895; bh=+9E42iUwWl2wACTnand+XDi9opCT2zD5Ix2rPRJKIdY=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=1O55W66YBgfRs2/0WZWrJ+7Kxl7zlsVylV6knMQQq4UmqRjCY2MvuUqW3ivx/TsiDtpZt08jP1oaMO8Mv4H8xn1ibiWGKQfG2C3Qmowkjp0ShbScolAHlSfFKzlN2nLMYDinpkLeZe6wFafUUTiz+ptY3JzeJ0hBS5Nldx5m4ro=
Received: from [192.168.1.66] (dmjacobson@99.120.98.171 with plain) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 20 Jul 2011 10:44:55 -0700 PDT
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
X-YMail-OSG: dLqHiLEVM1mfcV8lzfjL_eQTt1XNXaEB5B7uDsjyyJAS.4g uAQnFi3BeRq3Y150C.as4fJDYueJy397dgan.1rM11dm2f0jp7im4_bOTSDq n_VRJrTtIEwGnbJ0FUktbKl8kkXP53QscethMYKd3noTbPz.4xD27fZozY45 haJZI_SbSbBM3wrJRju7hC75xUHAT0S0L8OFbsX8vOAH5vuvQC48lIUJLWwA 0W6HMDoebNUGiWXE5Q6eHISfE13lw4_W8QkZs8YF8Yq2Wq9y2EupPgebcEIu Y3TGdVp4UC7EWWPRcoVDyZIe7LOSyZtPih22OcNTg0B9_gTpaCPiKm35nXr3 uRmWvM4h48lp.joFSXsJfaCY1S_RGj1APdzEXOerJKhI3JtNcsGixz7XYlSa KSMlUmYug_NOor82nwLjxPKA5ygWj.s8CCfIUmDtnRq0MmizQ11tnI4Nheew .ftXA_p4yir.doatbN52GctwWUwNt0Q--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4E271418.3010404@sbcglobal.net>
Date: Wed, 20 Jul 2011 10:44:56 -0700
From: David Jacobson <dmjacobson@sbcglobal.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: cfrg@irtf.org
References: <E1Qj2Ry-0002yg-CU@login01.fos.auckland.ac.nz> <B7C89736-F423-4C1C-B020-C642F117C596@cisco.com>
In-Reply-To: <B7C89736-F423-4C1C-B020-C642F117C596@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces"
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2011 17:45:04 -0000

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?= <jeremie.crenne@univ-ubs.fr> 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
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> 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
>
>