Re: [CFRG] [Cfrg] I-D Action: draft-irtf-cfrg-hpke-06.txt

Christopher Wood <caw@heapingbits.net> Tue, 03 November 2020 17:57 UTC

Return-Path: <caw@heapingbits.net>
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 5D6053A0EB5 for <cfrg@ietfa.amsl.com>; Tue, 3 Nov 2020 09:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=ypuY4WY7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OhhC8gCm
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 yNyph30krV0y for <cfrg@ietfa.amsl.com>; Tue, 3 Nov 2020 09:57:12 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6453A0EB3 for <cfrg@irtf.org>; Tue, 3 Nov 2020 09:57:12 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 3ECAEE20; Tue, 3 Nov 2020 12:57:11 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Tue, 03 Nov 2020 12:57:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=GQh5szU1f08SZBiD6qUPQt/JN8RH DW3RurVhLRulKV0=; b=ypuY4WY7ec4oZQTjD1Qx24Xx4BEAdV2ZG2NO0SUDBe3I BKU8s9hBdLCL0iGlfM0Lc0kgKBLS76+tmAV94Mj+ZUjVh7LZBPi9kaBmWqgNHrmX 65s+720bHbsyVhMef1GSr6PMYo6XCUBblpjM/j1Z3+qjlwbWFo2KZlOBj95CPLyy ahfy8C4toX/mAb0rpOLAdtJPCthn8VTHL0MIE3vM2HdzYtG+RT21wW365v0v2Lmo UFmoFIZoyjuOt1NCQQSLlPdzFJnmSzzaSGMWksZuWftGd0FT6cseAFXOgHERPrp2 gZpU8l6L0VLVBm11K/BNQK8ebz34myvYFAE4UdjTDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=GQh5sz U1f08SZBiD6qUPQt/JN8RHDW3RurVhLRulKV0=; b=OhhC8gCmU6KTIiOP1vrEh/ W6ALXQcpfZaIj5HeFSc+JS0AfDj+Esm736cirELjaq5o81cHwoiEQdQ63gpO0/rW ku+PJUF1Ygu+ov5dBASR09crhq8NsKY6W8PeS8Dd2Ae9KHKPeB8GYPPA4B2uZ4Gq 4xzuGICMxt4yGcKH1QCm1Xi/bJs/bLzthsLvxFIL7g0YYo+XmCGHeezZtO3xHeoE 4HjiANsCtWYTMBDroUImSaVIAcdt7NYRDGkcE8KHhINp9KaGAYzajqSLPUC4O0y+ /2vasttnrn+T2W+2mj+FZwI/Ct9Q6yCxEo9AooXLp6vog65Ij5FUtEqD7x17ydkw ==
X-ME-Sender: <xms:9pmhXyUiDjlFIKcUc1rrz_UOBpDmbykbYBqfDC8ILnzR013Jp00cRw> <xme:9pmhX-njw9XkeR3prcK73IJVIcAeRtK4K872F5ncTa1OOQeLzILynB_InSF3Sp4Z4 Xwr9WwomNUEoVC8iF0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtfedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepudffiedtud dttefggeefkeegvdekledvieeitdejteetuedvjeevleelleettdehnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhngh gsihhtshdrnhgvth
X-ME-Proxy: <xmx:9pmhX2a4VyNV1g_dueIFVuM7q2HzEpdeD8qh5RlTcBb78nW4xDtVJw> <xmx:9pmhX5WT8JL-lPBnaHCOpRphswV9glai4BKvM4VK-EV2IgYSN0WeWw> <xmx:9pmhX8l4pjSFrHGvaGAUAQYufmWXNPdCVD2WF0fpsfbnu-0AtI-rEg> <xmx:9pmhX-RKP1BTz3W0QYeIqIn6cuDwBulgTptoJv9M3USHjMiiCSVhug>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4A3043C00BA; Tue, 3 Nov 2020 12:57:10 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35
Mime-Version: 1.0
Message-Id: <71bf0346-b69f-40a8-b54f-a12458f70991@www.fastmail.com>
In-Reply-To: <CAL02cgQHjE8e8VcPs_jiQaQBSqNba7K9=xTzSaDnHHmn=L=xsA@mail.gmail.com>
References: <CAGiyFdejssUBrs3wmQL7QVKS_YkAr4aoOjow9wOgPHfcsPv+UA@mail.gmail.com> <SJ0PR09MB684891C13A558A4E53E9DD84F3190@SJ0PR09MB6848.namprd09.prod.outlook.com> <CAG2Zi214vikhdR4wa=0M6Yiyw0NTeHygKqTtwT_h=r1OR+WthQ@mail.gmail.com> <7eac427e-3746-4ebf-aea7-f2bdf2fec26c@www.fastmail.com> <64413716-205a-49b0-8438-3c473d7e6707@www.fastmail.com> <CAL02cgQHjE8e8VcPs_jiQaQBSqNba7K9=xTzSaDnHHmn=L=xsA@mail.gmail.com>
Date: Tue, 03 Nov 2020 09:56:49 -0800
From: "Christopher Wood" <caw@heapingbits.net>
To: "Richard Barnes" <rlb@ipv.sx>
Cc: CFRG <cfrg@irtf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0GptSlQ-gX2bu4s8pNLaZvBLnAM>
Subject: Re: [CFRG] [Cfrg] I-D Action: draft-irtf-cfrg-hpke-06.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Tue, 03 Nov 2020 17:57:14 -0000

