Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications

Andy Lutomirski <> Thu, 07 April 2016 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C5BF12D1ED for <>; Thu, 7 Apr 2016 16:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 XF-Q2uqHHk0Y for <>; Thu, 7 Apr 2016 16:16:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9168B12D12E for <>; Thu, 7 Apr 2016 16:16:27 -0700 (PDT)
Received: by with SMTP id p188so117483511oih.2 for <>; Thu, 07 Apr 2016 16:16:27 -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=yd/bJP7//4XcHT/DvgMl361xwzkDpHhG+xXpSOmQQ/E=; b=vkeSraYJisotJ1kUwLhL9x9Z4InqP/CDAc6krSgrJxMR+A0Y3wGWjYb42b5dRObYk9 J2BDbcJxN/L4DZfUSOq5sni61E/k/fncPEu1ROL+SK+BgpuPdjBrYYyMCNrU/OMwNclt D92MkCz+zNJwv7NpmH8ew0lhdVxZTcAUtiml2YDyVckgJqW+PsNoS+hTWoLe6xk6RVbH 6S6X0dvy7zNRXefJiFwhHVW5qvWyjXBy+RfvkGP/ojCTPPec1QKQ6enrgrNUqpIPp4sO P7Tk1i0SEyv0pfDZcYdC2UH83YQAAs8vIm71XQTi6GDI0EuMd9qBn0+7i/8UhcV9w+Hy brDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yd/bJP7//4XcHT/DvgMl361xwzkDpHhG+xXpSOmQQ/E=; b=heX8vI+/NsJU8/YTd1VYF/dyoOhKy9mGmMpSPfK1SmMbVmIN+q2MtlgmSrENhH91ub UExNuxjf6oXPpCSkVYixolRhfh6g7LHlToVMZtQLDWZu3Yw3VS1ZazMOwAaq4FKL0AqG u1Id1YmnwIRtUdLGWmVgkY7veBKxv1I272nUi2SZ6w40b3f5mn1MC5lZbY2qi/qF1/mw WkDl7C3H/mNekTfNn5+81WqTlTYuuL2BxPYVzGlO4oXqC57zqUnWjcKSTQJYIY/4Tc03 SHCGhCmkFx/wlUFLmT3TJ0EOenp/4XfSxHtNChWGFrI92br2/cMd83vxbU8t+1QFTfUF ds6Q==
X-Gm-Message-State: AD7BkJLhDZa5jGzw4kDbZmMiLpcXZDDGF8WsuwFNOXqa/BlU77Fpu8Nce2AQUP0v3aVSc1dcGpkcAAPKGSwwrd2t
X-Received: by with SMTP id j5mr2796563oia.43.1460070986967; Thu, 07 Apr 2016 16:16:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 7 Apr 2016 16:16:07 -0700 (PDT)
In-Reply-To: <em615f096a-5286-4b23-b267-26099193d002@sgueron-mobl3>
References: <> <em615f096a-5286-4b23-b267-26099193d002@sgueron-mobl3>
From: Andy Lutomirski <>
Date: Thu, 07 Apr 2016 16:16:07 -0700
Message-ID: <>
To: "Gueron, Shay" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Adam Langley <>, Yehuda Lindell <>, "" <>, Adam Langley <>
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Apr 2016 23:16:29 -0000

On Tue, Apr 5, 2016 at 6:14 AM, Gueron, Shay <> wrote:
> The (ACM CCS) paper described a GCM-SIV implementation with 128-bit keys.
> The CFRG submission is different in two respects:
> 1. A 256-bit version that is added.
> 2. There is key derivation added (based on the nonce) to refresh the
> encryption key for each record.
> The purpose of #2 is to allow AES-GCM-SIV to use a single key multiple
> times. In the original paper version, an IV is derived from the universal
> hash function (and the nonce) over the message, and occupies 95 bits of the
> counter block during the encryption. Collisions are imminent after 2^48
> uses, and to maintain safety margins, we would need to restrict the usage of
> one key to 2^32 messages. This could seem like a real constraint for a real
> AE scheme. With a differently derived key (derived from the nonce), the
> lifetime of one key can be extended.
> The cost of extending the lifetime of the key is that of computing a key
> schedule, but this overhead is small on the target platforms that have AES
> hardware support.
> To clarify a possible confusion about the 256-bit variant: no 256-bit key is
> ever derived from a 128-bit key. A 256-bit encryption key is derived from
> the 256-bit master key and a (128-bit) nonce but two encryptions. The
> authentication key has 128 bits, and so does the authentication tag.

The only relevant text I can find in the draft is:

   If the AES key is 16 bytes long then define the _record-encryption
   key_ as the encryption of the nonce using the AES key.  If AES-256 is
   being used then this is insufficient as 256 bits of key material are
   needed.  Therefore the record-encryption key in this case is the
   concatenation of the result of encrypting, using the AES key, the
   nonce with the least-significant bit of the first byte set to zero
   and then to one.

This very much sounds to be like (a) a 256-bit key is derived from a
128-bit key and (b) the draft doesn't actually specify what the record
key is in any other case.  I interpreted the vague text to mean that
the record key is the AES key in all other cases.

Can you clarify the draft?