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
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Adam Langley
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Aaron Zauner
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Aaron Zauner
- Re: [Cfrg] AES-GCM-SIV security of the additional… Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV security of the additional… Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] AES-GCM-SIV security of the additional… Jim Schaad
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] AES-GCM-SIV security of the additional… Blumenthal, Uri - 0553 - MITLL
- [Cfrg] AES-GCM-SIV with a new key hierarchy Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV security of the additional… Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV security of the additional… Daniel Bleichenbacher
- Re: [Cfrg] AES-GCM-SIV security of the additional… Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Antonio Sanso
- Re: [Cfrg] AES-GCM-SIV security of the additional… Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Blumenthal, Uri - 0553 - MITLL
- [Cfrg] AES-GCM-SIV security of the additional data Daniel Bleichenbacher
- Re: [Cfrg] AES-GCM-SIV security of the additional… Daniel Bleichenbacher
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Dan Harkins
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Shay Gueron