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

[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]
>