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

"Paterson, Kenny" <> Thu, 22 June 2017 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 660C7129548 for <>; Thu, 22 Jun 2017 07:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TV7EyHjT0wHC for <>; Thu, 22 Jun 2017 07:32:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C109129535 for <>; Thu, 22 Jun 2017 07:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sELHRnJG4oXl9goxvZKjNT4nRmG8P1WuXt+dHLfGUKg=; b=UkruoNThjISi6JqFfefpnp3sniNIqfalYOTzpuM7WEx11vNUPX5djxBy4Zpicn2hN/9H8LFcdOIVHCv5/XIsu4fSRjmRO853esLN+5nZxX9OdJbFUCZ+Em3BWzjPG1SL9KJRwKvJz9vd6qg71CtvUrza0DEGtUxRUjyBMRoJ+WU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 14:32:08 +0000
Received: from ([fe80::a0cf:ee9d:63a3:d1ab]) by ([fe80::a0cf:ee9d:63a3:d1ab%14]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 14:32:07 +0000
From: "Paterson, Kenny" <>
To: Tibor Jager <>, "" <>
CC: "" <>
Thread-Topic: [Crypto-panel] Review of AES-GCM-SIV
Date: Thu, 22 Jun 2017 14:32:07 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:itTdt4RJ38JjNUCGb2PAIhssCZOfwP3d2Jcagv4M0WMYPZTNknqLCb+r0xYSz/eICcapg9qh8LLJnOeolfYaUKG/T+A2G1m7B8YIAbArBGGiEV4GMLOO4jJVUfzQfAa5yLHoK1HFJCbALqzOfLf/Ueb3LmTR5xyPr4xksSFwma4YRmjbjhWqcm2x7cgsg7ZSXeWcCfCtOW8FvoxI++tsY2q2HZpTTvqh2gzZZPLerCcbsMQKHNEANqf6AhQSbvbLE8vbjqHEEeQOboXmcjCk0N+OJPtHO7XQDuP3s6lm4vy+hrmZyUdgjjGjnKclFKxPjHKErcQhImoXsQojrtkZUyzpi1j3MK4kPN7Ey2Tq/+zykrNQvLsohbEvSVGctUWf4GmYjbo/BZuDxVJu3nSkXSyq/MyOAsc4j662DGn3McT3cHGt/IfRJQm08MvpfP5FAi+eeqsO7+I7IzHC/NUNRMAhnq36dZuNJgRUorBr6hIIUcBxBqikbtXQjklUdP2yEhGhEOLBcEpTK+2S5GVbKj90lLqv9UfiBblslJUbIeLSFzD1ZUtHfXSZrBA7+xQG3It4Oyn1JReLAotYQWkWOwUasAqgYmTUaQWtKnWfJnFsddBoNKdFw9xw17sq78S1S8/fNfdsx3RO6Efpvi0xW3IP6Z+wSRJHrCPkKnJtDTeM5wplAbXA/ImKPxcboq+Tpds+r9eLv6h9Js9dfvJ9O2jZQXsv0EsKeiGvSAf2Zf5vPgRom6xX/nrlmLmic+/LXTQ9hqd9XBfn2cSj2TAVUBbYZd+Zyo/6kdvaRjD+fo8=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39840400002)(39410400002)(39850400002)(53754006)(24454002)(2950100002)(305945005)(6436002)(38730400002)(2900100001)(8936002)(76176999)(54356999)(102836003)(5250100002)(99286003)(6512007)(6116002)(2501003)(3846002)(50986999)(53936002)(229853002)(3660700001)(4001350100001)(42882006)(5660300001)(93886004)(3280700002)(25786009)(4326008)(36756003)(53546010)(66066001)(189998001)(72206003)(14454004)(86362001)(6506006)(74482002)(7736002)(81166006)(83506001)(8676002)(230783001)(6486002)(2906002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907;; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: b85b911e-ab5f-41a0-447b-08d4b97b7605
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1907;
x-ms-traffictypediagnostic: AM4PR0301MB1907:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1907;
x-forefront-prvs: 03468CBA43
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 14:32:07.7454 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907
Archived-At: <>
Subject: Re: [Crypto-panel] Review of AES-GCM-SIV
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jun 2017 14:32:14 -0000

Thanks Tibor - this is really helpful.



On 22/06/2017 14:19, "Tibor Jager" <> wrote:

>Hi all,
>Please find my review below:
>Summary: almost ready
>Major concerns:
>Minor comments and recommendations:
>Section 4, first paragraph after the pseudocode:
>The length block contains the length of the plaintext and the length of
>the additional data (AD), computed as
>  bytelen(plaintext)*8  and  bytelen(AD)*8, repectively
>Is it possible to encrypt such that the length in *bits* of either the
>plaintext or the AD is not a multiple of 8? If yes, then how exactly is
>the bytelen() function defined in this case?
>For example, 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 may
>happen, if bytelen() returns only integers, even tough bytelen(d) = 7/8
>would actually be correct). Note that then the encryption algorithm pads
>d with one zero, and we have bytelen(d||0) = 1, too. Therefore it holds
>  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. (A similar attack may be possible to modify
>plaintexts, too.)
>Depending on the application, this may pose a security issue, or at
>least an implementational difficulty, because it is natural to implement
>a bytelen() function in a way such that it returns only integers. (In
>particular if a developer only has plaintexts/ADs in mind whose size is
>a multiple of 8 bits, even though an application may permit other
>plaintext/AD sizes).
>(a) If plaintexts and AD may have bit-lengths which are not a multiple
>of 8, then the bytelen() function should be replaced with a bitlen()
>(b) Alternatively, if it is implicitly assumed that the lenghts of
>plaintext and AD in *bits* is always a multiple of 8 (which may be
>reasonable for most applications), then this should be clarified in the
>RFC. Then either encryption woukd fail if plaintext or AD do not have
>appropriate length, or it should be decribed how plaintext/AD can be
>padded to appropriate length.
>I think that (a) seems preferable, because it seems simpler, more
>general, and appropriate for an encryption scheme based on counter mode
>that permits arbitrary-length plaintexts.
>Section 1 "Introduction", 1st paragraph: I suggest to replace
>  "...that is easier for practitioners to use correctly."
>  "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
>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.