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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 21 August 2011 08:25 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 15B7621F899F for <cfrg@ietfa.amsl.com>; Sun, 21 Aug 2011 01:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.387
X-Spam-Level:
X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1]
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 0qfo8sTEf+8l for <cfrg@ietfa.amsl.com>; Sun, 21 Aug 2011 01:25:29 -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 E772D21F884C for <cfrg@irtf.org>; Sun, 21 Aug 2011 01:25:24 -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=1313915191; x=1345451191; 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:=20[Cfrg]=20request=20for=20comments=20on =20"Generation=20of=20Deterministic=20Initialization=20Ve ctors=20(IVs)=20and=20Nonces"|Cc:=20cfrg@irtf.org |In-Reply-To:=20<096AEDC1-26A4-4DCA-9579-7056B02320D3@cis co.com>|Message-Id:=20<E1Qv3MG-0005iR-6y@login01.fos.auck land.ac.nz>|Date:=20Sun,=2021=20Aug=202011=2020:26:16=20+ 1200; bh=yDaC/OzbdYp77zcsKqds0QSjfY8jy7GE3Y1pLMEFVEg=; b=Q2aL3sMk3a9fQ1DmxO6BGM40KkvK8Y5Z9/xNUIPVHuuw3Gffl6o8lZes LviCGE74GcvT9aSibveJ7AV6Gy7UXplI06dUgVLppv3KQXgTu9Ocd/er6 F5aur3tHsZFR1Q7wBDg+YGDjOdi9vKQvAkFOtubOBZ7vnhq8Z75FKnJwU Q=;
X-IronPort-AV: E=Sophos;i="4.68,258,1312113600"; d="scan'208";a="79342389"
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; 21 Aug 2011 20:26:17 +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 1Qv3MG-00010z-Gw; Sun, 21 Aug 2011 20:26:16 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Qv3MG-0005iR-6y; Sun, 21 Aug 2011 20:26:16 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: mcgrew@cisco.com, pgut001@cs.auckland.ac.nz
In-Reply-To: <096AEDC1-26A4-4DCA-9579-7056B02320D3@cisco.com>
Message-Id: <E1Qv3MG-0005iR-6y@login01.fos.auckland.ac.nz>
Date: Sun, 21 Aug 2011 20:26:16 +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: Sun, 21 Aug 2011 08:25:30 -0000

David McGrew <mcgrew@cisco.com>; writes:

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

Hmm, I can't see how trying to address things at the API level could work
because there's already a large variety of very different APIs, many dating
back 10-15 years, that would need to be changed.  I can't imagine how you'd
convince Microsoft, OpenSSL, BSAFE, whoever owns Java this week, and a bunch
of others, all to switch to, or introduce, a new unified AEAD encryption API.

All you'd really need to do is define is a single, standard way of applying
AES-GCM (or whatever), and then various vendors could then adapt it for
whatever their API looks like.

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

See above, even if you/I/we come up with an API, I can't imagine what it'd
take for vendors to adopt it.  Look at things like the MD4 and MD5 RFCs (to
take something that's been around since the dark ages of Internet cryto),
apart from a very very low-level part of the OpenSSL API I've never seen
anything that uses it, and that was introduced at more or less the year zero
of hashing APIs (it predates SSLeay, CryptoAPI, Java, and others), but still
didn't get adopted.

So I think the way forward is to define a single unambiguous way of applying
GCM, and leave it to individual API developers to provide the interface to it.
Even then, unfortunately, for most of the major protocols (IKE, ESP, TLS, etc)
it's already too late, they've already defined their own incompatible
mechanisms.

Peter.