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

Bjoern Tackmann <> Sat, 01 July 2017 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D110F1274D0 for <>; Sat, 1 Jul 2017 11:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BMVzglzdavgB for <>; Sat, 1 Jul 2017 11:34:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF7C1120454 for <>; Sat, 1 Jul 2017 11:34:43 -0700 (PDT)
Received: by with SMTP id v197so20440866ybv.3 for <>; Sat, 01 Jul 2017 11:34:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zH06pwSP8/OO4g9/4clKtWmd6u8rEvdd1msK4aY9oUU=; b=AyhZMHtY6ooKC/6mAGwtsLBjfkaBkFCe6SnEL7amN8+g7ZjAxfqLDT4oCJkY/SjHNk S7B4LBHDCCfin7epMf6p6/rYiqIqGC3iIpqMip/Ul+B8qROnDq2Y1/3HSh7JRyv8Qlue hiyPO4rFauylv7t9TIDzlQevwLS7TsyusvpSdk2InnygCLo+fyB6GQYStxBBfQF+PCDD VN9JisXYl6vsCFESIXALnpcs0OQp5j6f4AwyVTIptHlQYzxudgpVNR5N3K3+t01i2UoU FTcVsibEyHO9FA9ujxJBLO0cnf7JsRsEeALZu29V1gGh5yCKGjfzim2/L3E5IIvAl8iS HGzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zH06pwSP8/OO4g9/4clKtWmd6u8rEvdd1msK4aY9oUU=; b=A+eDhm8tM8QlNtbGZxGtQhwN536STYZ65qrLJOXLw7sS1LLy7LaPlmeG8NSLI2nSVi ahbzWjw9SyBdXNgnOF2gv0/oTkoohy0jR/ySVKfBWlMkP8axYAJnkkd9B6XGbX/mrdjI U54RNYCeD9yUQ/HvKcVajxDpgj7e/dqvHxJFXpoBY+JGvEds3u/nFbqdbUchAt5GQgI5 4sxk5urp/Drozs+oJjSbaRRWSASJ6Qm+VSMK/NSPDqx55rUUXmR3p8vEPWqDZbCoGH9G fC2AX1rF0xv2Hjeob4L8h70qzokWUz0oQgb3y6/R2QA4RTbmWnVxt8Z+fOo5xNY1Hc08 lj/g==
X-Gm-Message-State: AKS2vOypcbYTJmMgBpfWy2nTvJ+SkwojlKcoBTiggT0AejJNnhqFw13Z mm0nhDabo0IYKwDXbIpTFA6ZP9kcj02B
X-Received: by with SMTP id t6mr20971559ybj.221.1498934082774; Sat, 01 Jul 2017 11:34:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 1 Jul 2017 11:34:42 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Bjoern Tackmann <>
Date: Sat, 01 Jul 2017 20:34:42 +0200
Message-ID: <>
To: "Paterson, Kenny" <>
Cc: "" <>, "" <>
Content-Type: multipart/alternative; boundary="089e08221adc8bfd6f055345c9b6"
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: Sat, 01 Jul 2017 18:34:46 -0000

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. However, since this lead to
confusion, it may make sense to state this more explicitly.


Summary: Almost ready

Major issues: none

Minor issues:

I found the description of the encryption method comprehensible but a bit
too informal. Maybe a pseudo-code description may be easier to understand?

In that description, I stumbled particularly over the “_length block_” -
why the underscores? Also, I think it would make sense to clarify that the
32-bit counter value will overflow (and that this is intended).

One aspect that read a bit arbitrary to me was the domain separation for
AES by setting the first bit of the last byte to 1/0, and in particular
that seemed a bit wasteful since it is evaluated only once with the bit set
to 0. Wouldn't it be simpler (and possibly even with better security, but
at the cost of limiting the length to 2^32 - 1 blocks) to not fiddle with
the bits but just use the first counter-block to compute the tag? Note that
this would certainly require re-doing some part of the security analysis,
and the gains seem moderate, so I’m fine with this comment being discarded.
(Just wanted to make sure it is discarded consciously.)

On Thu, Jun 15, 2017 at 4:38 PM, Paterson, Kenny <>

> Dear CFRG panel members,
> Any volunteers from the panel to perform a review of:
> I'd like to move it towards last call, and having a couple of reviews from
> you fine people would help give us the confidence to do so.
> The draft might be best read in conjunction with the technical paper:
> though of course it needs to stand alone as an RFC.
> Let me know.
> Cheers,
> Kenny
> _______________________________________________
> Crypto-panel mailing list