Return-Path: X-Original-To: cfrg@mail2.ietf.org Delivered-To: cfrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7528F7CCA90D for ; Mon, 27 Oct 2025 04:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2TXcye0IK5B for ; Mon, 27 Oct 2025 04:04:13 -0700 (PDT) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4D39F7CCA8FB for ; Mon, 27 Oct 2025 04:04:13 -0700 (PDT) Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id F202E240103 for ; Mon, 27 Oct 2025 12:04:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.de; s=2017; t=1761563046; bh=I+WTWy0Kz9afpwx1GJuz2u+/VBsKhf9xmj7QApKL/+Y=; h=Message-ID:Subject:From:To:Cc:Date:Autocrypt:Content-Type: MIME-Version:From; b=QLRFfJYtA8ZHMiBso1Q1QG1f5iicHHtUl0HZo4Ix72puPGSgYcmL5OT+BOlchox27 j0wBFNoZsEYUxWZUIcHtO6eIBwZ2oPwsQz5FnlbCwmKJmbbMnMyU/p1TPWmRGPHQM9 CCn+d2TZCYQUbvpDEojA3jFPggDAORKg16+bS4T1URQdNRetsDxoZ3weVtxKuxl1v4 wswkvUAPh9cOU0wWZPIBcNHk3bSOta+eH//sRcq/dCH7mp+f79NEAbikY5g2s5/g+S b+5B8vf/vHgcjjkfV/2WvWIaVczTJtzdlg9cko92iZWlelEnHpGGnK75DQy0/jGSoN MYlvKko28oO0g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4cw9cN1qfpz9rxS; Mon, 27 Oct 2025 12:04:04 +0100 (CET) Message-ID: <51e5bc4a83c2b213716dfec19be26152d47d4254.camel@posteo.de> From: Martin Schanzenbach To: Thad Thompson , Filippo Valsorda Date: Mon, 27 Oct 2025 11:04:05 +0000 In-Reply-To: References: <21e583cf-a58c-4ff2-8ef6-e4c894525dd9@app.fastmail.com> <6205989c-81f2-45e5-837b-ce6217b88b55@app.fastmail.com> Autocrypt: addr=mschanzenbach@posteo.de; prefer-encrypt=mutual; keydata=mQINBFZlTN8BEADIXdWebdUepgP8YkULGh2EClt/q2Nkh5QB+V88ZtWVdEfz6ELbKeKE/ 39yllXso20H56OfWGgcU2SF6EKdT+FDir5pDxM+RQiIjrYHLMj9MG87LBcW65PHny6hmXtrfrWISX q7x2Si5G9pMz33jp5Dsx/IMTbTPbdK09b34S9aqIjTkpQ4yqByi07nkRcYgSOzx1Dr/7oatKn5/tT RQm9CQ2pqcYYD5Rqg1jcNpKRUWFX/m+LRd3iQ6ZF/F2W9hR6BYWRUi3eJOFYX/ngWrSj3q3c3zQgP y7R/4weZRT/WYjwccHyvLHbw3YFVLDgM2RAu2q765+3iWrH4RvYxS0eMDan7uK6q3+83KB83ofnH8 IEt6PWK3tmmQJ1vYbQDSqeLxiptPlOgoQuaJCCAFJaBIwamLZJq0BPmncDzZ3bGksROgV31qqFYsd KfyUnKQZZpEVsdpOz1oMK0RSlqW2j759C8E4DrsqCBoBm63lZPQsYp94s4gT5W2D3vfPqF3dOht6n ByGVYvwh3ildcBtKcU8vctlms+izbb0p94pviM10/vIuuAzerB4Pb8qMN8+KuSfIUtTWprD/D0NAP RBpc7Uiv8sSufldNhN+A4GdkkXe409+AWGusKMlZO9fP3BYf+J3jDxlbRoVoEyl67dioT0QbFdhOq Qt1EjJH9XT77QARAQABtC1NYXJ0aW4gU2NoYW56ZW5iYWNoIDxtc2NoYW56ZW5iYWNoQHBvc3Rlby 5kZT6JAlEEEwEIADsCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4ACGQEWIQQ9EQY8EPmNFL0k0Uc LCZjvhvWbagUCY470egAKCRALCZjvhvWbaopMEACfIHV7sgIv5bhrooTh+k9hpVjzIjomiy4HeVTK aZb6ZATHsa///YiWKrYM2OjO3u7+tQ73c9xW4EOIL3Fy/XE237k0urdU+urQkCcDvJAimoZn0c07T eRflqswco3lp/uyUhCb6UH4f7Os/HqMsLQCZFFutsvvU++bTiWJNBpoP8ntbqG2ZYhs2asFTWOBLH +BqyfiCfwsj4Rz/HyrOZC5DcXp591JZu8zaOF3zyu/uhODE6PNY08+gdN8s1/CmENp5oi7ir4EmHE h+VnVYVXe1zEk52jHNaKuHIb1l9q3xbJ8JczKDiOCe6ahRlmhSwdO0OTHyhrQWnGnG0hPscagTpTP hjooMVVnKtB4AEE2qVm5WAEA6EuYfgyp4+MuS1KWfgNGCHIbNyZ7Rc9D4fVtHl/ZUrF/k7KVEQ+HS y7WW9X2oDRtYuS6tvbNFnao3nq+EtZ8kzuSdt1yBtv0SeXNqj/ZrgI+gzz96U4D0lbVXCB7MpEsve O15fszATVN7rYJXY4Yjl2B64Z3bwNTFuIJjvih+nUp0Ls56GAcCvqCi1JLxOVu9ZR8lGSKKjl/RPl FcVyHzE7AiMTgKN6VdoCCsVNgMSBoGz9qg5Jey1lsrmTaNAUG28hJuAiNn4ZlQCsIz/XaMuIWb04/ xkgpLHpiT1smzUYOS9QxPEbtvsV3VbQpTWFydGluIFNjaGFuemVuYmFjaCA8c2NoYW56ZW5AZ251b mV0Lm9yZz6JAk4EEwEIADgCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQQ9EQY8EPmNFL0k0U cLCZjvhvWbagUCY470egAKCRALCZjvhvWbaskiEACc/tMSZBbVh5Bv9clLZvk1fsXn2J6HjOc0SE0 AImCaoYM0K3IGACj3HZckBZG6ZrX9z0PXtuoWKHR8QDcfeWCcp/pIWZQyzwZDQsuCCK1DT7MW4B3i vHeqLODR/7saZ2xnpbq35l/41BPb539wZuTph2LDZh9SRl6Yzgma9WdJNBF4EBXpodrVshrQ0WuOr WrIY4sPzlUPT25nayHgeCH6FKPhAV0t23GYPy0gq0kXXUJC1mVYai+6w4haJ+Y3p7MDgscdnd0BJ/ ijyOSH/lIumV8E+T1KgwLkGIKfPYzdNU+zi/g74RIXucuLPkl/Hs2mMj+l1Rtje0zPMy7jEmfp47X bFAF8Mo2/ME2HipiEV1kzf9mWSVEcEJE4lK+bg+K2S0hrBcqudF4PizxUnQ9FW+YJLJwkoVripk3H F0TFUu6IMHe60aF+Mlnc8MlgIvArRIKOFWvIk9wbCgziIDrp+WqFikAGtHfcjtJIM1OW0MSZ4rKWN QQWe4LFAIhQfys4iqjI9HNrUu6wqHjElotFTLdwyOfVJFnZmAjNwPR87E+N1RR1Lsl7NlajRyalfX A9ilXqhHKyzcTkFc7yl4dvu8w5+ptoBpF/UrUQa+W0auxcPxYmFFfymaK5z/NVS5U0/YUea5UuaUj eJseVMrkqTY+etXv4e/54Qhfaan6QV7QmTWFydGluIFNjaGFuemVuYmFjaCA8c2NoYW56ZW5AZ251 Lm9yZz6JAk4EEwEIADgCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQQ9EQY8EPmNFL0k0UcLC ZjvhvWbagUCY470egAKCRALCZjvhvWbaheYD/9ajvG1PENl/kuOE1g3HjN8vqbzbl06iFeJSl9Zr1 j18D4qeXMODbk0wFZZ8/pnqDJxUdcwvI/RviJuMKS0k+aUE3v4pIHGU6U3YxqSr3Cfk+JgGmpzP8C bZWLh9Zs5T2UWf57/nmyk0aiK4VF+bb9OYTxRu7lR+l0/psQqRUTm6XSDoqHsQ7EGZapxEy+KiiS2 4iCmLjGicpT05S08xGTIhZpd2B25BES3LVfe6rJfR9mJvCNoSSPKAvyvlu0l30DH7wBRS36dokalA K4tYcDF3ceHSdafzLgya3GvJppTW65zlq+rtwWwOj07dYR1RiMt6x68Mr+JvH9robPwLZ8TPOmxcG iEgNEWxunr81KLjRNckjEyF90oGdCGzckgmKx/rSgb8y3Lk7ivvohjoNydUYX7JGPWnyR9q+Nk7EV /fzT87bT//5I+86ECzIK/D0hL0gXhJa0cm7rQkn/OOzS4KEI/4pOmgNts7zfEm1VEB3f+VXpgRN/o /ikWfLsdu1K7PgdPYvF39V8Nl8AZKGzd5zUy1r3AMt0Lb3iBvsCsmry82b4Vj+CLvv9YvqyukBgPm P3N7XL12om6+VrGxnX1a/6KA1RU6UBSnzEg3L5addzeGrqT4hokLFBkizwBy0K62M+sCzVDWcwYQE juB7e/yimk3AVhbHl7lTb5ncNWzLQqTWFydGluIFNjaGFuemVuYmFjaCA8bWFydGluQHNjaGFuemV uYmEuY2g+iQJRBBMBCAA7AhsDBQsJCAcCAiICBhUKCQgLAgQWAgMBAh4HAheAFiEEPREGPBD5jRS9 JNFHCwmY74b1m2oFAmOO9HoACgkQCwmY74b1m2rvwQ/+J+tQZnN9L5AAeP35QV5aMmEJGiYUlMlKp hpivs0wR58an7umZWnbDyam3nx2N0rX7mpzYFD26ix0F7cHV5LGICqf2uA3Ek4IKNrlwNdPe5bzGi mnAlzZpqEjJRee0vnrEMJFh8QpBgGKrIQLgbVX9+FIZ7NqJTC9Bylm9D5015iPja6adtghH2D18EF 8Rs8cwofjwTToUUh6i/2/JU/EiOifqGzY/075+EMXDAYbm9k1yPt6uddfzLfiMwMxBh41M2Ua5KQm bESAiPUxOWRKEAo4uWCjrOlub/Mo9Zg04oMOg4HKuKbb81srmWJgX9UINw58ugucYHuGMph5MxNsk F47M9ZQV5ZvYl/7S2n9zx1sYlCQdElzxZcdZuzXjFrll3NtcX9cO1qt/ulxaEbkZIrdYw0HyTcRcn BaO3RQP6w2K8JjbcTHbWFGENrbZ70ISY2qgu6LHgWGbOO/391mm6/rI1pVc8VprxMAz9C+T3KuxGH /gK26ALV8roxi3en7wIGLRcybxY9fmrnj4YahHyMCWEg7MATN4BIUXDQy+u7vdBmLn+iv6KBFszo8 9KwBfzd08Rqb+N77z9BgkrJp9etRSlqqh0D4YtzWXmBnxSShU/xQac/qMdIDVYFK9HypIcD0rHJgg sEaq/0g3ECnVLR/IFpBrKIPNjA7U+d2W9g= Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-rcAc/EPUWrmqeiNqSoPm" MIME-Version: 1.0 Message-ID-Hash: AEVXS6KGSBLSRNZ4XTGFLANI74ZTM7QK X-Message-ID-Hash: AEVXS6KGSBLSRNZ4XTGFLANI74ZTM7QK X-MailFrom: mschanzenbach@posteo.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: CFRG , hpke@ietf.org, LAMPS WG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_=5Blamps=5D_Re=3A_Re=3A_Cross-testing_update_on_L?= =?utf-8?q?AMPS_Composite_and_cfrg-concrete-hybrid-kems?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-rcAc/EPUWrmqeiNqSoPm Content-Type: multipart/alternative; boundary="=-w9MqpUszxHPdBTcffU2r" --=-w9MqpUszxHPdBTcffU2r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch, dem 22.10.2025 um 07:46 -0500 schrieb Thad Thompson: > > Implementations can obviously always go off-spec for keygen. >=20 > This seems like the heart of the issue.=C2=A0 >=20 > Let's say I get my PQ-HPKE library implemented and tested and it > works fine with all the test=C2=A0vectors.=C2=A0But in prod we're only al= lowed > 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."=C2=A0 >=20 > 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. >=20 > 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 >=20 >=20 > On Tue, Oct 21, 2025 at 6:06=E2=80=AFPM Filippo Valsorda > wrote: > > Hi Mike, > >=20 > > Since this thread is about hybrid KEMs and not HPKE DHKEM, I think > > you are confusing the=C2=A0DeriveKeyPair function of RFC 9180 with the > > CG framework DeriveKeyPair function of=C2=A0draft-irtf-cfrg-hybrid-kems= - > > 06, Section 5.5, which references the RandomScalar function > > of=C2=A0draft-irtf-cfrg-concrete-hybrid-kems-01, Section 3.1.1. (I also > > find it hard to navigate the split in documents.) > >=20 > > 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=C2=A05.6.1.2, onl= y > > specifies a random key generation algorithm (a pretty silly one, > > IMHO, with the needless "d =3D 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. > >=20 > > 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. > >=20 > > Cheers, > > Filippo > >=20 > > def DeriveKeyPair(seed): > > (ek_PQ, ek_T, dk_PQ, dk_T) =3D expandDecapsKeyG(seed) > > return (concat(ek_PQ, ek_T), seed) > > def expandDecapsKeyG(seed): > > seed_full =3D PRG(seed) > > (seed_PQ, seed_T) =3D split(KEM_PQ.Nseed, Group_T.Nseed, seed_full) > >=20 > > (ek_PQ, dk_PQ) =3D KEM_PQ.DeriveKeyPair(seed_PQ) > > dk_T =3D Group_T.RandomScalar(seed_T) > > ek_T =3D Group_T.Exp(Group_T.g, dk_T) > >=20 > > return (ek_PQ, ek_T, dk_PQ, dk_T) > > def RandomScalar(seed): > > state =3D XOF.Init(seed) > > sk =3D OS2IP(XOF.Read(state, Nscalar)) > > while sk =3D=3D 0 || sk >=3D order: > > sk =3D OS2IP(XOF.Read(state, Nscalar)) > > return (sk, pk(sk)) > >=20 > > (The XOF is=C2=A0SHAKE256,=C2=A0Nseed/Nscalar is 32 for P-256, and 48 f= or P- > > 384.) > >=20 > > 2025-10-22 00:31 GMT+02:00 Mike Ounsworth > > : > > > Hi Watson, > > >=20 > > > SP 800-56A section=C2=A05.6.1 defines the FIPS-approved ways of > > > deriving a ECDH key.=C2=A0You 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. > > >=20 > > > On Tue, 21 Oct 2025 at 14:23, Watson Ladd > > > wrote: > > > > On Tue, Oct 21, 2025 at 12:14=E2=80=AFPM Mike Ounsworth > > > > 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. > > > > =20 > > > > 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. > > > > =20 > > > > > > > > > > On Tue, 21 Oct 2025 at 13:34, Mike Ounsworth > > > > 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 > > > > 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=E2=80= =99t > > > > 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=E2=80=99s Useful, > > > > >>> Tushar > > > > >>> > > > > >>> On Thu, Oct 16, 2025 at 8:45=E2=80=AFAM Mike Ounsworth > > > > 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 > > > > wrote: > > > > >>>>> > > > > >>>>> 2025-10-16 03:55 GMT+02:00 Mike Ounsworth > > > > : > > > > >>>>> > > > > >>>>> 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 =F0=9F=98=8B). > > > > >>>>> > > > > >>>>> > > > > >>>>> Could be > > > > https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/2= 1 > > > > . > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> CFRG mailing list -- cfrg@irtf.org > > > > >>>> To unsubscribe send an email to cfrg-leave@irtf.org > > > > > > > > > > _______________________________________________ > > > > > Spasm mailing list -- spasm@ietf.org > > > > > To unsubscribe send an email to spasm-leave@ietf.org > > > > =20 > > > > =20 > > > > =20 > > > > --=20 > > > > Astra mortemque praestare gradatim > >=20 > >=20 > > _______________________________________________ > > CFRG mailing list -- cfrg@irtf.org > > To unsubscribe send an email to cfrg-leave@irtf.org > _______________________________________________ > CFRG mailing list -- cfrg@irtf.org > To unsubscribe send an email to cfrg-leave@irtf.org --=-w9MqpUszxHPdBTcffU2r Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Am Mittwoch, dem 22.10.2025 um 07:46 -0500 schrie= b Thad Thompson:
> Impl= ementations 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 priva= te keys forged in the fires of Mount Doom. One does not simply tell their b= oss (and customers) "no problem, we'll just go off spec." 
<= br>
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 enf= orced) that X25519 keys generated through other means cannot be used.
=
Is this a MUST requirement? Where is the reasoning in particlar for X2= 5519 and X448? If it is a MUST, somewhere in the document should be an expl= anation on why it is done such that other KEMs can make an informed decisio= n how to place limitations on their (private) keys in a similar fashion.

