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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 05 July 2017 07:35 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 7671B131AA2 for <crypto-panel@ietfa.amsl.com>; Wed, 5 Jul 2017 00:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level:
X-Spam-Status: No, score=-2.91 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_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 WlsJI3BvAnt3 for <crypto-panel@ietfa.amsl.com>; Wed, 5 Jul 2017 00:35:11 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0055.outbound.protection.outlook.com [104.47.1.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EEE131A9F for <crypto-panel@irtf.org>; Wed, 5 Jul 2017 00:35:09 -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=3MR8pjCtK9f8ltQ5vheX4qaYvcyjZnDYsDyjX+EZysc=; b=Qs3bHM6R2aBQeT138uF+46nobdIp8DttRCsNYm4qbP8Mx4HhSAG/pzVbf4H+9lOFxjgMzlKW7JavCt0dxElbkWKbwVIiV3Gk9Sg1E7FBlYH2azytZ9ZvZHEUUsejh2RAm56vRGH5k1l/jbaofXTAHHFkL+RCuhWLQlMXt9YMrVg=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) 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:35:07 +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:35:06 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Tibor Jager <tibor.jager@upb.de>, "crypto-panel@irtf.org" <crypto-panel@irtf.org>
Thread-Topic: [Crypto-panel] Review of AES-GCM-SIV
Thread-Index: AQHS5eUMXPqksT4BkEOlrKXEsk18RKI/ZZ4AgAEupACAAyHcAIAAKM+AgAEUEICAABRfAA==
Date: Wed, 5 Jul 2017 07:35:06 +0000
Message-ID: <D5825520.98002%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> <fd89dbc1-012a-8816-cdfb-0b9f37bbe763@upb.de>
In-Reply-To: <fd89dbc1-012a-8816-cdfb-0b9f37bbe763@upb.de>
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: upb.de; dkim=none (message not signed) header.d=none;upb.de; 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; AM4PR0301MB1908; 7:fraiF14exptgFvP0QH4yw1AyAVCpdp2NVRsyzM6XYy0hR5wWIBhopBZNVHFp8c15e6JSxZVcCp1gu5XqQICeqgCnikHiYoCgiek2TwTQC+opcXYUaMvB1fhu6haDQ9Hw/JpNqaXY6jzvSAaVj9eUWrn6LGTApkU5qVd33P2kQd8Eoy6nV4/foxumCXOKGAJ4baGjGM21JXr3ZAjs4WQuFkxKwgHc5hQYcqbgm3a0nPflBzUPpO8ddNghkkWE/mXZx6PNm743HVopLyukURiIK4jokecGxTL3SbcuV0sXwepqwXP2yp6Ii2ytR0K80t6hJzH5orb4eZQ1gCren55mv8WoEtceXWbGsODxk38dq2AGAMbNIc8q+ThMhbPxDEjl5A/t7oSpyWPtVdIH99+TAPts6GJUHwoXInzHqfb1esVRPB+IEiOIVh0Ya7poyq+CHNnIHNzH3RhckoUNY2lLaB3JWLI5xt1SKBXNGh+PPjexxhtw15jwIG1w2PqFjWItm2xBZnCB3ZDDrhbm0HM0IMpwofDGpmwj4fJYxI+OU8bsC6JPFeaOftqO1+FVaFQawSPYqcARYbI9SV3wLjjv2mS9c5vNO6Kctmwf3AKhxpJ3Ud/qfhWHHE5B10XC1+gE0Q2KuiG8QeoyyCmFyItYtVsE4Jb6TdFbNheKj1UGES3Si38pxjAyRkmTuMtu9b0CXO/wCgYMtilrvaRCuS96Mw7Fhwizpv42H/4yLHEGt8XzHhQdbJGCp2BRFCJAJeKRJLXUmZMAELiQ/cKlgaqJK0yZomUluhE2YwNOlzIosaA=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(53754006)(377454003)(24454002)(38730400002)(6246003)(6506006)(5250100002)(189998001)(966005)(2501003)(66066001)(53546010)(86362001)(14454004)(53936002)(6512007)(6436002)(102836003)(6116002)(99286003)(3846002)(6306002)(83506001)(25786009)(2900100001)(5660300001)(3660700001)(81166006)(8676002)(3280700002)(8936002)(74482002)(2906002)(36756003)(4001350100001)(478600001)(230783001)(305945005)(6486002)(93886004)(50986999)(72206003)(7736002)(76176999)(42882006)(2950100002)(54356999)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: 6d322349-3a90-4477-d124-08d4c3785ba3
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:AM4PR0301MB1908;
x-ms-traffictypediagnostic: AM4PR0301MB1908:
x-microsoft-antispam-prvs: <AM4PR0301MB1908051E944D759D378BE18ABCD40@AM4PR0301MB1908.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(788757137089)(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)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1908;
x-forefront-prvs: 0359162B6D
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5B6555FAF8C3164C81DBB518D4719D55@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:35:06.6411 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/ARoOYqEa9Tt-JAGhSTTJTPiqVcc>
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:35:17 -0000

