Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces"
David McGrew <mcgrew@cisco.com> Fri, 19 August 2011 19:49 UTC
Return-Path: <mcgrew@cisco.com>
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 EE94921F8C0E for <cfrg@ietfa.amsl.com>; Fri, 19 Aug 2011 12:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.697
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOTgy3T3rZja for <cfrg@ietfa.amsl.com>; Fri, 19 Aug 2011 12:49:48 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 00E8221F8BD3 for <cfrg@irtf.org>; Fri, 19 Aug 2011 12:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; 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 mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 19 Aug 2011 19:50:41 +0000
Received: from stealth-10-32-254-212.cisco.com (stealth-10-32-254-212.cisco.com [10.32.254.212]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7JJodDF029882; Fri, 19 Aug 2011 19:50:40 GMT
Message-Id: <096AEDC1-26A4-4DCA-9579-7056B02320D3@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
In-Reply-To: <E1QjCHk-00012k-Aw@login01.fos.auckland.ac.nz>
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: <E1QjCHk-00012k-Aw@login01.fos.auckland.ac.nz>
X-Mailer: Apple Mail (2.936)
Cc: cfrg@irtf.org
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: 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 <mcgrew@cisco.com> 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
- [Cfrg] AES-GCM weakness Jérémie Crenne
- Re: [Cfrg] AES-GCM weakness David McGrew
- Re: [Cfrg] AES-GCM weakness Scott Fluhrer (sfluhrer)
- Re: [Cfrg] AES-GCM weakness Peter Gutmann
- [Cfrg] request for comments on "Generation of Det… David McGrew
- Re: [Cfrg] request for comments on "Generation of… Peter Gutmann
- Re: [Cfrg] request for comments on "Generation of… Dan Harkins
- Re: [Cfrg] request for comments on "Generation of… Peter Gutmann
- Re: [Cfrg] request for comments on "Generation of… Jim Schaad
- Re: [Cfrg] request for comments on "Generation of… David Jacobson
- Re: [Cfrg] request for comments on "Generation of… Dan Harkins
- [Cfrg] two-pass modes of operation David McGrew
- Re: [Cfrg] request for comments on "Generation of… David McGrew
- Re: [Cfrg] request for comments on "Generation of… Peter Gutmann