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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 05 July 2017 07:36 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 95066131A98 for <crypto-panel@ietfa.amsl.com>; Wed, 5 Jul 2017 00:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 lOBxxD_XjPPY for <crypto-panel@ietfa.amsl.com>; Wed, 5 Jul 2017 00:36:38 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20071.outbound.protection.outlook.com [40.107.2.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003B7131A86 for <crypto-panel@irtf.org>; Wed, 5 Jul 2017 00:36:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2oEI1civ4QojApz7RuF29x2scgnl8DFWA1YksS18Oco=; b=oHgu8309MAgR7ZhR0mZb2ktsDX/f0WXBO83NB/z8C4ayeHALSsXV3vmfM6PJMrWpsiYNSoilxOzVxs16cmKKBgo+PLo5HqBoLm3a+zMfsams+vN9/2kckK14THgFNprokaXpkUp7i27iTDHWgYuEhmza1F2yREg/h4zGO/Q5qwQ=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Wed, 5 Jul 2017 07:36:35 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1220.018; Wed, 5 Jul 2017 07:36:34 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Bjoern Tackmann <bjoern.tackmann@ieee.org>
CC: "crypto-panel@irtf.org" <crypto-panel@irtf.org>
Thread-Topic: [Crypto-panel] Review of AES-GCM-SIV
Thread-Index: AQHS5eUMXPqksT4BkEOlrKXEsk18RKI/ZZ4AgAEupACAAyHcAIAAKM+AgAACKACAASZaAA==
Date: Wed, 5 Jul 2017 07:36:34 +0000
Message-ID: <D5825533.98003%kenny.paterson@rhul.ac.uk>
References: <D5685A61.9675F%kenny.paterson@rhul.ac.uk> <CAFr4q=D8tm362WTQdZ97U93eavOafYwyLOFWTD2jK8YR2B+X-w@mail.gmail.com> <ab2e806f-e9aa-9bb5-2a12-f55f4a005fe8@upb.de> <CAFr4q=CA4OhcYA8u6VVb4Hx3+_AN9VeWZN30HOPO-jgvadt4RQ@mail.gmail.com> <D5815C4F.97F0D%kenny.paterson@rhul.ac.uk> <CAFr4q=DF3GFwRzU-2t8WypNxno10odm++1n5EenVVNuhA=7E5A@mail.gmail.com>
In-Reply-To: <CAFr4q=DF3GFwRzU-2t8WypNxno10odm++1n5EenVVNuhA=7E5A@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: ieee.org; dkim=none (message not signed) header.d=none;ieee.org; dmarc=none action=none header.from=rhul.ac.uk;
x-originating-ip: [134.219.227.30]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:baDVsy7fl32pbsvgHrlZCOs38FiW+IdEY7BVcoXbHanGjvK9/v9YqoKxLrYfjSaWj52qh9zCcNL4NSwTl9hJzSrKzefM3R6ycqwWDheEhbHbG2mAnlLLqnLdxGPuaz0jaWnrWVNhiMzNiK32OXS4UwyHkVERlysKjpZ7A9EfCUuJgWfucItxOXfRz+rRM5ulvsc6BE7qIeDBSZArsuyB32L23FMj87PDiOcHM72LeFQZtzynTuTWrm+8jH4drK44nsjnQnGRO38yu1EHTAoe/yCjdU9+g12UI/l0egoiOiURXkClsO/NWoqEAJsn4ONlBnBHzPk/zmiKCO3O+GBAqybYwjAglWU1YqhyppeF+GSnuGmjf2C9TrrDR8OvYpPUJFT1q1tsZSRBz86CQhSU1Yrg/ZtYDqIi3pTvcJig/nojYVdfpLwds+5+Pvek3cOvmO82KHgzxNXOIkh5AzGg9gZ5uWHpmx61sFLbIl3WIXBjOC1G2kafzyxnlrRTz0HuBhZrgKMLc1c0FZRYyxryIqirQ/U8wN8d7n3UvcO7AuR0mQqQGbTsWoB42zV12FoQjAUspyC4aF1L5NsA1U0+41Z7qhFBxK92LAU4IBO/y9FxqchE2dLb8ui7YLByiOSvPmfpXDcUMBeee5dFsbHNm3nslSSgEn7anye1RkrdkAvJ9RJ1cakrTmNdhUtPAaY95+4TMyY2eyHPWZzSQAPVSg1iWwSKy7gl9VbIb1kYrfmtqxBsRBCZm1cRAue4HiBpdtffp/z+j7MTIdzypFKnZrduRAnC4YgbLL6ZQJjTjaw=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39850400002)(39400400002)(39410400002)(39840400002)(24454002)(377454003)(53754006)(229853002)(25786009)(72206003)(6436002)(189998001)(478600001)(14454004)(53546010)(6116002)(3660700001)(4326008)(2900100001)(3280700002)(102836003)(3846002)(4001350100001)(86362001)(5660300001)(5250100002)(6486002)(83506001)(6506006)(76176999)(6916009)(42882006)(54356999)(2950100002)(99286003)(2906002)(6246003)(230783001)(66066001)(93886004)(50986999)(8936002)(81166006)(53936002)(110136004)(8676002)(74482002)(38730400002)(305945005)(7736002)(36756003)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: 9acd09f0-6fd1-442a-6ade-08d4c3789040
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1906;
x-ms-traffictypediagnostic: AM4PR0301MB1906:
x-microsoft-antispam-prvs: <AM4PR0301MB1906083D44488F610275A33EBCD40@AM4PR0301MB1906.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278178393323532)(278428928389397)(236129657087228)(192374486261705)(48057245064654)(167848164394848)(247924648384137);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906;
x-forefront-prvs: 0359162B6D
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <634DA0EA7586CD43AA5DC6CEB89FCC7E@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 07:36:34.8308 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/EupsPoY9RqAkqf6HbJHDh37TGx4>
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: Wed, 05 Jul 2017 07:36:40 -0000

