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

[Mike Ounsworth <[e-mail]>]

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