Re: [Cfrg] Updated bounds in AES-GCM-SIV paper

Adam Langley <agl@imperialviolet.org> Wed, 26 July 2017 22:26 UTC

Return-Path: <alangley@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE81131E92 for <cfrg@ietfa.amsl.com>; Wed, 26 Jul 2017 15:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no 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 ZAjUwUILCbJy for <cfrg@ietfa.amsl.com>; Wed, 26 Jul 2017 15:26:09 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 AE319131E8F for <cfrg@ietf.org>; Wed, 26 Jul 2017 15:26:09 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id g13so72907292ioj.5 for <cfrg@ietf.org>; Wed, 26 Jul 2017 15:26:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kLcoOjvEzo7C4Lt5TcaB65/AVcWwIHj7R4wrQOlFxds=; b=lNBy5ASetdQgACJwfS6HB//2is0HkFqiscECcaFEKkjOoWDKPS9GAu7sgfcU4aPG7n XIhBVVODpdUVihEBXm0/hPLqpm0Snd4mgUoR0pVYGRLpelxIcCsjVJQFtpENgRLbwCnY YqqEMHUwdZ6JNIuqtOwdsQGOe+CoyfYYDjGM1OhM6ec2xvvIdJyiqmVFdMuhznGPXL9o 9WKWvuYo/XyEa9xSVDIJNoGMxwhk8ufw0kWace/ieG7/+araGfbACtTxPMQ0dbWVjtKl WyvZW/ruzH9UEwlh+ORMndM/evFdFqNh5SlrMSC70HFykKIICMqixvgbaL5tA2m0KtBf ngVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kLcoOjvEzo7C4Lt5TcaB65/AVcWwIHj7R4wrQOlFxds=; b=d2SHvUzPYNF6pT5DnDRtqjc9Cmx63JGTTObYZAiwsaAMPApPECUgsTm+2q49CgqqP1 ufcvngiCGaD//eJsJo/0L94N9Mq4sJSmq69PCxy0y2sJMjSUv37OcfcYMW9yLm8DJzvo mt7WkYmulxWzkA70EjgRbvRQOot1qFPI82ES5pKsSi1L8jSW3wcUXK7Zl+hPDGZtLn/x AD/tGENd1wgoYSok83zDqJUGB+z9a0/fj88caLon/28+Zsg5me/ZCoLoliCtIr1opATc mkD+zIGxAglPWp0US0Mf8vMK5ejxu54oBT2weGzqAUlgIJXoqkIh0VVV6zyxyGDhR3oV KQsg==
X-Gm-Message-State: AIVw110zpg+0ltzvZJQZF6Hdwvh5hG0nfnggPGuBEMb7qGZjNJ29FTLB LpCTJUeAYggIe1nVCvCJwYOfDNagsg==
X-Received: by 10.107.157.8 with SMTP id g8mr2999688ioe.200.1501107968919; Wed, 26 Jul 2017 15:26:08 -0700 (PDT)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.79.38.216 with HTTP; Wed, 26 Jul 2017 15:26:08 -0700 (PDT)
In-Reply-To: <CAOOV4XvpdCuEc8s5iXr3mzxuCTXj63AP6wATriu=D3Dxs3zz4Q@mail.gmail.com>
References: <CAMfhd9UOFNfqoEp31r2moVaEfQZoeppP7h2Anrz0BBP518SeYA@mail.gmail.com> <CAOOV4XvpdCuEc8s5iXr3mzxuCTXj63AP6wATriu=D3Dxs3zz4Q@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
Date: Wed, 26 Jul 2017 15:26:08 -0700
X-Google-Sender-Auth: j0xIBh_SpRK6xLdTSV6THJzBJBI
Message-ID: <CAMfhd9UuZAfUFQpv0L_WZnhSUrpYdEMFzyZARO-12pchBc0AGA@mail.gmail.com>
To: Yannick Seurin <yannick.seurin@gmail.com>
Cc: cfrg@ietf.org, Tetsu Iwata <iwata@cse.nagoya-u.ac.jp>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/jaC1Y0TIl9pefzTJ8Mf4lNGJ2mU>
Subject: Re: [Cfrg] Updated bounds in AES-GCM-SIV paper
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jul 2017 22:26:11 -0000

On Wed, Jul 26, 2017 at 5:04 AM, Yannick Seurin
<yannick.seurin@gmail.com> wrote:
> We believe that the CFRG specification (especially Section 9) should be
> updated as well to reflect the new security analysis. Recommended usage
> limitations for an AEAD scheme (such as the maximal number of messages that
> can be encrypted with the same key) should be based on the maximal message
> length allowed by its specification (currently, 2^{32} 128-bit blocks). More
> fine-grained recommendations (such as "if the maximal message length in an
> application is 2^m and the maximal number of nonce repetitions is R, then
> the maximal number of messages that can be encrypted with the same key can
> be pushed to XXX") are likely to create confusion and incur implementations
> errors. For AES-GCM-SIV with randomly generated nonces (which has been put
> forward by the designers as the preferred way of generating nonces when no
> state can be saved by encrypting devices), this means that no more than
> 2^{30} messages should be encrypted with the same key, which contrasts with
> the recommended limit of 2^{50} given (without context) in Section 9 of the
> CFRG specification and in the abstract of [2].

While the maximal message length of AES-GCM-SIV is very large, we do
not think it useful to limit the total number of messages based on
it. Using such large messages is very rare (at best) and unwise with
any AEAD: large messages pressure consumers to process plaintext
before the whole message has been received and authenticated, because
buffering would be so costly.

We have just published -06, which contains updates in response to
several reviewer's feedback and also contains updated guidance
on the maximum number of messages for the case where the
maximum number of nonce repeats is 256 (which covers choosing nonces
randomly):

2^29 messages, where each plaintext is at most 1GiB
2^35 messages, where each plaintext is at most 128MiB
2^49 messages, where each plaintext is at most 1MiB
2^61 messages, where each plaintext is at most 16KiB


Cheers

AGL