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, 05 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 >> >> >> >> >> >> > > > > > > > >
- [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Tibor Jager
- Re: [Crypto-panel] Review of AES-GCM-SIV Scott Fluhrer (sfluhrer)
- Re: [Crypto-panel] Review of AES-GCM-SIV Russ Housley
- Re: [Crypto-panel] Review of AES-GCM-SIV Bjoern Tackmann
- Re: [Crypto-panel] Review of AES-GCM-SIV Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Scott Fluhrer (sfluhrer)
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Review of AES-GCM-SIV Tibor Jager
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Bjoern Tackmann
- Re: [Crypto-panel] Review of AES-GCM-SIV Tibor Jager
- Re: [Crypto-panel] Review of AES-GCM-SIV Bjoern Tackmann
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Bjoern Tackmann
- Re: [Crypto-panel] Review of AES-GCM-SIV Tibor Jager
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny
- Re: [Crypto-panel] Review of AES-GCM-SIV Paterson, Kenny