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

[Richard Barnes <[e-mail]>]

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