On Tue, Nov 3, 2020, at 7:32 AM, Richard Barnes wrote:
> Hi Chris,
> 
> I agree with your analysis here, but a couple of refinements/extensions 
> inline below...
> 
> On Tue, Nov 3, 2020 at 10:08 AM Christopher Wood <caw@heapingbits.net> wrote:
> > On Wed, Oct 28, 2020, at 4:21 PM, Christopher Wood wrote:
> > > On Mon, Oct 26, 2020, at 10:04 AM, Christopher Patton wrote:
> > > > Hi all,
> > > > 
> > > > I agree that we shouldn't discourage adoption of alternatives to HKDF. 
> > > > However, I don't think the spec does so: it merely requires adherence 
> > > > to the Extract-then-Expand API. There should be ways to securely "wrap" 
> > > > alternatives into Extract-then-Expand API providers, perhaps at the 
> > > > cost of CPU cycles. (E.g., how Noise uses Blake2b as pointed out above.)
> > > 
> > > +1.
> > > 
> > > The two-step Extract-then-Expand split does not rule out other KDFs and 
> > > allows best use of HKDF out of the box. Consequently, I don't think the 
> > > HPKE specification should change at this point.
> > 
> > To be more concrete, if desired, one could wrap HKDF as follows:
> > 
> >   Extract(salt, ikm): HKDF(secret=ikm, salt=salt, info="", length=Nh)
> >   Expand(prk, info, L): HKDF(secret=prk, salt="", info=info, length=L)
> 
> One could do that, but it would be kind of silly, when the whole point 
> of the extract/expand API is that it maps well to two-step KDFs.  
> Rather, I think the point here is that in addition to HKDF, you could 
> fit other two-step KDFs into this API, such as the one defined for KMAC 
> in NIST SP 800-56C.
>  
> > Similarly, I think one could wrap BLAKE3 as follows:
> > 
> >   Extract(salt, ikm): derive_key(context=salt, key_material=ikm), and output Nh bytes
> >   Expand(prk, info, L): derive_key(context=info, key_material=prk), and output L bytes
> 
> Since I have 800-56C open, I would note that the two-step construction 
> there uses a MAC for extract and a KDF for expand, so you could also do 
> an integration of that form:
> 
> Extract(salt, ikm) = BLAKE3.MAC(salt, ikm)
> Expand(prk, info, L) = BLAKE3.KDF(prk, info, L)
> 
> In any case, it seems clear that if you have a two-step KDF, you can 
> probably map it into the extract/expand API, and if you have a one-step 
> KDF, you can just invoke it twice if there's not a more elegant option.

Yep! I oversimplified for effect, but your explanation is much more clear. 

Best,
Chris