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

[Tushar Patel <[e-mail]>]

Hi Mike

Small typo, should be KASVS ( AI…), anyway ECDHE relates the KEM as ECDH
would be the weakest security point and in case for static we are back to
ECDSA with the seed.

A simple hybrid KEM would be a reduction of two independent schemes for
version 1 and later we could extend it in case you can prove the security
of a KAS on one side ECDH, however, even with P-521, I don’t think we can
get an ECDH method even on one side to be Quantum safe.

This is not to make the task difficult. just take a look at the IANA cipher
lists first IPsec and TLS and we get the overload with ECDH or DH in
general, the ephemeral methods could be used somewhat safely, however, does
need expert methods to be Quantum superimposition safe.

On Tue, Oct 21, 2025 at 6:43 PM Tushar Patel <[e-mail]> wrote:

> Hi Mike
>
> I know, the issue is that you will have to use ECDHE and not ECDH, if you
> use ECDH, you can get by using associated ECIES, otherwise I am not sure
> that any approved KAS without an associated ECDHE is permitted. Please
> refer to SP 800-56 and 57 and the KASCVS for currently approved methods.
>
> On Tue, Oct 21, 2025 at 3:08 PM Mike Ounsworth <[e-mail]>
> wrote:
>
>> Hi Tushar.
>>
>> We are talking about ECDH, not ECIES.
>>
>> In the case of PKI, we're talking about draft-ietf-lamps-pq-composite-kem
>> which combines ECDH with ML-KEM to produce a hybrid KEM.
>>
>> In the case of HPKE, we're talking about
>> draft-irtf-cfrg-concrete-hybrid-kems which does the same thing on top of
>> the DHKEM primitive defined in RFC9180.
>>
>> Both protocols need ECDH to be in the shape of a KEM not an IES because
>> the protocol already handles content encryption at a different layer
>>
>> ---
>> Mike Ounsworth
>> ------------------------------
>> *From:* Tushar Patel <[e-mail]>
>> *Sent:* Tuesday, October 21, 2025 4:41:04 PM
>> *To:* Watson Ladd <[e-mail]>
>> *Cc:* Mike Ounsworth <[e-mail]>; Mike Ounsworth <
>> [e-mail]>; Filippo Valsorda <[e-mail]>;
>> CFRG <[e-mail]>; [e-mail] <[e-mail]>; LAMPS WG <
>> [e-mail]>
>> *Subject:* Re: [EXTERNAL] [lamps] Re: [CFRG] Re: Cross-testing update on
>> LAMPS Composite and cfrg-concrete-hybrid-kems
>>
>> There is ECIES. ECDH is not acceptable in most cases, on the other hand
>> ECDHE with single op is acceptable. Be careful because there are open
>> source libraries that would start off with the same key without single op
>> due to domain parameters
>> There is ECIES.
>>
>> ECDH is not acceptable in most cases, on the other hand ECDHE with single
>> op is acceptable. Be careful because there are open source libraries that
>> would start off with the same key without single op due to domain
>> parameters and ECDH will mostly face the key repetition.
>>
>> On Tue, Oct 21, 2025 at 1:07 PM 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
>>
>>