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

[Deirdre Connolly <[e-mail]>]

> I'll also echo what Richard said. This is a domain separation scheme.
These are not names of primitives. They are not API names. They do not
appear on the wire. They are not specified by users of the primitive. They
do not appear in any user-facing systems at all. They're just random
constants internal to the primitive.

Yep

On Tue, Nov 4, 2025, 12:14 PM David Benjamin <[e-mail]> wrote:

> I am *strongly* opposed to changing the X25519 label. We should stick to
> the existing consensus. This has come up a few times before, with the same
> outcome. There are now several widespread deployments of this primitive.
> With the long, long history of trying to get these hybrids defined, it's
> long past the point that I'd be interested in shipping an incompatible
> variant of this now over-a-year-old, well-established, deployed,
> multi-implementor construction.
>
> Yes, this means hybrids overall are changing from consistent, short, if
> whimsical, labels to a mix of styles, but the poll was quite clear that one
> of the labels was always to remain the short one.
>
> I'll also echo what Richard said. This is a domain separation scheme.
> These are *not* names of primitives. They are *not* API names. They do
> *not* appear on the wire. They are *not* specified by users of the
> primitive. They do *not* appear in *any* user-facing systems *at all*.
> They're just random constants internal to the primitive. They are so
> invisible that I imagine most folks here do not even know the analogous
> values in other constructions. Here is a sampling of values I looked up.
>
> - HPKE concatenates a mix of ASCII strings and two-byte binary codepoints
> - TLS 1.3 key schedule uses short strings like "res binder" and "c e
> traffic", for efficiency
> - TLS 1.3 CertificateVerify uses 32 spaces (to work around a TLS 1.2
> issue), followed by strings like "TLS 1.3, server CertificateVerify"
> - TLS 1.2 used strings like "client finished"
> - SSL 3 used, variously, "A", "BB", "CCC", etc., and 0x434C4E54 ("CLNT")
> for the client and 0x53525652 ("SRVR") for the server
> - Certificate Transparency prepends one-byte prefixes 0x00 and 0x01
> - hash-to-curve just lets the caller pick the string, but oversized ones
> get a very abbreviated "H2C-OVERSIZE-DST-" before being hashed down
> - The TLS exporter label registry has a wide range of values from very
> long strings, to abbreviated strings, to an email address
> - AES-GCM reserves the zero counter value for some things
>
> The *only* purpose these bits serve is to make some encodings injective,
> and *for everyone to agree on the same encoding*. This late-breaking
> change proposal is incompatible with the second requirement. We should not
> apply it and stick to the existing consensus.
>
> On Tue, Nov 4, 2025 at 10:35 AM Richard Barnes <[e-mail]> wrote:
>
>> The justification is "the specific bits don't matter", as several people
>> noted in the recent labels discussion.  This is not like curve parameters
>> or Dual-EC DRBG, where a malicious choice could potentially introduce
>> subtle problems. The only thing that matters here is that the labels are
>> different from one another and that they are fixed.  We have labels that
>> meet those properties, so we should stick with them.
>>
>> From a practical point of view, the label is going to get copy/pasted
>> into each implementation exactly once and then never touched again.  The
>> variable names will be presumably be based on the hybrid KEM names, not the
>> labels, and the names are already constent.  See, e.g., the names that have
>> gone into the HPKE and MLS specs.
>>
>> --Richard
>>
>> On Tue, Nov 4, 2025 at 9:16 AM Nick Sullivan <[e-mail]>
>> wrote:
>>
>>> I'm definitely sympathetic to this position. It's unfortunate that the
>>> labels didn't get enough attention earlier to highlight this (pretty
>>> obvious in hindsight) issue. It's not great to have two versions of
>>> something out there, but it's not an uncommon situation for protocols to
>>> have a pre-IETF version of an algorithm deployed by industry champions
>>> outside the IETF. We've seen it with QUIC and others. None of the dependent
>>> IETF protocols are RFCs yet, so there's a window here to reexamine our
>>> assumptions (but I think it closes this week).
>>>
>>> Taking a construction being specified in a consensus process and
>>> specifically defining it to use a mysterious constant while simultaneously
>>> defining a suite of options that use systematic naming is not the type of
>>> thing cryptography research groups should do without a strong
>>> justification. I'm asking for that question to be adjudicated in public
>>> rather than in private conversations. If we're updating the labels for
>>> P-256 and P-384, it's only natural that we would consider updating X25519
>>> to be consistent. The argument against doing so is that some library
>>> implementers have implemented a construction with a different constant, and
>>> that these are deployed and available on multiple platforms, though not yet
>>> in any IETF RFCs I'm aware of. It's up to the CFRG to come to a consensus
>>> as to whether that's a strong enough justification when we need
>>> finalization ASAP.
>>>
>>> So, can someone fully articulate that justification so that the group
>>> can come to an agreement?
>>>
>>> Nick
>>>
>>> On Tue, Nov 4, 2025 at 8:50 AM Filippo Valsorda <[e-mail]>
>>> wrote:
>>>
>>>> I am most strongly opposed to defining two labels for the same
>>>> construction. It will only cause interoperability issues.
>>>>
>>>> My impression of this thread (and the other thread) is that most of the
>>>> group wants to ship and doesn't care about labels, not that most of the
>>>> group is opposed to ASCII art.
>>>>
>>>> The survey included the text "the label for X-Wing will be unchanged
>>>> (0x5C2E2F2F5E5C = "\.//^\")" and had ASCII art labels for the others ranked
>>>> second, not last, with little distance. If anything, it signals comparable
>>>> support for all the options.
>>>>
>>>> Changing the others to semantic ASCII is perfectly fine, whatever, but
>>>> changing the MLKEM768-X25519 one or having two labels for the same hybrid
>>>> makes no sense at all. The time to have opinions on the label was a year
>>>> ago, when implementers needed to ship something, and X-Wing was something
>>>> and the IETF did not produce anything.
>>>>
>>>> (I trust that even if CFRG somehow decides to give two names to the
>>>> same thing for no reason, causing confusion, the HPKE and LAMPS groups will
>>>> make the correct engineering decision of using the deployed one and not
>>>> split the ecosystem, reducing that confusion somewhat. Still unfortunate
>>>> that there would be the correct "legacy" one, and the unused one. One more
>>>> reason having a simple self-contained HPKE document like the LAMPS document
>>>> would be both faster and easier to implement than referencing two other
>>>> CFRG documents with potentially diverging opinions. CFRG is an RG, it can
>>>> take its time publishing abstract considerations on hybrids, while WGs need
>>>> to stop blocking on an RG to make progress.)
>>>>
>>>>
>>>>
>>>> 2025-11-04 14:20 GMT+01:00 Nick Sullivan <[e-mail]>:
>>>>
>>>> Hi Richard,
>>>>
>>>> This outcome seems reasonable to me. Please go ahead and update the
>>>> draft with the semantic labels for MLKEM768-P256, and MLKEM1024-P384.
>>>>
>>>> From my perspective as CFRG chair, there is one last bikeshed to paint:
>>>> the label for MLKEM768-X25519. It's clear from this discussion thread that
>>>> having ASCII art, and especially ASCII art that contains special characters
>>>> like backslashes, is undesirable to most of the group. On the other hand,
>>>> some in the group have expressed interest in using this draft as an
>>>> opportunity to define an RFC reference that establishes a code point for an
>>>> X25519-MLKEM hybrid that is interoperable with deployed versions of X-Wing
>>>> that contain the ASCII label. These are at odds.
>>>>
>>>> I want to propose an alternative that could resolve this conflict and
>>>> help us move past these issues. Here's the proposal: we define the
>>>> following three codepoints in the body of the document, updating them all
>>>> to use semantic labels:
>>>> MLKEM768-P256, label: MLKEM768-P256
>>>> MLKEM1024-P384, label: MLKEM1024-P384
>>>> MLKEM768-X25519, label: MLKEM768-X25519
>>>>
>>>> Then, in the appendix, we include a fourth codepoint to document the
>>>> legacy X-Wing construction with name "X-Wing" and label "\.//^\" so that
>>>> existing deployments have a unique and memorable codepoint they can use and
>>>> reference.
>>>>
>>>> Let's set aside for now the question of whether we should define IANA
>>>> registries in an IRTF document at all. Most documents of this sort, like
>>>> RFC 9380, RFC 9106, etc., rely on higher-level IETF protocols to define
>>>> IANA registries; HPKE was an exception that is now being rectified by the
>>>> HPKE WG. Assuming there is an IANA table created as prescribed in this
>>>> draft, this is what it would be updated to in this proposal:
>>>> | Label      | Fw | PQ Component | T Component | KDF      | PRG       |
>>>> Nseed | Nss | Reference
>>>> ||============|====|==============|=============|==========|===========|=======|=====|===========|
>>>> | "MLKEM1024-X25519" | CG | ML-KEM-768   | Curve25519  | SHA3-256 |
>>>> SHAKE-256 | 32    | 32  | [RFCXXXX] |
>>>> | "MLKEM768-P256" | CG | ML-KEM-768   | P-256       | SHA3-256 |
>>>> SHAKE-256 | 32    | 32  | [RFCXXXX] |
>>>> | "MLKEM1024-P384" | CG | ML-KEM-1024  | P-384       | SHA3-256 |
>>>> SHAKE-256 | 32    | 32  | [RFCXXXX] |
>>>> | "X-Wing" | CG | ML-KEM-1024  | P-384       | SHA3-256 | SHAKE-256 |
>>>> 32    | 32  | [RFCXXXX] |
>>>>
>>>> It's in the document's best interest to come to a decision on this
>>>> point as soon as possible. There is a 25-minute segment to discuss the
>>>> hybrid KEMs drafts in the Thursday CFRG meeting. The CFRG chairs would like
>>>> to finalize the decision for these labels so that we can publish stable
>>>> test vectors that other groups can rely on not to change going forward
>>>> (assuming there are no security-critical issues uncovered during the crypto
>>>> panel review or the research group's last call).
>>>>
>>>> Thoughts welcome!
>>>> Nick
>>>>
>>>>
>>>> On Sat, Nov 1, 2025 at 12:29 PM Richard Barnes <[e-mail]> wrote:
>>>>
>>>> OK, looks like we have a decision from the poll.  With 49 votes in,
>>>> semantic >> numbers ≈ ASCII art > random.
>>>>
>>>> I implemented this in <
>>>> https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/41>
>>>> and will cut a new draft when the window reopens.
>>>>
>>>> --Richard
>>>>
>>>> On Wed, Oct 29, 2025 at 1:17 PM Richard Barnes <[e-mail]> wrote:
>>>>
>>>> If folks care about what labels are used, I'm running a quick poll
>>>> trying to bring the CFRG discussion to a close.  Come chose your favorite
>>>> color of bikeshed paint!
>>>>
>>>> https://app.sli.do/event/g9nesbb6yuYJPbwqKm6a5z
>>>> passcode: hqeyst
>>>>
>>>> On Wed, Oct 29, 2025 at 12:08 PM Sophie Schmieg <sschmieg=
>>>> [e-mail]> wrote:
>>>>
>>>> My spicy hot take on the backslash is that anyone implementing
>>>> cryptographic code should probably know how to produce exact byte patterns
>>>> to appear in their language of choice, whether that is done via hex
>>>> encoding, via escape characters, base64, or via oring together a bunch of
>>>> left shifted 1s, I leave to the implementer, but exact control over bit
>>>> patterns is important for many cryptographic algorithms, whether that is
>>>> due to ASCII art or because certain polynomials happening to be irreducible
>>>> of GF(2).
>>>>
>>>> On Wed, Oct 29, 2025 at 1:32 PM Mike Ounsworth <Mike.Ounsworth=
>>>> [e-mail]> wrote:
>>>>
>>>> Hi Filippo, what's NOT bikeshedding is that the community has been very
>>>> clear that the HPKE and hybrid KEM documents need to be aligned and
>>>> interoperate so that crypto libs only need to implement one primitive. That
>>>> means choosing the same labels. I thought we had agreed to the HPKE style
>>>> labels with the SHAKE256 removed.
>>>>
>>>> The LAMPS document went into WGLC on Oct 17 under that assumption. That
>>>> AFTER THAT you went and changed to more stupid spaceships.
>>>>
>>>> That's not bikeshedding, that's intentionally breaking intorop with the
>>>> LAMPS doc after it entered WGLC.
>>>>
>>>> ---
>>>> Mike Ounsworth
>>>> ------------------------------
>>>>
>>>> *From:* Carl Wallace <[e-mail]>
>>>> *Sent:* Wednesday, October 29, 2025 2:59:03 PM
>>>> *To:* Filippo Valsorda <[e-mail]>; Daniel Van Geest <
>>>> [e-mail]>; Mike Ounsworth <
>>>> [e-mail]>; Samuel Lee (ENS/Crypto) <
>>>> [e-mail]>
>>>> *Cc:* CFRG <[e-mail]>; [e-mail] <[e-mail]>; LAMPS WG <
>>>> [e-mail]>
>>>> *Subject:* [lamps] Re: [CFRG] Re: [EXTERNAL] Re: [hpke] Re: Re: Re:
>>>> Re: Cross-testing update on LAMPS Composite and cfrg-concrete-hybrid-kems
>>>>
>>>> Inline. . From: Filippo Valsorda <filippo@ ml. filippo. io> Date:
>>>> Wednesday, October 29, 2025 at 3: 49 PM To: Carl Wallace <carl@
>>>> redhoundsoftware. com>, Daniel Van Geest <daniel. vangeest@
>>>> cryptonext-security. com>, Mike Ounsworth <ounsworth+ietf@ gmail. com>,
>>>>
>>>> Inline..
>>>>
>>>>
>>>>
>>>> *From: *Filippo Valsorda <[e-mail]>
>>>> *Date: *Wednesday, October 29, 2025 at 3:49 PM
>>>> *To: *Carl Wallace <[e-mail]>, Daniel Van Geest <
>>>> [e-mail]>, Mike Ounsworth <
>>>> [e-mail]>, "Samuel Lee (ENS/Crypto)" <
>>>> [e-mail]>
>>>> *Cc: *CFRG <[e-mail]>, "[e-mail]" <[e-mail]>, LAMPS WG <
>>>> [e-mail]>
>>>> *Subject: *Re: [lamps] Re: [CFRG] Re: [EXTERNAL] Re: [hpke] Re: Re:
>>>> Re: Re: Cross-testing update on LAMPS Composite and
>>>> cfrg-concrete-hybrid-kems
>>>>
>>>>
>>>>
>>>> <snip>
>>>>
>>>>
>>>>
>>>> [CW] Some of these labels changed in an update published on October 20:
>>>> https://author-tools.ietf.org/iddiff?url1=draft-irtf-cfrg-concrete-hybrid-kems-00&url2=draft-irtf-cfrg-concrete-hybrid-kems-01&difftype=--html
>>>> <https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url1=draft-irtf-cfrg-concrete-hybrid-kems-00&url2=draft-irtf-cfrg-concrete-hybrid-kems-01&difftype=--html__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSKvai_P0$>.
>>>> So that’s 9 days ago. It hardly seems earth shattering to revert those
>>>> changes in an update when the publication window reopens.
>>>>
>>>>
>>>>
>>>> No, the ML-KEM-768 + X25519 one has been in use for months, e.g. in
>>>> https://developer.apple.com/documentation/cryptokit/xwingmlkem768x25519
>>>> <https://urldefense.com/v3/__https://developer.apple.com/documentation/cryptokit/xwingmlkem768x25519__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDS8lP9zWY$> and
>>>> I believe in Google's Tink.
>>>>
>>>>
>>>>
>>>> [CW] Hence my use of the words “some of the labels”. I understand that *
>>>> *one** of the labels was defined earlier. That can be seen in the diff
>>>> I provided a link to, along with indications that other labels just
>>>> changed, including the one Dan references below.
>>>>
>>>>
>>>>
>>>> FWIW, I did use the provided hex as you suggest rather than deal with
>>>> escaping the string but really don’t see why we’d torture ourselves like
>>>> this. Recall there was pushback to using (more relevant) DER encoded OIDs
>>>> as too cumbersome and those had exactly the same “just use the hex”
>>>> property you cite above.
>>>>
>>>>
>>>>
>>>> 2025-10-29 18:06 GMT+01:00 Daniel Van Geest <daniel.vangees
>>>> <https://urldefense.com/v3/__http://daniel.vangees__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSayiSZN4$>
>>>> [e-mail]
>>>> <https://urldefense.com/v3/__http://cryptonext-security.com__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSBLS5GrE$>
>>>> >:
>>>>
>>>> Is it bikeshedding the labels by pointing out that by using common
>>>> escape characters (\) in the label you are virtually guaranteeing
>>>> implementations make a difficult to detect interoperability mistake?
>>>>
>>>> In fact, they screwed it up themselves IN THEIR OWN DRAFT!
>>>>
>>>>    - Label: ` | /-` (0x207C202F2D5C)
>>>>
>>>> no Thanks,
>>>> Daniel
>>>>
>>>>
>>>>
>>>> On 2025-10-29 10:06 a.m., Filippo Valsorda wrote:
>>>>
>>>> Hi Mike,
>>>>
>>>>
>>>>
>>>> I have some good news: as of
>>>> https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/28
>>>> <https://urldefense.com/v3/__https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/28__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSKdQC3rc$> the
>>>> CFRG labels don't include "SHAKE256" anymore!
>>>>
>>>>
>>>>
>>>> See also https://github.com/cfrg/draft-irtf-cfrg-hybrid-kems/issues/77
>>>> <https://urldefense.com/v3/__https://github.com/cfrg/draft-irtf-cfrg-hybrid-kems/issues/77__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSgC24B2c$> for
>>>> the discussion on whether different keygens should interoperate, which
>>>> concluded we should allow it.
>>>>
>>>>
>>>>
>>>> As an implementer, please please please don't ship similarly shaped
>>>> hybrids with the same components that don't interoperate. (Also, pretty
>>>> please, let's not bikeshed the labels unless absolutely necessary, it's
>>>> been 14 months since FIPS 203, I need a stable P-256 hybrid for age
>>>> hardware keys.)
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Filippo
>>>>
>>>>
>>>>
>>>> 2025-10-29 02:59 GMT+01:00 Mike Ounsworth <[e-mail]>:
>>>>
>>>> Hi Samuel, I believe this question is still up for debate. The labels
>>>> are different because the concrete CFRG draft uses a combined keygen and
>>>> private key -- ie the stored private key is a single 32 byte seed that you
>>>> have to use SHAKE256 to expand out into an ML-KEM seed and an ECDH seed [1]
>>>> whereas the LAMPS Composite private key conveys the two component private
>>>> keys separately. Currently, the CFRG draft includes "SHAKE256" in the label
>>>> to force Encap() / Decap() incompatibility between things that use
>>>> different KDFs for key expansion from stored private key (or in the case of
>>>> composites, no KDF since no expansion is necessary). The core argument is
>>>> that shared seed private keys have extra MAL-BIND security properties.
>>>>
>>>>
>>>>
>>>> This is an open point of discussion about whether this _should_ be
>>>> represented in the label, or whether this is unrelated to Encap() / Decap()
>>>> compatibility. If you have an opinion on this, now would be a good time to
>>>> voice it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [1] sample code showing re-expanding a combined seed private key:
>>>> https://github.com/lamps-wg/draft-composite-kem/blob/main/src/crossTestCRFGHybridKEM.py#L85
>>>> <https://urldefense.com/v3/__https://github.com/lamps-wg/draft-composite-kem/blob/main/src/crossTestCRFGHybridKEM.py*L85__;Iw!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDS7_gTo0U$>
>>>>
>>>>
>>>>
>>>> -Mike
>>>>
>>>>
>>>>
>>>> On Tue, Oct 28, 2025, 20:45 Samuel Lee (ENS/Crypto) <
>>>> [e-mail]> wrote:
>>>>
>>>> This is great news!
>>>>
>>>>
>>>>
>>>> For my own understanding, is the intent that the labels are going to
>>>> aligned before both *cfrg-concrete-hybrid-kems* and LAMPS
>>>> *draft-composite-kem* are adopted?
>>>>
>>>> i.e. if one was going to implement a hybrid-kem interface for
>>>> MLKEM768-P256, it would be usable in both HPKE and CMS.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Sam
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Mike Ounsworth <[e-mail]>
>>>> *Sent:* 27 October 2025 16:55
>>>> *To:* CFRG <[e-mail]>; [e-mail] <[e-mail]>; LAMPS WG <
>>>> [e-mail]>
>>>> *Subject:* [EXTERNAL] [lamps] Re: [hpke] Re: [CFRG] Re: Re: Re:
>>>> Cross-testing update on LAMPS Composite and cfrg-concrete-hybrid-kems
>>>>
>>>>
>>>>
>>>> [e-mail] appears similar to someone who previously
>>>> sent you email, but may not be that person. Learn why this could be a
>>>> risk
>>>> <https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSdXCOYYw$>
>>>>
>>>> Hi CFRG, HPKE, and LAMPS,
>>>>
>>>>
>>>>
>>>> After a bit more back-and-forth with Richard about exactly what EC
>>>> private key format he used in his test vectors, WE HAVE INTEROP ON
>>>> MLKEM768+P256!!!
>>>>
>>>>
>>>>
>>>> The secret I was missing was that the ECDH private key in Richard's
>>>> test vectors are the big-endian integer representation of an EC private
>>>> key, and if I just threw that directly into a PKCS8, then it was a valid
>>>> LAMPS Composite private key (plus some other fighting with the python
>>>> cryptography library). That's fine, I'm happy to consider that "achieving
>>>> interop". Richard has submitted a PR
>>>> to draft-irtf-cfrg-concrete-hybrid-kems that would have helped me avoid
>>>> this confusion in the first place. As a bonus, I learned something, thanks
>>>> Richard for helping me through this.
>>>>
>>>>
>>>>
>>>> I'm happy to declare this thread complete: we have proved
>>>> that draft-irtf-cfrg-concrete-hybrid-kems and
>>>> draft-ietf-lamps-pq-composite-kem are cross-compatible up to the label and
>>>> private key encoding, which was the goal.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Details of the hacking that I had to do to convert an instance of the
>>>> CFRG test vectors into an instance of the LAMPS test vectors can be found
>>>> here:
>>>>
>>>>
>>>> https://github.com/lamps-wg/draft-composite-kem/blob/main/src/crossTestCRFGHybridKEM.py#L92
>>>> <https://urldefense.com/v3/__https://github.com/lamps-wg/draft-composite-kem/blob/main/src/crossTestCRFGHybridKEM.py*L92__;Iw!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSsCndGTE$>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, 27 Oct 2025 at 08:13, Thad Thompson <[e-mail]>
>>>> wrote:
>>>>
>>>> Hey Martin,
>>>>
>>>> > I have to admit, that in my HPKE implementation I did not even notice
>>>> (or have enforced) that X25519 keys generated through other means cannot be
>>>> used.
>>>>
>>>> Is this a MUST requirement?
>>>>
>>>>
>>>>
>>>> No, sorry for the confusion - I don't believe this is the case. As
>>>> Watson pointed out above, key generation is handled pretty well in
>>>> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems#section-5.2
>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems*section-5.2__;Iw!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSXcssxd4$> which
>>>> describes the considerations for working without seeds. Also note that this
>>>> isn't in the context of an HPKE spec, but just hybrid KEMs at this point.
>>>>
>>>>
>>>>
>>>> My earlier comment was aimed more generally toward the impression one
>>>> gets from various places is that seed based key generation is a 'should'
>>>> requirement, when it really isn't. For example,
>>>>
>>>>
>>>> https://www.ietf.org/archive/id/draft-irtf-cfrg-concrete-hybrid-kems-01.html#section-3.1.1-7
>>>> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-irtf-cfrg-concrete-hybrid-kems-01.html*section-3.1.1-7__;Iw!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSDXbzS_E$>
>>>> specifies:
>>>>
>>>>
>>>>
>>>> > A hybrid KEM using these curves MUST specify the PRG that should be
>>>> used.  All of the hybrid KEMs in this document use SHAKE256 [FIPS202].
>>>>
>>>>
>>>>
>>>> Which might make it appear that a PRG (and seed based key generation)
>>>> is required for 'in-production' implementations of the KEM, instead of
>>>> really being a requirement for interop testing.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> -Thad
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 27, 2025 at 6:04 AM Martin Schanzenbach <
>>>> [e-mail]> wrote:
>>>>
>>>> Am Mittwoch, dem 22.10.2025 um 07:46 -0500 schrieb Thad Thompson:
>>>>
>>>> > Implementations can obviously always go off-spec for keygen.
>>>>
>>>>
>>>>
>>>> This seems like the heart of the issue.
>>>>
>>>>
>>>>
>>>> Let's say I get my PQ-HPKE library implemented and tested and it works
>>>> fine with all the test vectors. But in prod we're only allowed to use EC
>>>> private keys forged in the fires of Mount Doom. One does not simply tell
>>>> their boss (and customers) "no problem, we'll just go off spec."
>>>>
>>>>
>>>>
>>>> It would go a long way if there were a section clearly explaining the
>>>> security impact of using EC keys generated elsewhere, making it an
>>>> 'in-spec' option.
>>>>
>>>>
>>>>
>>>> Best
>>>>
>>>> -Thad
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>>
>>>> I have to admit, that in my HPKE implementation I did not even notice
>>>> (or have enforced) that X25519 keys generated through other means cannot be
>>>> used.
>>>>
>>>> Is this a MUST requirement? Where is the reasoning in particlar for
>>>> X25519 and X448? If it is a MUST, somewhere in the document should be an
>>>> explanation on why it is done such that other KEMs can make an informed
>>>> decision how to place limitations on their (private) keys in a similar
>>>> fashion.
>>>>
>>>>
>>>>
>>>> BR
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Oct 21, 2025 at 6:06 PM Filippo Valsorda <[e-mail]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> Hi Mike,
>>>>
>>>>
>>>>
>>>> Since this thread is about hybrid KEMs and not HPKE DHKEM, I think you
>>>> are confusing the DeriveKeyPair function of RFC 9180 with the CG framework
>>>> DeriveKeyPair function of draft-irtf-cfrg-hybrid-kems-06, Section 5.5,
>>>> which references the RandomScalar function
>>>> of draft-irtf-cfrg-concrete-hybrid-kems-01, Section 3.1.1. (I also find it
>>>> hard to navigate the split in documents.)
>>>>
>>>>
>>>>
>>>> I have reproduced them below for you. I am certain you can implement
>>>> them with any major cryptography library. There is nothing HPKE-specific
>>>> about them. SP 800-56A, Section 5.6.1.2, only specifies a random key
>>>> generation algorithm (a pretty silly one, IMHO, with the needless "d = c +
>>>> 1" instead of checking "c > 0"), so I am not sure what relevance it has
>>>> here: there is no such thing as a standard library function for SP 800-56A,
>>>> Section 5.6.1.2.{1,2} key *derivation*. If the argument is that no one
>>>> should be allowed to derive ECDH keys from a KDF because NIST doesn't like
>>>> that, I doubt many folks will find that argument persuasive.
>>>>
>>>>
>>>>
>>>> Implementations can obviously always go off-spec for keygen if they
>>>> need to appease a regulator (or e.g. use hardware keys), though! They will
>>>> still interoperate.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Filippo
>>>>
>>>>
>>>>
>>>> def DeriveKeyPair(seed):
>>>>
>>>>     (ek_PQ, ek_T, dk_PQ, dk_T) = expandDecapsKeyG(seed)
>>>>
>>>>     return (concat(ek_PQ, ek_T), seed)
>>>>
>>>> def expandDecapsKeyG(seed):
>>>>
>>>>     seed_full = PRG(seed)
>>>>
>>>>     (seed_PQ, seed_T) = split(KEM_PQ.Nseed, Group_T.Nseed, seed_full)
>>>>
>>>>
>>>>
>>>>     (ek_PQ, dk_PQ) = KEM_PQ.DeriveKeyPair(seed_PQ)
>>>>
>>>>     dk_T = Group_T.RandomScalar(seed_T)
>>>>
>>>>     ek_T = Group_T.Exp(Group_T.g, dk_T)
>>>>
>>>>
>>>>
>>>>     return (ek_PQ, ek_T, dk_PQ, dk_T)
>>>>
>>>> def RandomScalar(seed):
>>>>
>>>>   state = XOF.Init(seed)
>>>>
>>>>   sk = OS2IP(XOF.Read(state, Nscalar))
>>>>
>>>>   while sk == 0 || sk >= order:
>>>>
>>>>     sk = OS2IP(XOF.Read(state, Nscalar))
>>>>
>>>>   return (sk, pk(sk))
>>>>
>>>> (The XOF is SHAKE256, Nseed/Nscalar is 32 for P-256, and 48 for P-384.)
>>>>
>>>>
>>>>
>>>> 2025-10-22 00:31 GMT+02:00 Mike Ounsworth <[e-mail]>:
>>>>
>>>> Hi Watson,
>>>>
>>>>
>>>>
>>>> SP 800-56A section 5.6.1 defines the FIPS-approved ways of deriving a
>>>> ECDH key. You can't derive your keys as described in rfc9180 7.1.3 and
>>>> claim that it is "ECDH" as defined in SP 800-56A, because it isn't. That's
>>>> not a FIPS-allowed way to derive EC keys, and that's the whole story.
>>>>
>>>>
>>>>
>>>> On Tue, 21 Oct 2025 at 14:23, Watson Ladd <[e-mail]>
>>>> wrote:
>>>>
>>>> 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://datatracker.ietf.org/doc/html/rfc9180#derive-key-pair
>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9180*derive-key-pair__;Iw!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSLtKS3Ig$>
>>>>
>>>> >
>>>>
>>>> > 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://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/#cryptography.hazmat.primitives.asymmetric.ec.derive_private_key
>>>> <https://urldefense.com/v3/__https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/*cryptography.hazmat.primitives.asymmetric.ec.derive_private_key__;Iw!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSFP4Myto$>
>>>>
>>>> >> 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://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/21
>>>> <https://urldefense.com/v3/__https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/21__;!!FJ-Y8qCqXTj2!eFcmIFtPoVBOI1Xrw8NUJlvYnkOdBWEF_x21kJZ0hfPPeOMg0Bx5vpsXEOeqqV7OINWKvlRwLRpDIuBTkQ37KUDSjLO7N4M$>
>>>> .
>>>>
>>>> >>>>
>>>>
>>>> >>>> _______________________________________________
>>>>
>>>> >>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> CFRG mailing list -- [e-mail]
>>>>
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>>
>>>> CFRG mailing list -- [e-mail]
>>>>
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> hpke mailing list -- [e-mail]
>>>>
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>>
>>>> CFRG mailing list -- [e-mail]
>>>>
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> 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]
>>>>
>>>>
>>>> *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.*
>>>>
>>>> _______________________________________________
>>>> Spasm mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>>>> [e-mail]
>>>>
>>>>
>>>> _______________________________________________
>>>> CFRG mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>> CFRG mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>> 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]
>>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>