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

[Mike Ounsworth <[e-mail]>]

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
>