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

Dan Harkins <dharkins@lounge.org> Wed, 11 January 2017 00:22 UTC

Return-Path: <dharkins@lounge.org>
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 7C67C129883 for <cfrg@ietfa.amsl.com>; Tue, 10 Jan 2017 16:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Cg6FaJM2XVl5 for <cfrg@ietfa.amsl.com>; Tue, 10 Jan 2017 16:22:25 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1827D129880 for <cfrg@irtf.org>; Tue, 10 Jan 2017 16:22:25 -0800 (PST)
Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id AF05C10224058 for <cfrg@irtf.org>; Tue, 10 Jan 2017 16:22:24 -0800 (PST)
To: cfrg@irtf.org
References: <em85e6ab2a-6a3c-4b2e-986d-2e44c2965663@sgueron-mobl3>
From: Dan Harkins <dharkins@lounge.org>
Message-ID: <8ea394a8-1823-cdcf-4b4b-d313cf16b38f@lounge.org>
Date: Tue, 10 Jan 2017 16:22:23 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <em85e6ab2a-6a3c-4b2e-986d-2e44c2965663@sgueron-mobl3>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/IMVLbb4Nd6RH9dB8S_SPFHqPSTk>
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: Wed, 11 Jan 2017 00:22:26 -0000

   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