Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06

Yehuda Lindell <Yehuda.Lindell@biu.ac.il> Tue, 03 October 2017 05:30 UTC

Return-Path: <Yehuda.Lindell@biu.ac.il>
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 56CF11342D0 for <cfrg@ietfa.amsl.com>; Mon, 2 Oct 2017 22:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=biu365.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 k2yiuK_3d2dw for <cfrg@ietfa.amsl.com>; Mon, 2 Oct 2017 22:29:57 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0096.outbound.protection.outlook.com [104.47.2.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3D513301B for <cfrg@irtf.org>; Mon, 2 Oct 2017 22:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=biu365.onmicrosoft.com; s=selector1-biu-ac-il; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j5CYtGY0TpkmAT2GSl+7r0CDwMp9ezQQ2peMugTNjjY=; b=ON3qjaMu0YQ2eU7wyIyl/DKd8OsAX0PwdNTNMPE7Mt+fMv+9zCqUyKzKnTevTPgRyezkqlrCMrbqe1qZ7PVvcsIUJZc9WpLP61pa32hqhL/CTRlacZSsOpqxYL2XWURalX9AAGzmTKe1GkjIOO3SoG2bTZluNrIkhvwQydwLL6Q=
Received: from VI1PR04MB3021.eurprd04.prod.outlook.com (10.170.228.143) by VI1PR04MB3021.eurprd04.prod.outlook.com (10.170.228.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 3 Oct 2017 05:29:48 +0000
Received: from VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::7d5a:9e3a:92f:7b3c]) by VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::7d5a:9e3a:92f:7b3c%13]) with mapi id 15.20.0077.018; Tue, 3 Oct 2017 05:29:48 +0000
From: Yehuda Lindell <Yehuda.Lindell@biu.ac.il>
To: "cfrg@irtf.org" <cfrg@irtf.org>, Paterson Kenny <Kenny.Paterson@rhul.ac.uk>
Thread-Topic: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06
Thread-Index: AQHTPAie8f6pbpDtCkaVEQgXSqmCwA==
Date: Tue, 03 Oct 2017 05:29:44 +0000
Message-ID: <6FE8E700-E7F8-46F5-8EC4-E948FDB1D9BE@biu.ac.il>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [81.218.146.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR04MB3021; 6:9VL0QkOIWt4+hKqja798mmm1uz3uwLly/o/MQ+vwnP7vuAxRtxR8ocDdaSHDPcqCvNTTGJpalkC1ZroWGzhusmB/X6TaPgxQDDmYJWSfO6+zH8NFoHEm/OQKcWliTztHU6HXE7XGX9bjHDYqcHmlG63Q27H9PAlplG8vkrKgaFIHKUYVPtoDpeCUL5HxBH9ZflYB/u3bxiljCtEPKweGKsHx+rncBXHSy0GznysP7ttqwq+lhyvygnI6ljGpm8nToWMtLlLcW45KHFxeffTH9cOGQGVJK27c5uSAoHcgHiwnsm55RX/1gT7VU5prVL9bua2P2pIX9NY8aC0UCuEveg==; 5:eK3B3vTVzXSsIKLGwH4Wz5h3RkqHxKAMKCv5zEnz8vurtnqgyxrQkrNHomm6HRpUuSpQQ/5XX/xtExpkNWvPPmVeBvxG7Rr5eCZEEd3mZRcV+yAU/MrajXJw/BvYqJZVbxhFSnBW191mnG+Fu9jszw==; 24:92qo+3Xs8Z16kz4yx2SfrElcehBRWkgtbzCnuNqpaLnYovUwCDqXEpf9RUH4V4QbqPF2Mrvvkcpp0+6bC9k21xMR7GcFh4ncg1edTEC1xN4=; 7:JjNjQJSlMFqrgxk+fcs1XtckTtg8P+HWaSiz9Ho+7Ahj6MeTjWHg444+GdYuMx6B63LknxrAHp0Jzk5kgZ3CLuM3uuwDcOR2lAir7zsuOuzP7jbczk4BVPkLgaRStbHwEl94aOwFY6/68ud3NHD5GRFnufVOCsMVO1xWGPKlsYlJstwHcwA2G82FmupB5Z/Wwgb4bH3XyWBd10y7MXqXUxOLXZpT3sJt7EaKqA6BvTg=
x-ms-office365-filtering-correlation-id: bee9fcdb-ade8-4600-5654-08d50a1fc39b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR04MB3021;
x-ms-traffictypediagnostic: VI1PR04MB3021:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Yehuda.Lindell@biu.ac.il;
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-microsoft-antispam-prvs: <VI1PR04MB3021287F32AE4A7C56E52BE1C3720@VI1PR04MB3021.eurprd04.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR04MB3021; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR04MB3021;
x-forefront-prvs: 044968D9E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39830400002)(189002)(199003)(6116002)(105586002)(99286003)(3846002)(102836003)(82746002)(97736004)(6246003)(8656003)(305945005)(66066001)(230783001)(6512007)(478600001)(413944005)(2501003)(83716003)(5250100002)(106356001)(54356999)(50986999)(3660700001)(72206003)(99936001)(8936002)(8676002)(2900100001)(786003)(81156014)(229853002)(6436002)(6666003)(68736007)(6486002)(316002)(86362001)(101416001)(33656002)(81166006)(14454004)(3280700002)(189998001)(7736002)(53936002)(25786009)(42882006)(74482002)(36756003)(5660300001)(2906002)(74826001)(110136005)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB3021; H:VI1PR04MB3021.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: biu.ac.il does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_0D26DFB4-7619-4952-877D-18549780D505"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
X-OriginatorOrg: biu.ac.il
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2017 05:29:44.9325 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 61234e14-5b87-4b67-ac19-8feaa8ba8f12
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3021
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/f-jxn154tFXQ65033tUBw1vvl90>
Subject: Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Oct 2017 05:30:00 -0000

Dear all,

The paper by Bose, Hoang and Tessaro (BHT) shows that AES-GCM-SIV has excellent multi-user security bounds (according to the authors, this is the first scheme that has been shown to have the property that the multi-user security is essentially as good as the single user security). Thus, this is great support for AES-GCM-SIV as a standard.

Conceptually, the reason why AES-GCM-SIV gets much better multi-user security than other modes is due to the continual key derivation that ensures that even if two users have the same key, the damage is minimal since they must also use the same IV in order to face a problem.

The authors also show that the ORIGINAL key derivation mode proposed for AES-GCM-SIV is actually good enough (i.e., simple key derivation via CTR mode, and without truncation). They say that it is more efficient, and this is true theoretically. However, practically, when using AES-NI, the cost of 2 additional encryptions for the key derivation is almost zero due to the pipeline (2 more cycles), and negligible even for reasonably small messages. Especially, since these are shadowed by the key expansion that is required in any case.

At the time, there were objections to the plain CTR derivation method, during the CFRG discussions (e.g., due to the fact that for 256-bit keys, this rules out the possibility of keys of the form K||K). Instead, an OCB style derivation was promoted. Subsequently, we ended up with the current truncated CTR method. We therefore propose to not change the key derivation method (again).

Thanks,

Shay, Adam and Yehuda