Re: [Crypto-panel] Review of AES-GCM-SIV

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Mon, 19 June 2017 14:05 UTC

Return-Path: <sfluhrer@cisco.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101FE1314A8 for <crypto-panel@ietfa.amsl.com>; Mon, 19 Jun 2017 07:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj2PqXQ0GiD5 for <crypto-panel@ietfa.amsl.com>; Mon, 19 Jun 2017 07:05:52 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE6B1314AD for <crypto-panel@irtf.org>; Mon, 19 Jun 2017 07:05:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2870; q=dns/txt; s=iport; t=1497881152; x=1499090752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MAOHdc0NdfR/e3VgNfOlatlJmvhhTly2lZutKOXDZ/U=; b=Z4mzKg+X94j9ET79vl/Ohb7oC0DwUHhsMr3V8Ke/yPzQET0D0Kav38JM 1ivN+RypFTBvWxrHiGl9D34p4Xt9Xnf90GkQVeUFGuj28DZcHqmPsFxxL VAX1a/b+TkxZiOQU5YkPaB7Mvh70dtEsz1mTBsdbm54Xb7oTw73qGLqLo M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQCe2UdZ/5ldJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNYYoENB593lXeCESELhS5KAoJPQRYBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMBATg0CwwEAgEIEQQBAQEeCQcnCxQJCAIEAQ0FCIokEK93i2EBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZjgWCCFoEMhHCFbAWeXgKHLowmghGJNYZQlQgBJgI?= =?us-ascii?q?vgQp0FUmFCgMcgSc/dohUgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.39,361,1493683200"; d="scan'208";a="263314638"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 14:05:51 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5JE5oER017138 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2017 14:05:51 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Jun 2017 10:05:50 -0400
Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 19 Jun 2017 10:05:50 -0400
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, "crypto-panel@irtf.org" <crypto-panel@irtf.org>
CC: "alexey.melnikov@isode.com" <alexey.melnikov@isode.com>
Thread-Topic: Review of AES-GCM-SIV
Thread-Index: AQHS5eUMXPqksT4BkEOlrKXEsk18RKImD/sAgAYnq/A=
Date: Mon, 19 Jun 2017 14:05:50 +0000
Message-ID: <c1299ee52c524040ac0b2d2041eeb759@XCH-RTP-006.cisco.com>
References: <D5685A61.9675F%kenny.paterson@rhul.ac.uk> <D5685B25.96765%kenny.paterson@rhul.ac.uk>
In-Reply-To: <D5685B25.96765%kenny.paterson@rhul.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.2.54]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/KvDIlEP38ITA_VbS1J_uP2I2Dbo>
Subject: Re: [Crypto-panel] Review of AES-GCM-SIV
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jun 2017 14:05:56 -0000

My review:

Summary: Almost Ready

Major Concerns:

None - from a security perspective, it looks pretty good


Minor Concern:

One thing that may be problematic to an implementor was the nonces listed in the test vectors.  AES-GCM-SIV takes 12 byte nonces, the nonces listed are 16 bytes long.  While this is unlikely to be a major source of confusion for an implementator, I suggest that the nonces be trimmed down before publishing.


Nits:

The encryption/decryption algorithms are given using fairly terse English descriptions.  While they are moderately clear to me, I wonder if they'd be as clear to someone else; I'm wondering if a pseudocode description would work better?  On the other hand, the test vectors give intermediate cipherstates (which would help a lot).

While the test vectors are quite good in general, they use only one nonce, and two keys (one for each key length).  While there is certainly value in reusing the same key and nonce for slightly different plaintexts/AADs, I believe there would also be value in showing how different keys/nonces work.  One example: at one point,  AES-GCM-SIV xor's in the nonce into the POLYVAL result.  If someone did an incorrect implementation where (say) they exclusive-or'ed only the first 4 or 8 bytes of the nonce, the current test vectors would still pass.

The bytes in the test vector are listed LSB to MSB.  This rather assumes that the implementor is using little-endian byte ordering; I would suggest that this be changed to a more endian-neutral notation (possibly by just omitted the LSB and MSB labels).



> -----Original Message-----
> From: Crypto-panel [mailto:crypto-panel-bounces@irtf.org] On Behalf Of
> Paterson, Kenny
> Sent: Thursday, June 15, 2017 10:43 AM
> To: Paterson, Kenny; crypto-panel@irtf.org
> Cc: alexey.melnikov@isode.com
> Subject: Re: [Crypto-panel] Review of AES-GCM-SIV
> 
> Sorry, that should be
> https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-05 (and not -04).
> 
> On 15/06/2017 15:38, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
> wrote:
> 
> >Dear CFRG panel members,
> >
> >Any volunteers from the panel to perform a review of:
> >
> >https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-04
> >
> >
> >I'd like to move it towards last call, and having a couple of reviews
> >from you fine people would help give us the confidence to do so.
> >
> >The draft might be best read in conjunction with the technical paper:
> >
> >https://eprint.iacr.org/2017/168
> >
> >
> >though of course it needs to stand alone as an RFC.
> >
> >Let me know.
> >
> >Cheers,
> >
> >Kenny
> >
> 
> _______________________________________________
> Crypto-panel mailing list
> Crypto-panel@irtf.org
> https://www.irtf.org/mailman/listinfo/crypto-panel