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

Tibor Jager <> Sun, 02 July 2017 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F84E12EA74 for <>; Sun, 2 Jul 2017 05:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fKviMbQvCXmK for <>; Sun, 2 Jul 2017 05:37:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10BB912EB4B for <>; Sun, 2 Jul 2017 05:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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: <> <>
From: Tibor Jager <>
Message-ID: <>
Date: Sun, 2 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: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-IMT-Spam-Score: 0.0 ()
X-PMX-Version:, Antispam-Engine:, 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: <>
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: 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.