Re: [Crypto-panel] Review of AES-GCM-SIV
Tibor Jager <tibor.jager@upb.de> Wed, 05 July 2017 07:22 UTC
Return-Path: <tibor.jager@upb.de>
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 624AF131830 for <crypto-panel@ietfa.amsl.com>; Wed, 5 Jul 2017 00:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uni-paderborn.de
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 DGpV1iJmQ9XZ for <crypto-panel@ietfa.amsl.com>; Wed, 5 Jul 2017 00:22:05 -0700 (PDT)
Received: from mail.uni-paderborn.de (mail.uni-paderborn.de [131.234.142.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C5E13183B for <crypto-panel@irtf.org>; Wed, 5 Jul 2017 00:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=uni-paderborn.de; s=20170601; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=vzErzMixNEzHCkxDB4+x6XXarMGC5Fx2uX7WFnUV1FU=; b=MgajK82G4WJDvtIhfwa06GDP3UiIDXbRRaL6aaBFzVJ0/5K/nA3xIOeZCCE1spWLdiabSTkZtdPKhIlCo5RIhDNWJZoaBo4aRSWYsiswpCrZjTrsfu4ELL+/PQ0UoGGHHUCHYWYMTlsrtUUyUasU8l8dsnbFhU0oC/w4uRsJhPM=;
To: crypto-panel@irtf.org
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>
From: Tibor Jager <tibor.jager@upb.de>
Message-ID: <fd89dbc1-012a-8816-cdfb-0b9f37bbe763@upb.de>
Date: Wed, 05 Jul 2017 09:21:59 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <D5815C4F.97F0D%kenny.paterson@rhul.ac.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-IMT-Spam-Score: 0.0 ()
X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.7.5.71516, AntiVirus-Engine: 5.38.0, AntiVirus-Data: 2017.7.5.5380000
X-IMT-Authenticated-Sender: uid=tjager,ou=People,o=upb,c=de
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/hwO8gOsctsSdbRHswvp3du9YiQs>
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:22:08 -0000
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] 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