BR



On Tue, Oct = 21, 2025 at 6:06=E2=80=AFPM Filippo Valsorda <filippo@ml.filippo.io> 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-concre= te-hybrid-kems-01, Section 3.1.1. (I also find it hard to navigate the spli= t in documents.)

I have reproduced them below for = you. I am certain you can implement them with any major cryptography librar= y. 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 =3D c + 1" instead of checking "c > 0"), so I= am not sure what relevance it has here: there is no such thing as a standa= rd 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 tha= t argument persuasive.

Implementations can obvious= ly 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) =3D expandDecapsKeyG(seed)
    return (concat(ek_PQ, ek_T), seed)
def expandDecapsKeyG(seed):
    seed_full =3D PRG(seed)
    (seed_PQ, seed_T) =3D split(KEM_PQ.Nseed, Group_T.Nseed, seed_full)

    (ek_PQ, dk_PQ) =3D KEM_PQ.DeriveKeyPair(seed_PQ)
    dk_T =3D Group_T.RandomScalar(seed_T)
    ek_T =3D Group_T.Exp(Group_T.g, dk_T)

    return (ek_PQ, ek_T, dk_PQ, dk_T)
def RandomScalar(seed):
  state =3D XOF.Init(seed)
  sk =3D OS2IP(XOF.Read(state, Nscalar))
  while sk =3D=3D 0 || sk >=3D order:
    sk =3D OS2IP(XOF.Read(state, Nscalar))
  return (sk, pk(sk))
