MIME-Version: 1.0
References: <528f96b5-b342-407a-b5f7-2e8afc16f1b8@mtg.de>
 <2907C129-93F1-4D66-B741-4FC85ED1DF9F@nohats.ca>
In-Reply-To: <2907C129-93F1-4D66-B741-4FC85ED1DF9F@nohats.ca>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 14 Sep 2024 12:26:31 -0400
Message-ID: 
 <CAMm+Lwj1+O1whL1Xf_ZypD9t8rQ5TAmG9Z4O9V3VWFk=dN7VGA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="00000000000018f233062216ce38"
Message-ID-Hash: NY6BTTUWUJOBQMT2GEK4NSU2Y5GP6HGO
CC: Falko Strenzke <falko.strenzke@mtg.de>, openpgp@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bopenpgp=5D_Re=3A_WG=3A_BSI_view_on_KEM_combiners?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/LfycDin-LlOjnTTM463ejTEpIsc>

--00000000000018f233062216ce38
Content-Type: text/plain; charset="UTF-8"

I have read this thread several times and find very little direct technical
content or citations I can follow to descriptions of that content. The KEM
combiners mailing list seems to have very little discussion of what was
discussed on their calls.

What is it about combining KEM and ECC outputs that is supposed to be so
difficult that HKDF does not already address it? Sure, we have to make sure
that we achieve domain separation in signatures. But in the encryption
domain, either the output can be used to decrypt/authenticate or it cannot.

I am rather skeptical of any company being bought into any particular
approach to PDC at this point in time that a technical choice between
combiners would cost 'millions of dollars' unless a patent were at issue.
Come to that, the notion that BSI has come to a firm conclusion AGAINST a
particular approach and does not have a concise rationale seems unlikely.

We have an IETF combiner function for KEM and ECC, it is called HKDF and if
there is a reason not to use HKDF (KEM + ECC) then we should be fixing HKDF.

--00000000000018f233062216ce38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">I h=
ave read this thread several times and find very little direct technical co=
ntent or citations I can follow to descriptions=C2=A0of that content. The K=
EM combiners mailing list seems to have very little discussion of what was =
discussed on their calls.</div><div class=3D"gmail_default" style=3D"font-s=
ize:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small"=
>What is it about combining KEM and ECC outputs that is supposed to be so d=
ifficult that HKDF does not already address it? Sure, we have to make sure =
that we achieve domain separation=C2=A0in signatures. But in the encryption=
 domain, either the output can be used to decrypt/authenticate or it cannot=
.</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><di=
v class=3D"gmail_default" style=3D"font-size:small">I am rather skeptical o=
f any company being bought into any particular approach to PDC at this poin=
t in time that a technical choice between combiners would cost &#39;million=
s of dollars&#39; unless a patent were at issue. Come to that, the notion t=
hat BSI has come to a firm conclusion AGAINST a particular approach and doe=
s not have a concise rationale seems unlikely.</div><div class=3D"gmail_def=
ault" style=3D"font-size:small"><br></div><div class=3D"gmail_default" styl=
e=3D"font-size:small">We have an IETF combiner function for KEM and ECC, it=
 is called HKDF and if there is a reason not to use HKDF (KEM=C2=A0+ ECC) t=
hen we should be fixing HKDF.</div><div class=3D"gmail_default" style=3D"fo=
nt-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sm=
all"><br></div><div class=3D"gmail_default" style=3D"font-size:small"><br><=
/div></div>

--00000000000018f233062216ce38--