Re: [Crypto-panel] Review of AES-GCM-SIV
Tibor Jager <tibor.jager@gmail.com> Thu, 22 June 2017 13:28 UTC
Return-Path: <tibor.jager@gmail.com>
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 88356128854 for <crypto-panel@ietfa.amsl.com>; Thu, 22 Jun 2017 06:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ao2Ldh3VdKjy for <crypto-panel@ietfa.amsl.com>; Thu, 22 Jun 2017 06:28:01 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 8B188126E64 for <crypto-panel@irtf.org>; Thu, 22 Jun 2017 06:28:01 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id 16so11848231qkg.2 for <crypto-panel@irtf.org>; Thu, 22 Jun 2017 06:28:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DjajDdIBfbxm/rzgC16NO7gD7hFS7BPd6M5rm/5UySY=; b=pnhBicnFWsLyDkLkKJkEVnh1soaeJigDfWeAsej/CXVh7SmTPQSdIbPNnnb0949hXL HQRUCXKv+b2uDz6XC5S+ZbhRBlw4okwbrtGTi/VjBE02IC6XK7G+wXXHlEPBriftZsTQ n+MItRmmwem3R7OUp2oKVsSj1bDe8Ba251U1ev8PEGR974MyFyQSuwmXvIVUJSeQL3Ea LmVkAJsJN+u+yleE+X+mIDBKoO8vgB/lXSgrquBgQvUET75oG+c3liFIOO4OW2yl3OnF GU8LA0uZlse/r7/aNuMK8w4ybFceq6txXBfj1EJqHPfU63sv6CdAJrXHHPmY6aCU4qlT BnLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DjajDdIBfbxm/rzgC16NO7gD7hFS7BPd6M5rm/5UySY=; b=Kf4QH9Zzuvvx/lZqX4w+qDFCfkk/JQFwd86DKVtisauiZ3FCKYidmCjtLOrI/vGX17 juWPnJfnddnBfAau9p7y/tDtUYHs0Om16beBCA3KjAlZhpVC4lkgMj9ug7ihkGysGx2X wd0whk8NceO0B9J7xhjGASa8LgMi1MzfK5RTW+yA7Z6PF8rRWCE1S8kdnbuWEBFHND2x Wt5NxlwYHS6i2GgKRwfvy/f1rH4ysYWOxCAVNJUAnxVbmJVPZ9PRnyR3Gi9/JN5hgoIY hkqGcRuLIj9Qs6ca9yZHjGPLbpIAsE9Y0SpVpLGh4YXIoVH8+633BQB2DzKM0slTnPux q+xw==
X-Gm-Message-State: AKS2vOxRaO5bTLVXSWedImsH8q3pTnEjsh5FxV+uBS7NbMRSoHA5fZDT NaCW7FEgpGTG6YJSovmIOLQw/Pk8kZDT
X-Received: by 10.55.210.193 with SMTP id f184mr3052669qkj.76.1498138080389; Thu, 22 Jun 2017 06:28:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.153.4 with HTTP; Thu, 22 Jun 2017 06:27:59 -0700 (PDT)
In-Reply-To: <c1299ee52c524040ac0b2d2041eeb759@XCH-RTP-006.cisco.com>
References: <D5685A61.9675F%kenny.paterson@rhul.ac.uk> <D5685B25.96765%kenny.paterson@rhul.ac.uk> <c1299ee52c524040ac0b2d2041eeb759@XCH-RTP-006.cisco.com>
From: Tibor Jager <tibor.jager@gmail.com>
Date: Thu, 22 Jun 2017 15:27:59 +0200
Message-ID: <CA+yVaTzr8QncLXh_i6176amsK4-_s7O8DiYrE=Y=6vKc+NX+cg@mail.gmail.com>
To: "crypto-panel@irtf.org" <crypto-panel@irtf.org>
Cc: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, "alexey.melnikov@isode.com" <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/tbc7bBt-h_UGSQgqOsFoDpXK3dA>
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: Thu, 22 Jun 2017 13:28:03 -0000
Hi all, Please find my review below: ================================================================================ Summary: almost ready ======================================== Major concerns: ======================================== none ======================================== 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 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. (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). Recommendations: (a) If plaintexts and AD may have bit-lengths which are not a multiple of 8 (which is somewhat suggested by the statement "plaintexts can have arbitrary length" in the 1st paragraph of Section 4, and by the fact that the example in section 8 talks about the *bit*-length of the plaintext), then the bytelen() function should be replaced with a bitlen() function. (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. ======================================== 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
- [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