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

David McGrew <> Fri, 19 August 2011 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE94921F8C0E for <>; Fri, 19 Aug 2011 12:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.697
X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DOTgy3T3rZja for <>; Fri, 19 Aug 2011 12:49:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 00E8221F8BD3 for <>; Fri, 19 Aug 2011 12:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4511; q=dns/txt; s=iport; t=1313783445; x=1314993045; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=VO8LoSN5mgdoRIAUodz1jPQxAJ3DWN3+mrpnhOdNeo8=; b=ObhtZ2DWSVdxGyryZEuQK1nQPEZm/DERajmxumuJmW6zOoG/HojGZUEb MtK68AIvZhuk4AuiIU7e9bfsvU7eGlBPY49fPCAT2Qk0ZmHuJ51WucOpE Ou+KBC9RDh35+gTJ6Ss6cHkP8Wjvg2uZdoHPsOPPrtJ9p0iEAJ+zkDosw w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAAO+Tk6rRDoH/2dsb2JhbABBDqd/d4FAAQEBAQIBEgElAjEOBQsLDjhXBhMWBQeHTwSaCwGedYVpXwSHYIszkD1Y
X-IronPort-AV: E=Sophos;i="4.68,252,1312156800"; d="scan'208";a="14799942"
Received: from ([]) by with ESMTP; 19 Aug 2011 19:50:41 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p7JJodDF029882; Fri, 19 Aug 2011 19:50:40 GMT
Message-Id: <>
From: David McGrew <>
To: Peter Gutmann <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 19 Aug 2011 12:50:39 -0700
References: <>
X-Mailer: Apple Mail (2.936)
Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Aug 2011 19:49:49 -0000

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 <> writes:
>> I wrote up a draft describing how deterministic IVs should be  
>> generated, and
>> reviewing how they are used in different protocols:
> 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  

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