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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 19 July 2011 15:36 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
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 77E7921F8572 for <cfrg@ietfa.amsl.com>; Tue, 19 Jul 2011 08:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.646
X-Spam-Level:
X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 SMM0hcuXyZxD for <cfrg@ietfa.amsl.com>; Tue, 19 Jul 2011 08:36:30 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7759521F86A2 for <cfrg@irtf.org>; Tue, 19 Jul 2011 08:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311089583; x=1342625583; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20mcgrew@cisco.com,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20request=20for=20comments=20on=20"Genera tion=20of=20Deterministic=20Initialization=20Vectors=20(I Vs)=20and=20Nonces"|Cc:=20cfrg@irtf.org,=20jeremie.crenne @univ-ubs.fr|In-Reply-To:=20<B7C89736-F423-4C1C-B020-C642 F117C596@cisco.com>|Message-Id:=20<E1QjCHk-00012k-Aw@logi n01.fos.auckland.ac.nz>|Date:=20Wed,=2020=20Jul=202011=20 03:32:36=20+1200; bh=xgQli8OTpwXEgUJ8oboRApIEhZ9StQFNWqYjEg1BFOw=; b=Jfq5P4IyvXJfAxzmc7RwXt1ETazy/M2lKwVBCwVzI7tM6OBiFjjMS7II aMO85+XmmY8SluGD0sWc1rNFgKAI2iG1CjEdPETsNY1n6wphOWLiNecvw jSqbDEhRnm0sYDHvICjRS57G18HSFSGApf4Fu11XEUAsQEsUb1xUMbyt+ o=;
X-IronPort-AV: E=Sophos;i="4.67,228,1309694400"; d="scan'208";a="72566541"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Jul 2011 03:32:37 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QjCHk-0004bY-HL; Wed, 20 Jul 2011 03:32:36 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QjCHk-00012k-Aw; Wed, 20 Jul 2011 03:32:36 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: mcgrew@cisco.com, pgut001@cs.auckland.ac.nz
In-Reply-To: <B7C89736-F423-4C1C-B020-C642F117C596@cisco.com>
Message-Id: <E1QjCHk-00012k-Aw@login01.fos.auckland.ac.nz>
Date: Wed, 20 Jul 2011 03:32:36 +1200
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: Tue, 19 Jul 2011 15:36:34 -0000

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.  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.