Re: [Cfrg] AES-GCM-SIV with a new key hierarchy

"Gueron, Shay" <shay.gueron@gmail.com> Sun, 26 June 2016 08:31 UTC

Return-Path: <shay.gueron@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 6EF6812D09F for <cfrg@ietfa.amsl.com>; Sun, 26 Jun 2016 01:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 lyviRpyJwdUX for <cfrg@ietfa.amsl.com>; Sun, 26 Jun 2016 01:31:48 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 74AB112B071 for <cfrg@ietf.org>; Sun, 26 Jun 2016 01:31:48 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id 187so16669536wmz.1 for <cfrg@ietf.org>; Sun, 26 Jun 2016 01:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-transfer-encoding; bh=qR9FCv+yxuJcSo5vDYLqlmN6v+XDdGqKlt4z7u4xQdU=; b=T7lOEMWXW+UyfLuAHwsi/Dolj77h3dlRWH0i7V1eNrZRWwlrus6F3zmPdvsivzhTNm xxp6M98bjWcs12vsUJBIHFhOnX55GIKW+O1yjabx8SfbSikmeYvZy/UnWrxu9amRHD+7 AuhV9PW+nmFPwx60XE3ZggYgDYFmve3E6vY/N9UnJSbwPUZBwbE1Zgx35fA/FYGFjgd5 739M3lL2cNWk9mYD8XBLC6qKqhzSMREu92o/FlMeX+lgO44ORwondMbf2pHZ5+UPM0Ga fO87laYeLwsxB/RtYdWEk32FiGnMN9MtoMnDN0QzAy/4QOmdIXbZhBtDloUf7nYSkCsR 2jJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version:content-transfer-encoding; bh=qR9FCv+yxuJcSo5vDYLqlmN6v+XDdGqKlt4z7u4xQdU=; b=go2CRk/B1SbPe03Th3NSD2Bl/HbeXz48hHFA0BkTMB5w2kpTq5vTROdVuSL1xadqp6 A8FcJaN9XkZh3pvxBEI1nSgSoOS/RsjSkgsHo7EqGNv7GDEHJe9vkCRy0gXW4g9/G6n9 zxgiOcOC21vScTX5fDxfni5gyfIBLm3LaCOzlgGXx8paegJTmZv/ql3CP+OxMjb13nRB yN3jRAw6W7ilzI7jvJXcIP3hY/+dgl4VryjmStOTttBLZCNzzVKA1TvN0I5YX4hn0MrM kkirDTgXH1MiQoK+CemjH0v2csBSd1GaRq5t+s0gNBehC7XLwkrrcClSNPMc0LUVGDlX /E8w==
X-Gm-Message-State: ALyK8tIpRZCpxg+18gM9RlIwc+NgZOKtqdP2quUdceHp7hASfuDMoXeHpmH4olutJRgpcw==
X-Received: by 10.28.165.206 with SMTP id o197mr5738933wme.102.1466929907023; Sun, 26 Jun 2016 01:31:47 -0700 (PDT)
Received: from [132.74.211.74] ([132.74.211.74]) by smtp.gmail.com with ESMTPSA id f189sm5433705wmf.19.2016.06.26.01.31.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 26 Jun 2016 01:31:45 -0700 (PDT)
From: "Gueron, Shay" <shay.gueron@gmail.com>
To: Aaron Zauner <azet@azet.org>
Date: Sun, 26 Jun 2016 08:26:12 +0000
Message-Id: <em01122224-6812-4371-a628-21d5f8515794@sgueron-mobl3>
In-Reply-To: <1D6C8C6D-8D82-43D4-A1B9-800C493E6BD0@azet.org>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/lM8gttOdcr2SXDf86fSYFfs5AT4>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
Cc: Yehuda Lindell <Yehuda.Lindell@biu.ac.il>, "cfrg@ietf.org" <cfrg@ietf.org>, Adam Langley <agl@google.com>
Subject: Re: [Cfrg] AES-GCM-SIV with a new key hierarchy
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Gueron, Shay" <shay.gueron@gmail.com>
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: Sun, 26 Jun 2016 08:31:50 -0000

Of course - let me describe.
For simplicity, I describe the case of a 128-bit MK.

Option 1: K1 = E_MK (0), K2 = E_K1 (0)  (K1 will be used for encryption, 
and K2 for the authentication)
Then continue AES-GCM-SIV as it is defined now (including a derivation 
of a record encryption key, per nonce N)

Option 2: K1 = E_MK (N), K2 = E_K1 (N)
Then AES-GCM-SIV as it is defined now, but without an  additional 
derivation of a record encryption key; just set K1 as the record 
encryption key.

Note: Option 1 is merely a static "pre-derivation" (where K1, K2 can be 
cached). Here, MK is used directly only twice.
Option 2 uses MK (directly) with each nonce. Here, the hash key also 
depend on the nonce.

There is another option.

Option 3: K1 = E_MK (0), K2 = E_K1 (0)
Then continue AES-GCM-SIV as it is defined now (including a derivation 
of a record encryption key, per nonce N) and also define a record hash 
key via E_K2 (N).


These options offer different nuances, and would have a noticeable 
performance effect only for short messages. My favorite, among these 3, 
is Option 3 (that seems to enjoy all the benefits, at a small additional 
latency).


Shay


------ Original Message ------
From: "Aaron Zauner" <azet@azet.org>
To: "Gueron, Shay" <shay.gueron@gmail.com>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>; "Yehuda Lindell" 
<Yehuda.Lindell@biu.ac.il>; "Adam Langley" <agl@google.com>
Sent: 6/26/2016 11:07:36 AM
Subject: Re: [Cfrg] AES-GCM-SIV with a new key hierarchy

>Hi,
>>  On 25 Jun 2016, at 01:10, Gueron, Shay <shay.gueron@gmail.com> wrote:
>>
>>  An alternative would be to incorporate the nonce from the beginning, 
>>during the derivation of K, H from MK. This will modify the record 
>>encryption key and also the hash key per each nonce. In that case the 
>>extra derivation of the record encryption key (per nonce) could be 
>>skipped (but also could be not done).
>
>Could you clarify on that paragraph? e.g. with pseudocode?
>
>Incorporating the nonce in the MK derivation step makes sense to me.
>
>But; I don't fully grasp the last part of this paragraph; if you skip 
>the extra derivation per record encryption key per nonce you lose 
>nonce-MR?! Given the nonce is incorporated in the MK derivation step, 
>this isn't an issue, but I'm not 100% sure what your suggestion here 
>is.
>
>Thanks,
>Aaron