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

Bjoern Tackmann <bjoern.tackmann@ieee.org> Tue, 04 July 2017 15:01 UTC

Return-Path: <bjoern.tackmann@ieee.org>
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 25C7F12706D for <crypto-panel@ietfa.amsl.com>; Tue, 4 Jul 2017 08:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=ieee-org.20150623.gappssmtp.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 rdPdpFxAEobP for <crypto-panel@ietfa.amsl.com>; Tue, 4 Jul 2017 08:01:42 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 ACB79131628 for <crypto-panel@irtf.org>; Tue, 4 Jul 2017 08:01:39 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l21so74568218ywb.1 for <crypto-panel@irtf.org>; Tue, 04 Jul 2017 08:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXGLFvatJA+1Kh3DIedi7canx+vBIUB2vC8bSgBUhmE=; b=RdTIIeFaeE7F0Mck7C5GKm/Hj7EugQRgmwNdZKfD7V5BeYVKyjaSK0PCzfpiXtOL6p xEDkNv+x/NrKgt+8sG1HglYa1oLou+jCk4EsA1CfdObs1DQqVHRpQ4hOaR4wo4n4KKm/ FH3YTwysOc83HznlXCtf368Fjl+JoGkS1VUzIuQ+7jzKSraeAtIPMRhjR/c25vJ9t5FC Y72RcpPrhNrZMaIZ//YPc50KhVMdqaANO6b6ehaa3tBVvln7rTZcOl+MTXoz/puB9wEK V49Df1ZiJ4/jlTCLmSlFJFA7OHletzX31XVg4kGb0aGcAAuRWXgcF3aYzPS8wUxNVs1M eeug==
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=SXGLFvatJA+1Kh3DIedi7canx+vBIUB2vC8bSgBUhmE=; b=BAEba5CaaD+Uofg0m60z4WFNlplZnkp7cojUNVEVDSJqYxpccZFI0e5zrG87XWgq4C aTMU9AsEQOjG83nJKdHViY/fgLUEAUgKeiVumbIoCPLbheBjiiKSRgzaPsat9U6VyYZw AWvlNhsuX4rnuR47iR4V15o44liA9M1J6XBP0t+vCY8wiuOjggpxjKiGQloYhigJakqc K1uEahHwPAkz1mge8YQAWWuPQ39jCP2xmkpYFVCRYOnEAbwxqDQeeUXmaarif0HPJ+0f 2BAwxLqik65O9CdrOqzW+iILB9zPZ5v7UWb4C/QgPFef+U/0X2XdZQLfm4Lf61JiBxNR tCyA==
X-Gm-Message-State: AKS2vOwCuljYL4glOcaFklb0cr8G8RPuHowD+KApIaNe99Vvi4Oj1bb0 kECltcSQ/ljxoddyL1SI5thtPhxTqvV/
X-Received: by 10.129.73.78 with SMTP id w75mr30658526ywa.244.1499180498665; Tue, 04 Jul 2017 08:01:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.179.2 with HTTP; Tue, 4 Jul 2017 08:01:38 -0700 (PDT)
In-Reply-To: <D5815C4F.97F0D%kenny.paterson@rhul.ac.uk>
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: Bjoern Tackmann <bjoern.tackmann@ieee.org>
Date: Tue, 4 Jul 2017 17:01:38 +0200
Message-ID: <CAFr4q=DF3GFwRzU-2t8WypNxno10odm++1n5EenVVNuhA=7E5A@mail.gmail.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Cc: "crypto-panel@irtf.org" <crypto-panel@irtf.org>
Content-Type: multipart/alternative; boundary="001a114da48414090105537f2936"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/6mQ3H4qT9T197F2SVxR9GOLrE0Y>
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: Tue, 04 Jul 2017 15:01:44 -0000

Thanks, Kenny, and please find my updated report below.

=========================
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 explicitly
clarify that the 32-bit counter value for the CTR part is explicitly
allowed to overflow.

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

After discussion with the other reviewers: The draft is ambiguous with
respect to byte-strings vs. bit-strings. My interpretation, stemming from
the beginning of Section 4 explicitly mentioning byte-strings, is that all
strings must be properly byte-aligned. But given that, using
bytelen(additional_length) * 8 and bytelen(plaintext) * 8, i.e. bit-length,
is confusing. If the draft is supposed to deal with byte-aligned strings
only (which appears practically sensible), then this should be made clear
in the document, and byte-length should be used in the encryption.
Otherwise, the algorithms have to be specified more clearly for the case of
bit-strings that are not byte-aligned. In either case, the draft should be
clarified in this respect.


On Tue, Jul 4, 2017 at 3:53 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
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
> >
> >
> >
> >
> >
> >
>
>