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

[Nick Sullivan <[e-mail]>]

Thanks Dennis,

It's great that this point has been discussed in the IETF, but it
hasn't yet been discussed in the CFRG, and consensus hasn't been
established within the group on this point. Hopefully, we can get some
closure at the CFRG meeting.

I'll admit that I wasn't fully familiar with all of these threads, but
upon review, I don't see a clear justification for maintaining
compatibility articulated in them beyond "velocity" and the fact that
an identical construction with a specific label has been shipped in
non-IETF protocols by Apple and Google Cloud. In fact, these threads
highlight that many people have concerns with the starship label
approach.

The stakeholders with the strongest preference for maintaining
compatibility appear to be library implementers, who would likely need
to add a new codepoint to their libraries to support existing non-IETF
use cases and any RFC that relies on concrete hybrids as normative.
Which is less than ideal, but maybe not catastrophic. The good news is
that almost all existing implementations use the term X-Wing, X-Wing
and X25519-MLKEM512 are very different names, so confusion may be
minimal among users.

I'd like to see a better justification (or a consensus among CFRG
participants that the given justification is sufficient) for
maintaining compatibility between X25519-MLKEM512 and X-Wing. If IETF
protocol stakeholders have a preference (this thread suggests people
leaning this way), that would also helpful so we can close this
discussion.

Like everyone here, I'm not happy about bringing up this discussion
point so late in the conversation, but as a chair I need feedback from
the group itself.

-Nick

Please correct me if I'm wrong, but the relevant points from these
threads seem to be:
[lamps] New labels in draft-irtf-cfrg-concrete-hybrid-kems-01 :
- Discussion focused on the labels of the P256/P384 hybrids, not X25519

[lamps] Cross-testing update on LAMPS Composite and
cfrg-concrete-hybrid-kems: Current thread
- Strong opinions about not using the starship label for NIST hybrids.
"We’re already having interop problems at the PQC hackathon group
because of the backslash in the xwing label" -Mike O
- No deep discussion about X25519 other than requesting it be written
in hex format to obfuscate the fact that this string exists, which
suggests the label is less than ideal.
- A hybrid matching the current X25519-MLKEM512 starship label has
been shipped in non-IETF protocols by Apple and Google Cloud.

[lamps] X-Wing X.509 Certificates
- Early discussion focused on X-Wing individual drafts and LAMPS interop.
- Strong suggestion that convergence is a useful goal. "We should try
to make the crypto the same so that crypto library maintainers don’t
need to implement a half-dozen different versions of ML-KEM-768 +
X25519 because every protocol does it slightly differently. It would
be sweet if id-MLKEM768-X25519 just is X-Wing" -Mike Ounsworth

[hpke] Status of X-Wing
- The ASCII vs text label debate was not conclusively decided on the
HPKE list in this thread.
- By the time of draft-ietf-hpke-pq-02 (late 2025), they opted for the
alphanumeric labels (MLKEM768-X25519, etc.), demonstrating a
preference for clarity in the final registry. "By the way the code
point for HPKE is defined in draft-ietf-hpke-pq, not this draft, and
(thankfully) it doesn’t use the ascii art labels. It uses:
MLKEM768-P256, MLKEM768-P384, MLKEM768-X25519 – which seem eminently
sane to me" - Rohan Mahy

On Tue, Nov 4, 2025 at 10:48 AM Dennis Jackson
<ietf=[e-mail]> wrote:
>
> This issue has been discussed at length on the lamps and hpke WG mailing lists. In particular the threads:
>
> [lamps] New labels in draft-irtf-cfrg-concrete-hybrid-kems-01
> [lamps] Cross-testing update on LAMPS Composite and cfrg-concrete-hybrid-kems
> [lamps] X-Wing X.509 Certificates
> [hpke] Status of X-Wing
>
> It was also discussed in the lamps meeting today.
>
> Best,
> Dennis
>
> On 04/11/2025 15:16, Nick Sullivan 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. 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 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 <[e-mail]>:
>>
>> 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 the CFRG labels don't include "SHAKE256" anymore!
>>
>>
>>
>> See also https://github.com/cfrg/draft-irtf-cfrg-hybrid-kems/issues/77 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
>>
>>
>>
>> -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
>>
>>
>> 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
>>
>>
>>
>>
>>
>> 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 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 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
>>
>> >
>>
>> > 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
>>
>> >> 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.
>>
>> >>>>
>>
>> >>>> _______________________________________________
>>
>> >>>> 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]
>
> _______________________________________________
> hpke mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]