(The XOF is SHAKE256, Nseed/N= scalar is 32 for P-256, and 48 for P-384.)

202= 5-10-22 00:31 GMT+02:00 Mike Ounsworth <ounsworth+ietf@gmail.com>:
Hi Watson,

SP 800-56A section 5.6.1 defines = the FIPS-approved ways of deriving a ECDH key. You can't derive your k= eys 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 k= eys, and that's the whole story.

On Tue, 21 Oct 2025 at 14:23, Watson Ladd <watsonbladd@gmail.com> wrote:
On Tue, Oct 21, 2025 at 12:14=E2=80=AFPM= Mike Ounsworth
>=
> Follow-up: I see that DHKEM.DeriveKeyPair(ikm) is defined = in RFC9180:
>
> 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 deriv= ation is not defined for ECDH in general.
>
> S= o, on that grounds, I object to draft-irtf-cfrg-concrete-hybrid-kems RECOMM= ENDING 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 singl= e IETF protocol, and most importantly to me, does not exist in FIPS or curr= ent cryptographic libraries.

I don't understand:= HKDF (or the underlying hash function worst case)
absolutely do= es 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 <= ;ounsworth+= ietf@gmail.com> wrote:
>>
>> Hi CF= RG and HPKE,
>>
>> I just want to give an= update on this. Richard and I did some more cross-testing this week, and w= e are at an impasse on the SEC-P curves, and it has to do with the seeds. T= he CFRG /HPKE draft stores the hybrid private keys as a seed, so you have t= o re-derive the P256 half from a seed. My problem is that ECDH is a thing t= hat 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 t= op of the core python cryptography library, and I cannot implement the CRFG= / HPKE draft that way. Python crypto has this:
>> but that appears to not derive the same keys as= Richard's implementation.
>>
>> The issu= e is that EC.derive_priv_from_seed() is not a standardized function. You ca= n probably infer from a careful read of [SEC1] or [SP.800-56A] what it need= s to be, but it is not actually standardized or FIPS-allowed. It requires m= ucking around with EC point multiplication. The fact that it's not a standa= rdized thing means that I will likely not be the last person to have intero= p problems with this. Maybe my issues are as simple as not using that pytho= n 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 k= ind of mess you get into when you use non-standardized APIs for existing 20= year-old primitives.
>>
>> So at this po= int, I think we have to declare non-compatibility between LAMPS and HPKE Hy= brid KEMs. Since our X-Wings are compatible, we know that our QSF framework= s 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 <tjpatel.tl@gmail.com> wrote:
>>>
>= ;>> Sorry, jumping in a running train and
>>> man= y 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 li= brary, the fixed code is with a previous employer, 64-bit and 128-bit in JS= ON libs are a mess or sign bit issues in general.
>>>
>>> Also, please make sure that you are parsing the comp= ressed notations for ECC correctly, some libraries pack those incorrectly a= nd also wrote my own ASN.1 parsers for some elements, you might be surprise= d where I hit these areas, can=E2=80=99t disclose, though both were from re= puted organizations.
>>>
>>> Last, = please make sure you have matching generators and incorporate the affine an= d infinity checks, these may translate to all sorts of weird issues that ar= e impossible to debug through OSS macros in most cases.
>>= >
>>> There is substandard ECC, ECDSA and ECDHE at m= any places in OSS libs and you may have to debug these.
>>= >
>>> Personally, I think NIST should mandate pristi= ne implementations as companies spend a lot more time fixing other implemen= tations than their own.
>>>
>>> Hop= e it=E2=80=99s Useful,
>>> Tushar
>>&g= t;
>>> On Thu, Oct 16, 2025 at 8:45=E2=80=AFAM Mike Oun= sworth <= ounsworth+ietf@gmail.com> wrote:
>>>>
>>>> Thanks Filippo,
>>>>
= >>>> Richard and I did some debugging last night. He gave me n= ew test vectors that include that bug fix to the P256 / P384 constants.
>>>>
>>>> My current theory is t= hat the code I quickly whipped up to do a P256 private key expansion from s= eed does not match Richard's. Since this is wholly out of scope for LAMPS C= omposite (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 / P38= 4 private key so that we don't need to debug through the P256-from-seed stu= ff. Anyway, this is all good validation of both our test vectors.
>>>>
>>>> Anyway, making progress!
>>>>
>>>> On Thu, 16 Oct 2025 at= 10:29, Filippo Valsorda <filippo@ml.filippo.io> wrote:
>>>&g= t;>
>>>>> 2025-10-16 03:55 GMT+02:00 Mike Ouns= worth <o= unsworth+ietf@gmail.com>:
>>>>>
= >>>>> Results: we are cross-compatible on X-Wing, but not o= n P256 (and that's after hacking my script to use the CFRG label not the LA= MPS label, so there's clearly some other bug at play, but I have no idea wh= at, so of course I assume it's on the cfrg reference impl side =F0=9F=98=8B= ).
>>>>>
>>>>>
>>>>> Could be https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/21.<= /div>
>>>>
>>>> ___________________= ____________________________
>>>> CFRG mailing list = -- cfrg@irtf.org
>>>> To unsubscribe send an email to cfrg-leave@irtf.org
&= gt;
> _______________________________________________
> Spasm mailing list -- spasm@ietf.org
> To unsubscribe send an email to = spasm-leave@ietf.= org



--
Astra mortemque praestare gradatim

_____________________________________________= __
CFRG mailing list -- cfrg@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
_______________________________________________
CFRG mailing list -- cfrg@irtf.org<= /a>

=
--=-w9MqpUszxHPdBTcffU2r-- --=-rcAc/EPUWrmqeiNqSoPm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQJMBAABCgA2FiEEPREGPBD5jRS9JNFHCwmY74b1m2oFAmj/UaMYHG1zY2hhbnpl bmJhY2hAcG9zdGVvLmRlAAoJEAsJmO+G9Ztq2BkQAJVDUo4CeB07vjEVqpDWVOID BodFSC+OVCnuzljkLst98FkG7OZcZJYKUHuH0oKHaN+yBYl0JFcPZr5acUscCLy2 X8HOUc0CFyNm5di2bRCMPuY9++LUuj5pZafdaOM+BaaNUhe4//J2fOq8rkFXB8ka BigjO9lH/1p/RlTRtvzWKRQ4H+5HCYFZckyl69bMEZxCcUvO5fc7tYngxSmL5VeN Yj/jBuz8sfYjd4PSIcDwXQBhuGa6H43IRUJS+JiNMXowS9BKBOGTaGqjdLqZCLFa TIZrsb+mLXCFS6XgKAwVvU6YoSIjKhnop5JGkflZrS3ALWpFM2NIs3pZ4kPuukvW /79lP+eUl9HG9xXVaPpZLguz15bdDrhCO97zQBiYeIl+YCPdC1mCQ5gOhSy2748L T3hHkCHX29LPDc3GTx40HDBhMN5JE/btSz3BIcJ1I411g0nlb2FDAwnUfm+MgtEB WTM3p9iFT5e41nlSl+KK1XuqAsDMaFEinTIok4g/NaJxFq4j3vbgC2N6ZcopZsl7 0cFvACnTT+Y3U02zOwsvRrRhNz+MvAKAVuKnbFe3nRJ4O8HkM5bUZl/NDrK4G+Mr 9kBw3XHtJTUKs11SyfoQb7hna7outnCDK45gGC73qTdsGXB/FZ50OEtqnn2q8nqv N/lKJxabDcX1xA5Kn9BS =aUDj -----END PGP SIGNATURE----- --=-rcAc/EPUWrmqeiNqSoPm--