[CFRG] Re: [hpke] Re: [EXTERNAL] [lamps] Re: Re: Cross-testing update on LAMPS Composite and cfrg-concrete-hybrid-kems

[Sophie Schmieg <[e-mail]>]

As far as I know, HPKE does not even define a private key format (or a
public key format, for that matter), it just points to the standard formats
for those key types.
The HKDF labeled extract parts etc are parts of the KEM that is defined in
HPKE, ECDH by itself is not a KEM. It is absolutely necessary to have a KEM
in a kem combiner :)

But I think while I was typing this, Filippo has found the cause of the
confusion.

On Tue, Oct 21, 2025 at 3:41 PM Mike Ounsworth <[e-mail]>
wrote:

> Watson,
>
> Responding to this email.
>
> > OpenSSL supports HPKE.
>
> Right. And this is kinda my point. OpenSSL supports all sorts of
> X.509-specific encodings too. Why is it ok to take an HPKE-specific private
> key format and make that RECOMMENDED in a CFRG document -- implying that
> all other protocols implementers would need to implement the bits of the
> HPKE protocol necessary to support this private key format -- yet if I
> proposed a CFRG doc that normatively used some ASN.1-based private key
> format, people would SCREAM AT ME. All that LabeledExtract() stuff is
> absolutely "HPKE protocol implementation" that does not exist in any other
> protocol.
>
> My point is this: ECDH is a thing that has existed for decades, is well
> standardized, and well-supported in libraries. I consider it harmful to
> start mandating new, FIPS-non-compliant, key derivation functions for it at
> this point in its history.
>
> On Tue, 21 Oct 2025 at 15:07, Watson Ladd <[e-mail]> wrote:
>
>> On Tue, Oct 21, 2025 at 12:36 PM Mike Ounsworth
>> <[e-mail]> wrote:
>> >
>> > > I don't understand: HKDF (or the underlying hash function worst case)
>> absolutely does exist in current cryptographic libraries. If the argument
>> is that a private key generated one way won't work when moved to a
>> different system, that's a slightly different matter.
>> >
>> > Hi Watson,
>> >
>> > I could just replace some words there and make a pro-ASN.1 argument by
>> saying that byte string parsers exist in all languages, so why is everyone
>> so afraid to strip off an OCTET STRING.
>> >
>> > #1: interop and compatibility.
>> > The goal of the LAMPS - CFRG cross-testing was to see if the two things
>> we have defined are in fact the same thing. We have failed to do that
>> because we have not thus far been able to read each other's private keys.
>> The core issue is (in my opinion) because the CFRG doc uses what I will
>> call an HPKE-specific private key format that I don't have easy access to
>> an implementation for. From my perspective, that's an HPKE-specific thing
>> that doesn't belong in a CFRG doc any more than ASN.1 would.
>> >
>> > #2 security:
>> > The overarching mantra of cryptography is "Don't roll your own
>> primitives, use a library", and here we have a CRFC document which is
>> giving general cryptographic guidance, not scoped to the HPKE protocol,
>> that requires implementing your own private key derivation function that we
>> know is not well supported by crypto libraries. I don't think that is in
>> fact good sound guidance. I think "If you have an existing hardened
>> side-channel-resistant library that does EC, then just use that" is in fact
>> better guidance. I get that CFRG publishes many things that are novel
>> cryptographic primitives where that guidance doesn't apply, but ECDH is not
>> novel cryptography, why are we making it novel, and is all that headache
>> really worth the marginal security gains from using seeds?
>>
>> OpenSSL supports HPKE.
>>
>> OpenSSL supports setting the private key to a bignum ( by setting
>> "priv" (OSSL_PKEY_PARAM_PRIV_KEY) <unsigned integer>) in key
>> generation. OpenSSL I think implements constant time number
>> comparisons (although the interface is baroque and there have been
>> issues before). Certainly s2n is.
>>
>> Why exactly is this "rolling your own primitive" and implementing the
>> hybrid at all not? Is there a reason that library authors wouldn't be
>> implementing these? I'm not sure this argument is coherent, although
>> there's one you could be making that we want to use existing libraries
>> or hardware modules that only generate keys internally and can't
>> import private keys.
>>
>> >
>> > ---
>> >
>> > Mike Ounsworth
>> >
>> >
>> >
>> > ________________________________
>> > From: Watson Ladd <[e-mail]>
>> > Sent: Tuesday, October 21, 2025 2:23 PM
>> > To: Mike Ounsworth <[e-mail]>
>> > Cc: Tushar Patel <[e-mail]>; Filippo Valsorda <
>> [e-mail]>; CFRG <[e-mail]>; [e-mail] <
>> [e-mail]>; LAMPS WG <[e-mail]>
>> > Subject: [EXTERNAL] [lamps] Re: [CFRG] Re: Cross-testing update on
>> LAMPS Composite and cfrg-concrete-hybrid-kems
>> >
>> > On Tue, Oct 21, 2025 at 12: 14 PM Mike Ounsworth <ounsworth+ietf@
>> gmail. com> wrote: > > Follow-up: I see that DHKEM. DeriveKeyPair(ikm) is
>> defined in RFC9180: > https: //urldefense. com/v3/__https: //datatracker.
>> ietf.
>> org/doc/html/rfc9180*derive-key-pair__;Iw!!FJ-Y8qCqXTj2!YZhxRq-M6f_HcCCo4UQwQL5yYgX-wB80VLdUBwT4kjVcB1kFr4Q-3qvwqDoxc0sd9b0S4uQDAW4gzWiIEJVI_sRPPS7QFdI$
>> >
>> > On Tue, Oct 21, 2025 at 12:14 PM Mike Ounsworth
>> > <[e-mail]> wrote:
>> > >
>> > > Follow-up: I see that DHKEM.DeriveKeyPair(ikm) is defined in RFC9180:
>> > >
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9180*derive-key-pair__;Iw!!FJ-Y8qCqXTj2!YZhxRq-M6f_HcCCo4UQwQL5yYgX-wB80VLdUBwT4kjVcB1kFr4Q-3qvwqDoxc0sd9b0S4uQDAW4gzWiIEJVI_sRPPS7QFdI$
>> > >
>> > > That makes liberal use of HPKE's LabelledExtract(), which fully
>> explains why this is not compatible with the python API.
>> > >
>> > > That means that a seed-based key derivation is defined for P-256,
>> P-384, and P-521, but only within the confines of the DHKEM primitive
>> within the HPKE protocol. It is still the case that a seed-based key
>> derivation is not defined for ECDH in general.
>> > >
>> > > So, on that grounds, I object to draft-irtf-cfrg-concrete-hybrid-kems
>> RECOMMENDING a seed-based priv on exactly the same grounds that anyone else
>> would object to it RECOMMENDING an ASN.1 based encoding: this is a CFRG
>> document that normatively depends on a building block that only exists in
>> one single IETF protocol, and most importantly to me, does not exist in
>> FIPS or current cryptographic libraries.
>> >
>> > I don't understand: HKDF (or the underlying hash function worst case)
>> > absolutely does exist in current cryptographic libraries. If the
>> > argument is that a private key generated one way won't work when moved
>> > to a different system, that's a slightly different matter.
>> >
>> > >
>> > > On Tue, 21 Oct 2025 at 13:34, Mike Ounsworth <
>> [e-mail]> wrote:
>> > >>
>> > >> Hi CFRG and HPKE,
>> > >>
>> > >> I just want to give an update on this. Richard and I did some more
>> cross-testing this week, and we are at an impasse on the SEC-P curves, and
>> it has to do with the seeds. The CFRG /HPKE draft stores the hybrid private
>> keys as a seed, so you have to re-derive the P256 half from a seed. My
>> problem is that ECDH is a thing that has been standardized for like 20
>> years in [SEC1] and [SP.800-56A], and those two documents do not specify or
>> allow a seed-based EC keygen, and as a consequence, many crypto libraries
>> don't support a seed-based EC keygen API. For example, I'm doing my
>> reference implementation for Composites on top of the core python
>> cryptography library, and I cannot implement the CRFG / HPKE draft that
>> way. Python crypto has this:
>> > >>
>> https://urldefense.com/v3/__https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/*cryptography.hazmat.primitives.asymmetric.ec.derive_private_key__;Iw!!FJ-Y8qCqXTj2!YZhxRq-M6f_HcCCo4UQwQL5yYgX-wB80VLdUBwT4kjVcB1kFr4Q-3qvwqDoxc0sd9b0S4uQDAW4gzWiIEJVI_sRPBePJyjM$
>> > >> but that appears to not derive the same keys as Richard's
>> implementation.
>> > >>
>> > >> The issue is that EC.derive_priv_from_seed() is not a standardized
>> function. You can probably infer from a careful read of [SEC1] or
>> [SP.800-56A] what it needs to be, but it is not actually standardized or
>> FIPS-allowed. It requires mucking around with EC point multiplication. The
>> fact that it's not a standardized thing means that I will likely not be the
>> last person to have interop problems with this. Maybe my issues are as
>> simple as not using that python ec.derive_private_key() properly, maybe his
>> scalar is 'big' rather than 'little' or something. If that's the case, I'd
>> be happy -- but this is the kind of mess you get into when you use
>> non-standardized APIs for existing 20 year-old primitives.
>> > >>
>> > >> So at this point, I think we have to declare non-compatibility
>> between LAMPS and HPKE Hybrid KEMs. Since our X-Wings are compatible, we
>> know that our QSF frameworks are identical, so in principle our P256's
>> should work too, but we're been incapable of testing it because this
>> off-spec seed stuff is getting in the way.
>> > >>
>> > >> On Thu, 16 Oct 2025 at 17:40, Tushar Patel <[e-mail]>
>> wrote:
>> > >>>
>> > >>> Sorry, jumping in a running train and
>> > >>> many years ago while working through JSON bindings for the tests, I
>> ran into a sign bit conversion error on big numbers and had to rewrite part
>> of the library, the fixed code is with a previous employer, 64-bit and
>> 128-bit in JSON libs are a mess or sign bit issues in general.
>> > >>>
>> > >>> Also, please make sure that you are parsing the compressed
>> notations for ECC correctly, some libraries pack those incorrectly and also
>> wrote my own ASN.1 parsers for some elements, you might be surprised where
>> I hit these areas, can’t disclose, though both were from reputed
>> organizations.
>> > >>>
>> > >>> Last, please make sure you have matching generators and incorporate
>> the affine and infinity checks, these may translate to all sorts of weird
>> issues that are impossible to debug through OSS macros in most cases.
>> > >>>
>> > >>> There is substandard ECC, ECDSA and ECDHE at many places in OSS
>> libs and you may have to debug these.
>> > >>>
>> > >>> Personally, I think NIST should mandate pristine implementations as
>> companies spend a lot more time fixing other implementations than their own.
>> > >>>
>> > >>> Hope it’s Useful,
>> > >>> Tushar
>> > >>>
>> > >>> On Thu, Oct 16, 2025 at 8:45 AM Mike Ounsworth <
>> [e-mail]> wrote:
>> > >>>>
>> > >>>> Thanks Filippo,
>> > >>>>
>> > >>>> Richard and I did some debugging last night. He gave me new test
>> vectors that include that bug fix to the P256 / P384 constants.
>> > >>>>
>> > >>>> My current theory is that the code I quickly whipped up to do a
>> P256 private key expansion from seed does not match Richard's. Since this
>> is wholly out of scope for LAMPS Composite (we store the full P256 private
>> key), I'm hoping that Richard can give me a dump of intermediate values
>> that includes the expanded P256 / P384 private key so that we don't need to
>> debug through the P256-from-seed stuff. Anyway, this is all good validation
>> of both our test vectors.
>> > >>>>
>> > >>>> Anyway, making progress!
>> > >>>>
>> > >>>> On Thu, 16 Oct 2025 at 10:29, Filippo Valsorda <
>> [e-mail]> wrote:
>> > >>>>>
>> > >>>>> 2025-10-16 03:55 GMT+02:00 Mike Ounsworth <
>> [e-mail]>:
>> > >>>>>
>> > >>>>> Results: we are cross-compatible on X-Wing, but not on P256 (and
>> that's after hacking my script to use the CFRG label not the LAMPS label,
>> so there's clearly some other bug at play, but I have no idea what, so of
>> course I assume it's on the cfrg reference impl side 😋).
>> > >>>>>
>> > >>>>>
>> > >>>>> Could be
>> https://urldefense.com/v3/__https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/21__;!!FJ-Y8qCqXTj2!YZhxRq-M6f_HcCCo4UQwQL5yYgX-wB80VLdUBwT4kjVcB1kFr4Q-3qvwqDoxc0sd9b0S4uQDAW4gzWiIEJVI_sRP6B8fHsg$
>> .
>> > >>>>
>> > >>>> _______________________________________________
>> > >>>> CFRG mailing list -- [e-mail]
>> > >>>> To unsubscribe send an email to [e-mail]
>> > >
>> > > _______________________________________________
>> > > Spasm mailing list -- [e-mail]
>> > > To unsubscribe send an email to [e-mail]
>> >
>> >
>> >
>> > --
>> > Astra mortemque praestare gradatim
>> >
>> > _______________________________________________
>> > Spasm mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>> >
>> > Any email and files/attachments transmitted with it are intended solely
>> for the use of the individual or entity to whom they are addressed. If this
>> message has been sent to you in error, you must not copy, distribute or
>> disclose of the information it contains. Please notify Entrust immediately
>> and delete the message from your system.
>> >
>>
>>
>> --
>> Astra mortemque praestare gradatim
>>
> _______________________________________________
> hpke mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]