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

Richard Barnes <rlb@ipv.sx> Tue, 03 November 2020 15:33 UTC

Return-Path: <rlb@ipv.sx>
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 DFC5A3A0AA6 for <cfrg@ietfa.amsl.com>; Tue, 3 Nov 2020 07:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.20150623.gappssmtp.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 ytE85xc94frU for <cfrg@ietfa.amsl.com>; Tue, 3 Nov 2020 07:33:05 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 E9EB73A0141 for <cfrg@irtf.org>; Tue, 3 Nov 2020 07:33:04 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id j31so5132057qtb.8 for <cfrg@irtf.org>; Tue, 03 Nov 2020 07:33:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iw3Gc4J2dSLDKw++6ZemNewizo97VJX7OgtswsGZRHI=; b=lg9EfR3UHBthZX2QV+0X9wIQmXd2nrm2OTX/zDZ8mmiteBvc0CwBSBYH1UqU66fLB7 DLmmuHY+4hBTPDqz26OFW6pfmRdQFVE65X2DF5KOl3oncoV7O5BlTlC5Qy5LIqM9spl1 otfrlsLJ+kZnMr/HHttuyNKWYYGYelrC9deQ41bm1fGUABkm4o88In7P3ZDw6p+3/eq1 yO2/ksVo55pdtfgTrjmpD9UNm8sK8Xhu4JhLlj6S+HtUMYImqFB+vQXiNFBYVEqfcbg5 KWr3W5RReK65+G0icZA+aqDPSAbl5You0kVkRhct73PzHo0kmfU+XZ3o5HEuQNVcck8D lcEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iw3Gc4J2dSLDKw++6ZemNewizo97VJX7OgtswsGZRHI=; b=QJGWCTNSMaP0h0ft5iHAvBEh/hgq4Pq2Kv2wgWdwlM8eZxIACQ0q9jlprZhIMXUMI0 pSarRjt7RLiRqOEFidhPo5DO4KMApSO/ovwUvACGQHSKofrd8e2rZMM9/+QhqtLZZ0tk 6XE/B/hTEn0i52KBUEgtc585urYEa+6NrxrFPx1e4fj2QyVarFccy49cvY/R6EPSxn99 qnw0gGKcsgFPIxtbPVjCYkrVycZ0W0KZDtU3i5TBocYRqHDAldjDGL10GwcEE9a/QlQ2 89Nl39YpI4SN0aawdOFK0eKVxb9qcPGGmLkECqfQKMmibhEDTdNmqOF+ioe/GUL8drpw zooA==
X-Gm-Message-State: AOAM530zOzP+ab7bEUrjUedbUo/L3yLKMBztk+pEOAHkq71goNt3r3g2 rvvvrv/TP1xKxdysDwmQCKQ83bTeb1H1jt4HrkrywQ==
X-Google-Smtp-Source: ABdhPJyXlRSPTCBIX2RfNwdGaht/Da+WQCpBSEvnIpRUIhQLfRsh8ShrApqJ3mzWaV8D+C567nIfVTb9uMq7jialRd0=
X-Received: by 2002:ac8:41d4:: with SMTP id o20mr8170392qtm.313.1604417583490; Tue, 03 Nov 2020 07:33:03 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <64413716-205a-49b0-8438-3c473d7e6707@www.fastmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 3 Nov 2020 10:32:44 -0500
Message-ID: <CAL02cgQHjE8e8VcPs_jiQaQBSqNba7K9=xTzSaDnHHmn=L=xsA@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000022bb1505b335945f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/_NLUbHW3MSfYMgO0BomZ7pLiV3Y>
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 15:33:07 -0000

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.

--Richard



> Best,
> Chris
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>