Thanks Tibor, much appreciated.

On 05/07/2017 08:21, "Crypto-panel on behalf of Tibor Jager"
<crypto-panel-bounces@irtf.org on behalf of tibor.jager@upb.de> wrote:

>Hi all,
>
>Please find my updated review below:
>
>==========================================================================
>======
>
>Summary: almost ready
>
>========================================
>Major concerns:
>========================================
>
>none
>
>========================================
>Minor comments and recommendations:
>========================================
>
>
>The draft is somewhat unclear whether plaintexts and additional data
>(AD) are always assumed to be given as *byte*-strings, or whether it is
>also possible to encrypt arbitrary-length *bit*-strings whose length is
>not a multiple of 8.
>
>
>On the one hand, at the beginning of Section 4 it is clearly stated that
>the encryption algorithm takes "arbitrary-length plaintext & additional
>data *byte*-strings".
>
>On the other hand, 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 misleading for
>developers.) Also the example in Section 8 mentions the bit-length of
>plaintext/AD.
>
>Hence, I want to suggest to mention this assumption about the plaintext
>length more clearly - even if it seems quite standard and will most
>likely hold for most application anyway.
>
>In the worst case, if a developer misunderstands this and allows the
>encryption with arbitrary bit-length plaintext and AD, then this may
>enable to break the integrity of ciphertexts (at least in theory), if
>the bytelen() function is implemented in the natural way.
>
>Let C = Enc(k,m,d,n) be a ciphertext, encrypting plaintext m with key k,
>nonce n, and additional data d. Suppose that |d| = 7 bits, and that
>bytelen() is implemented such that bytelen(d) = 1 (which seems natural,
>even tough bytelen(d) = 7/8 would actually be correct). Note that the
>encryption algorithm pads d with zeroes to a multiple of 16 bytes before
>it is processed by POLYVAL, such that in particular it holds that
>
>  C = Enc(k,m,d,n) = Enc(k,m,d||0,n)
>
>and the decryption algorithm accepts both d and d||0 as "valid"
>additional data for C.
>
>Of course this attack is rather theoretical, but it can easily be
>avoided by either including the precise *bit*-length of plaintext and AD
>into the length block, or by letting the encryption algorithm abort, if
>the lengths of plaintexts or 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).
>
>
>========================================
>Nitpicking:
>========================================
>
>Section 1 "Introduction", 1st paragraph: I suggest to replace
>  "...that is easier for practitioners to use correctly."
>with
>  "that is easier to use correctly."
>
>
>In Section 4, first paragraph, the text suggests that plaintexts and
>additional data of arbitrary length can be encrypted. However, the
>description of the decryption procedure in Section 5 rejects ciphertexts
>of size larger than 2^36+16 bytes, and Section 6 gives upper bounds on
>the plaintext and AD sizes P_MAX and A_MAX.
>
>
>In Section 4, last paragraph, the result of encryption is the "resulting
>ciphertext ... followed by the tag". Thus, in this notation, the tag is
>not part of the "ciphertext", but it is separate and sent along with the
>ciphertext.
>However, at the beginning of Section 5, decryption algorithm receives as
>input key, nonce, AD, and a ciphertext, and the ciphertext is split into
>the encrypted plaintext and the tag, thus the "ciphertext" contains the
>tag here. One could unify this, by always considering the tag as part of
>the ciphertext.
>
>
>Section 8, very very nitpicking: One could mention here that the
>plaintext are the bit strings corresponding to the *ASCII encoding* of
>"Hello world" and "example".
>
>
>Section 8, 5th paragraph, again very nitpicking: Some developers may
>have difficulties in understanding immediately which numbers are given
>in hexadecimal notation, and which in decimal notation. For clarity, one
>could write here something like:
>"example": 7 characters = 56 bits = 0x38 bits
>"Hello world": 11 characters = 88 bits = 0x58 bits
>
>
>Section 9, 7th paragraph: "Suzuki et al. [multibirthday]", the reference
>lists Kazuhiro as first author, so it seems this should be Kazuhiro et al.
>
>
>I did not check the test vectors.
>
>
>Regarding Scott's comment on the verbal description of the encryption
>and decryption algorithms: I had the same impression, some pseudocode
>may be helpful to clarify what is happening here.
>
>
>Apart from the above minor comments, I think that this is an excellent
>RFC, which is very clear, precise, easy to understand, and
>well-readable. The large number of test vectors will certainly be
>considered very helpful to many implementers. I think it is very useful
>to have a nonce misuse-resistant encryption scheme defined in an RFC, in
>particular if it is as competitive with weaker solutions regarding
>implementational difficulty and computational efficiency as this one.
>
>==========================================================================
>======
>
>
>Cheers,
>Tibor
>
>
>
>On 04/07/2017 15:53, Paterson, Kenny 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 mailing list
>> Crypto-panel@irtf.org
>> https://www.irtf.org/mailman/listinfo/crypto-panel
>> 
>
>_______________________________________________
>Crypto-panel mailing list
>Crypto-panel@irtf.org
>https://www.irtf.org/mailman/listinfo/crypto-panel