Return-Path: <rswatjfet.org@gmail.com>
X-Original-To: cfrg@mail2.ietf.org
Delivered-To: cfrg@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1])
	by mail2.ietf.org (Postfix) with ESMTP id 7454C86BE12
	for <cfrg@mail2.ietf.org>; Thu,  6 Mar 2025 11:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level: 
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5
	tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001,
	FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001,
	RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=0.001,
	RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
	RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001,
	SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31])
	by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0BvX89PwBwES for <cfrg@mail2.ietf.org>;
	Thu,  6 Mar 2025 11:48:04 -0800 (PST)
Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com
 [209.85.219.41])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(No client certificate requested)
	by mail2.ietf.org (Postfix) with ESMTPS id B132286BE07
	for <cfrg@irtf.org>; Thu,  6 Mar 2025 11:48:04 -0800 (PST)
Received: by mail-qv1-f41.google.com with SMTP id
 6a1803df08f44-6e8f6970326so8073796d6.0
        for <cfrg@irtf.org>; Thu, 06 Mar 2025 11:48:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741290484; x=1741895284;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=A7KW8U0dk5N4pqV7i04w9lNuyY+D+Dm7NOlCfQ69vd8=;
        b=colvwjNKxEOdHIZq0wyj+2XgJ7mJnD+cl2OxStrUD+tJifhBjpnEcn4YvD7pcpf4lF
         idjZW8AKZU8zukZrBgWt0BDMWDP63RcXkY8IFJNrdVmh3kIIVClqcfHw563HnDK8lVx4
         x/DCtRlOMn/hBSueNhe19GTws0OFrbKXZL0945IOI55gx5q2RhRtY8hTHevUbQZwKYSY
         raNE/yekJyH6mNEh7dn6Uzg97kZIy6RyMferMTwZvDutnd2r5dtPUtpVqVsxp5E+0tbs
         1Vt//t+BwqSNIn5ibU9AU5s4K3q46Ay/rD9D5A2nPhBb8N+A0/m6ZyTSDGMJ5xFPD+Q9
         UvVA==
X-Gm-Message-State: AOJu0Yyghi8JGYpeeR1O7KgPe+6J8kpYZ6JBFdQQCts1gAV4xxeyVxQf
	zW2DFGPlaHoyR1T07+xB2iNpM3fU/wyxwhFGBmUSuYuzPcf3msmkuXcMLg==
X-Gm-Gg: ASbGncsCayqlALJI6FHK6umc1Pz6sQcPyYF87NTGuW2DA9JaYm3GAHaLCZHS/XwX+j+
	yT/tLk6VJ/XzhHzdSZx/ZwN8WPHWE0go/btFPBE8QJ99mdqhDeuPqVPk+eSWMNpoqCy44dTpPIh
	roqWcigOLLvFPJSVbQI+U90Y0OQHXehjK/W3AXUGWsdiznN5NzQIiPBT1DeDFHHjvFUo3oZGzD8
	Ew64zG6FfbXrqDadNzp+0z8ge/hIIr4LChSvzIJ9lLIBL7GqyNm+17fBRi4RhxoQFEuh4Oo5pm7
	QQh1jlVseI7SuA82KymbpE6GRRvhd3f2iHCIGp+mw7wizJJ+3eXVwgGbfnvsxNYcL2b2qFH56OS
	vXK9mrQXFJYDWQno9
X-Google-Smtp-Source: 
 AGHT+IFCbV7+UHek/UDr9SDv/K6wzL3cSovK6MeYuEpmSSsXXnqNY/MGWJYbrN1r/m7Lhzl8UfZ0Og==
X-Received: by 2002:ad4:5d49:0:b0:6e8:fbb7:6764 with SMTP id
 6a1803df08f44-6e9006ba2fbmr4404666d6.45.1741290484081;
        Thu, 06 Mar 2025 11:48:04 -0800 (PST)
Received: from localhost (pool-74-109-196-203.pitbpa.fios.verizon.net.
 [74.109.196.203])
        by smtp.gmail.com with UTF8SMTPSA id
 6a1803df08f44-6e8f715b718sm10351126d6.91.2025.03.06.11.48.02
        for <cfrg@irtf.org>
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Thu, 06 Mar 2025 11:48:03 -0800 (PST)
Date: Thu, 6 Mar 2025 14:48:02 -0500
From: "Riad S. Wahby" <rsw@jfet.org>
To: cfrg@irtf.org
Message-ID: <ewavpsoh77jpkw3lnngmyq2w52rlnj6rjvbo32bwnmskzev2xv@kf2pf5kqia5f>
References: 
 <174104647991.518397.15722864021260778275@dt-datatracker-5dd67b77bb-4k4zh>
 <CAFR824wzxpHE6Vqb2zJqSCE6ZMN4JT8CTjW9Yj4wbkeki5idfQ@mail.gmail.com>
 <600a2260-e564-4540-af9f-9632fba7bced@posteo.de>
 <CAEEbLAaBx2gh1wTwsm_JwFX=bF9DyGQO7hPv=sFMpS=khmfLiA@mail.gmail.com>
 <CAEEbLAYYAGeF-tGVG3z3d9aCHgoWmHZ5bbM3seUFC4BQVPvovQ@mail.gmail.com>
 <9805e12b-f77a-44f8-9fe5-e15287b2008d@posteo.de>
 <Z8iM2zhhspgWIKOg@LK-Perkele-VII2.locald>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Z8iM2zhhspgWIKOg@LK-Perkele-VII2.locald>
Message-ID-Hash: ZCCZDWGI3RF7Z5VZ337QLE7IBRIVCDYT
X-Message-ID-Hash: ZCCZDWGI3RF7Z5VZ337QLE7IBRIVCDYT
X-MailFrom: rswatjfet.org@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_SHA-3_for_HPKE?=
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/cfrg/Eco4764dW7CoMZClp0zsSobMzts>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> Furthermore, that sounds like something that would cause major issues
> with existing implementations.

Agreed.

It seems like the reasonable options are either to use HKDF with SHA3
(which is perfectly fine; HMAC works just fine with sponges, even if it's
not necessary) or to first define an extract-and-expand abstraction that
is tailored to SHA3 (or, even better, tailored to sponges generally) and
then use that.

In the latter case, it would be best for the extract-and-expand construction
to be explicit and accompanied by a clear analysis (along the lines of what's
provided for HKDF). An ad-hoc construction that lacks this analysis probably
shouldn't be recommended for use. It would also be great if this analysis
weren't just "sponges look like random oracles, so this is OK". Because one
of the nice things about HKDF is that we are able to avoid jumping to the
strongest possible model of the hash function and still get a useful result.

All of this is to say: it's a heck of a lot less work to rely on HKDF.
So if the complaint is a few extraneous invocations of the hash function,
it seems to me like the work (of writing, reviewing, revising, etc.) isn't
so easy to justify.

That said, I would be happy to see such an analysis published, and would
certainly read it :)

Cheers,

-=rsw

