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

Tibor Jager <tibor.jager@upb.de> Sun, 02 July 2017 12:38 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 9F84E12EA74 for <crypto-panel@ietfa.amsl.com>; Sun, 2 Jul 2017 05:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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] 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 fKviMbQvCXmK for <crypto-panel@ietfa.amsl.com>; Sun, 2 Jul 2017 05:37:58 -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 10BB912EB4B for <crypto-panel@irtf.org>; Sun, 2 Jul 2017 05:37:57 -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:To:References:Subject; bh=EHhvjCKmcyF3Q/N65csIZLaeribW/bvPjuoYdZfhMmQ=; b=PONz5JFlSqoe+9QSjZ7Vjuzghek78tUdJ/xKPiaP83EUSp3N4rZyjlw77absbWgnKcYGaJhlhv6DZtBiqM3ucX48vvfPCajjmZsybCZiD60/2PBON48QmmiDr8nhpyQKgFvRyJJdqzAsxmXXGpxT9g5dE6pstm4NloIHw1l8ATE=;
References: <D5685A61.9675F%kenny.paterson@rhul.ac.uk> <CAFr4q=D8tm362WTQdZ97U93eavOafYwyLOFWTD2jK8YR2B+X-w@mail.gmail.com>
To: crypto-panel@irtf.org
From: Tibor Jager <tibor.jager@upb.de>
Message-ID: <ab2e806f-e9aa-9bb5-2a12-f55f4a005fe8@upb.de>
Date: Sun, 02 Jul 2017 14:37:54 +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: <CAFr4q=D8tm362WTQdZ97U93eavOafYwyLOFWTD2jK8YR2B+X-w@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-IMT-Spam-Score: 0.0 ()
X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.7.2.123016, AntiVirus-Engine: 5.38.0, AntiVirus-Data: 2017.6.19.5380004
X-IMT-Authenticated-Sender: uid=tjager,ou=People,o=upb,c=de
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/qxKVc1dBlbpOmit8xLfGuOxIYwk>
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: Sun, 02 Jul 2017 12:38:00 -0000

Hi all,

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.

- 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).

I do not see this as a big issue either, I just wanted to suggest to
mention this assumption about the plaintext length more clearly - even
if it seems quite standard to assume plaintexts/ADs are always given as
sequences of bytes, and will most likely hold for most application anyway.

Cheers,
Tibor