IETF Logo Mail Archive

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

Loup Vaillant-David <loup@loup-vaillant.fr> Mon, 26 October 2020 16:19 UTC

Return-Path: <loup@loup-vaillant.fr>
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 8B5183A0CE1 for <cfrg@ietfa.amsl.com>; Mon, 26 Oct 2020 09:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 iSsb3pR8fKnf for <cfrg@ietfa.amsl.com>; Mon, 26 Oct 2020 09:19:10 -0700 (PDT)
Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3723A0CE0 for <cfrg@ietf.org>; Mon, 26 Oct 2020 09:19:09 -0700 (PDT)
X-Originating-IP: 82.254.246.40
Received: from grey-fade (lns-bzn-60-82-254-246-40.adsl.proxad.net [82.254.246.40]) (Authenticated sender: loup@loup-vaillant.fr) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 145DD20008; Mon, 26 Oct 2020 16:19:05 +0000 (UTC)
Message-ID: <4ac8b9bb3ca3ad8cbd8f7ee7dbbda7257639930c.camel@loup-vaillant.fr>
From: Loup Vaillant-David <loup@loup-vaillant.fr>
To: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>, cfrg@ietf.org
Date: Mon, 26 Oct 2020 17:19:05 +0100
In-Reply-To: <CAGiyFdejssUBrs3wmQL7QVKS_YkAr4aoOjow9wOgPHfcsPv+UA@mail.gmail.com>
References: <CAGiyFdejssUBrs3wmQL7QVKS_YkAr4aoOjow9wOgPHfcsPv+UA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/FKwnOG_-1svQu3mGJ-zsxcL6H88>
Subject: Re: [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: Mon, 26 Oct 2020 16:19:13 -0000

Hi,

> as commented in my review, and as discussed more recently with Ben
> Lipp, I just find that directly defining the KDR in terms
> extract/expand internal operations will prevent the adoption of other
> KDFs than HKDF.

I believe this is already happening here and there. The Noise protocol
for instance could have used a generic KDF block, but instead have
settled on HKDF, even when the underlying hash is Blake2b.

(Now JPA here obviously knows this, but for those who did not invent
Blake, Blake2b has a keyed mode that as far as I know is a fine KDF.)

Loup.

v2.23.0 | Report a Bug | By Email