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

Shay Gueron <shay.gueron@gmail.com> Thu, 12 January 2017 10:01 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 B83071294C8 for <cfrg@ietfa.amsl.com>; Thu, 12 Jan 2017 02:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 71EnYdyHS7JB for <cfrg@ietfa.amsl.com>; Thu, 12 Jan 2017 02:01:18 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 9AA281293F8 for <cfrg@irtf.org>; Thu, 12 Jan 2017 02:01:18 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id l19so8863140ywc.2 for <cfrg@irtf.org>; Thu, 12 Jan 2017 02:01:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YE544rX5ia9CNu0iQHEXmOvU0EkgGGEgHAnClAohYu8=; b=QBeICDbhJi4/U8hhcrDxOnT1yGZ9AH4ZVeqIXTwos0DIMVI0a4GivzCojny/bDCmcm KecGPyCqheiB8qF+FW+vqMxCEh7tw7/R2QdfcDbLLGAsQgqiarPwNaU61bd+LC92puqj 3qm/zsMV7CH4Z7I5QfAnfWW/2XfTp30IAqGIEK9S+enG5SdSVCq5/NTYFdkwAtkaSNkt LG0l8UWwjpC4WI/pCa3sIouqmoOT4dpKlQ1nExOKSjRKbUHd1Gd/wxMuqqWSaIHf7vvc Ykx2a+VlbYPWXOiFbuQIn/wLRZcwCX2c2oKNh1x7/WuhWhPFtJvJQi3Qcvy8qVERdWG4 hq+Q==
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=YE544rX5ia9CNu0iQHEXmOvU0EkgGGEgHAnClAohYu8=; b=b9KTt42rEzYDiRMM4Dezq4P1Atet3FyxlDtcfv5acCuXNMIZlfiWEhiCmc1iiflVsF P06EddZISnEYyor7AdcXCcUdm0yVuwOrpFrAudFmHuwfx8bsVMpfG9IdgntwDTXTpJL3 PwPNE27OhB3Uyzdv81wMBcb3g0w4eZUPllnCgjA518ev89SQGf+0qXg4xWZYQ4KyG+8R rrO0Kgtjf9Tq5gPT19FEIVtrsrj5zOzP6cnIAxQco02Y1qQoxpn10Aa3oUVUoAgtnEWK OeV2wStW6AYZE+Vxr1V0G5iVkpAqU7DLULDU8OXiUrMW4UB/HK8OCX0lrxKcjBH9cXM+ 1YRQ==
X-Gm-Message-State: AIkVDXKEDCVz5F3kEf0cusaNR6Q8fybh8CRylICWCDsd3g8BeycCXXxkqIhdaQOuFHpPU5aqEiLOnqnOs9Uqpg==
X-Received: by 10.13.246.134 with SMTP id g128mr11910198ywf.320.1484215277588; Thu, 12 Jan 2017 02:01:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.141 with HTTP; Thu, 12 Jan 2017 02:01:16 -0800 (PST)
In-Reply-To: <8ea394a8-1823-cdcf-4b4b-d313cf16b38f@lounge.org>
References: <em85e6ab2a-6a3c-4b2e-986d-2e44c2965663@sgueron-mobl3> <8ea394a8-1823-cdcf-4b4b-d313cf16b38f@lounge.org>
From: Shay Gueron <shay.gueron@gmail.com>
Date: Thu, 12 Jan 2017 12:01:16 +0200
Message-ID: <CAHP81y-SJZRANmSXsvABD3Gw0aRv+ZKm8uy0B6XNYp_f=0cE2w@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=94eb2c0327c46417830545e2cc8c
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/n42p9vN1-z19eNASQd7B0lzlh90>
Cc: Yehuda Lindell <Yehuda.Lindell@biu.ac.il>, cfrg@irtf.org
Subject: Re: [Cfrg] AES-GCM-SIV with a new key hierarchy
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Thu, 12 Jan 2017 10:01:21 -0000

Hi Dan,

Thanks for your question.

In general, some KDF is needed, in order to increase the number of times
that the algorithm can be used with a given key. So, we start with a KDF
that has a master key and derives a new key(s)  per nonce.

The "cascade" method we use now is also some kind of a KDF, and there can
be others.

However, your timing with this question is fantastic. Indeed, we were not
satisfied with the serialized nature of the current KDF, and are working on
a different (better) one. This work is coming to an end, and we expect to
post the revision of AES-GCM-SIV next week.

Thanks, Shay


2017-01-10 16:22 GMT-08:00 Dan Harkins <dharkins@lounge.org>rg>:

>
>   Hello,
>
> On 6/24/16 10:10 AM, Gueron, Shay wrote:
>
>> Hello everyone,
>>
>> I start a new tread.
>>
>> It is a branch off the one entitled "AES-GCM-SIV security of the
>> additional data" and initiated by Daniel.
>>
>> It combine Kenny's inputs about having two separate keys and the AEADE
>> interface (which he raised at the CFRG meeting in
>> Vienna in May and also mentioned, in the previous thread, that
>> concatenating 2 separate keys does not solve the problem that Daniel
>> raised).
>>
>> It also address a comment that Bart Preneel made at that CFRG meeting.
>>
>> ****
>>
>> It is possible to define AES-GCM-SIV with a standard interface that has a
>> single key (say, MK for "Master Key"), which can be 128 or 256 bits.
>> Basically, by adding the following key derivation step:
>>
>>     Using MK, derive two new keys K and H: K for encryption and H for
>> authentication.
>>     From that point on, apply AES-GCM-SIV as it is defined now, where (K,
>> H) are the keys.
>>
>> Note that K and H are derived statically from MK. The "record encryption
>> key" for the encryption depends on the nonce N, via another derivation, as
>> it is currently defined in AES-GCM-SIV.
>>
>> Note: the derivations are different for the 128 and the 256 bit keys, but
>> such derivations are already in use by AES-GCM-SIV.
>> With this, AES-GM-SIV could be used with the protocol Daniel described,
>> and would address Kenny's comment on the AEAD interface.
>> (I guess that it could be better viewed as a drop in replacement to
>> AES-GCM)
>>
>> The cost is the additional key derivation. this cost could be low if the
>> message is long, or if many messages are encrypted (so that K, H can be
>> cached).
>>
>> 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).
>>
>> I would appreciate any comments on this.
>>
>
>   Why not just have a single double-wide key the way AES-SIV (RFC 5297)
> does?
> It's 256 bits or 512 bits. KDFs are good at generating streams of any
> length so
> why not just let the KDF give you all that you need instead of doing
> additional
> derivations inside?
>
>   regards,
>
>   Dan.
>
>
>> Thanks, Shay
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>