Thanks Bjoern for this revision.

On 04/07/2017 16:01, "Bjoern Tackmann" <bjoern.tackmann@ieee.org> wrote:

>Thanks, Kenny, and please find my updated report below.
>
>
>=========================
>Summary: Almost ready
>
>
>Major issues: none
>
>
>Minor issues:
>
>
>I found the description of the encryption method comprehensible but a bit
>too informal. Maybe a pseudo-code description may be easier to understand?
>
>
>In that description, I stumbled particularly over the “_length block_” -
>why the underscores? Also, I think it would make sense to explicitly
>clarify that the 32-bit counter value for the CTR part is explicitly
>allowed to overflow.
>
>
>One aspect that read a bit arbitrary to me was the domain separation for
>AES by setting the first bit of the last byte to 1/0, and in particular
>that seemed a bit wasteful since it is evaluated only once with the bit
>set to 0. Wouldn't it be simpler (and
> possibly even with better security, but at the cost of limiting the
>length to 2^32 - 1 blocks) to not fiddle with the bits but just use the
>first counter-block to compute the tag? Note that this would certainly
>require re-doing some part of the security analysis,
> and the gains seem moderate, so I’m fine with this comment being
>discarded. (Just wanted to make sure it is discarded consciously.)
>
>
>After discussion with the other reviewers: The draft is ambiguous with
>respect to byte-strings vs. bit-strings. My interpretation, stemming from
>the beginning of Section 4 explicitly mentioning byte-strings, is that
>all strings must be properly byte-aligned.
> But given that, using bytelen(additional_length) * 8 and
>bytelen(plaintext) * 8, i.e. bit-length, is confusing. If the draft is
>supposed to deal with byte-aligned strings only (which appears
>practically sensible), then this should be made clear in the document,
> and byte-length should be used in the encryption. Otherwise, the
>algorithms have to be specified more clearly for the case of bit-strings
>that are not byte-aligned. In either case, the draft should be clarified
>in this respect.
>
>
>
>
>
>On Tue, Jul 4, 2017 at 3:53 PM, Paterson, Kenny
><Kenny.Paterson@rhul.ac.uk> wrote:
>
>Thanks everyone for this helpful discussion.
>
>If you want to update your reviews in the light of it, please go ahead and
>resend your reviews here. I'll then collate the three reviews we have to
>the CFRG list.
>
>Cheers
>
>Kenny
>
>On 04/07/2017 13:27, "Crypto-panel on behalf of Bjoern Tackmann"
><crypto-panel-bounces@irtf.org on behalf of
>bjoern.tackmann@ieee.org>
>wrote:
>
>>Hi all,
>>
>>On Sun, Jul 2, 2017 at 2:37 PM, Tibor Jager
>><tibor.jager@upb.de> wrote:
>>
>>
>>On 01/07/2017 20:34, Bjoern Tackmann wrote:
>>> Please find my review below. It's a nice piece of work and overall in
>>> quite good shape.
>>>
>>> After looking at the other reviews: I do not quite understand Tibor's
>>> comment on the bit-length vs. byte-length, given that the draft states
>>> that the scheme takes "arbitrary-length plaintext & additional data
>>> byte-strings" -- and for me the term "byte-strings" means that the
>>> byte-length of the strings is an integer.
>>
>>Indeed, this is one of the sections that suggests that it is implicitly
>>assumed that "valid" plaintexts and AD have always a byte-length which
>>is an integer.
>>
>>What I found *potentially* confusing is:
>>
>>- Then it would also be somewhat more intuitive/consistent to include
>>the byte-length of plaintext and AD in the length block. The current
>>draft includes the bit-length. (This is of course technically fine and
>>essentially just a different notation, but *could* be confusing.)
>>
>>- Also the example in Section 8 mentions the bit-length.
>>
>>
>>
>>
>>I fully agree that it would be less ambiguous to do these computations in
>>terms of byte-length. I do not see any advantage of having the scheme
>>operate internally in terms of bit-length, when only byte-length strings
>>are allowed.
>>
>>
>>
>>
>>- It would also make sense to let the encryption algorithm abort, if the
>>lengths of plaintexts and AD are not a multiple of 8 bits (and one could
>>ignore this check in applications where this is guaranteed by the
>>environment - but this is of course something that only the application
>>developer can decide).
>>
>>
>>
>>
>>Agreed.
>>
>>
>>
>>
>>Best,
>>Björn
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>