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

[Mike Ounsworth <[e-mail]>]

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.

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