nx_p256_ecdh.nx

nx_p256_ecdh.nx -- ECDH key exchange on P-256 (secp256r1) for the TLS 1.3 key_share path (browser arc rung B4-P256-KEYSHARE). The P-256 stack (field, point, scalar_mul) shipped for ECDSA cert VERIFICATION; this module composes the same primitives into the ECDHE role so the ClientHello can carry a secp256r1 KeyShareEntry next to the X25519 one. Servers that insist on P-256 (the AWS- fronted class behind the B2-HTTPBIN-CH alert) then never need a HelloRetryRequest: they just pick our P-256 share. Public API: p256_ecdh_derive_priv(seed32, out_priv32) -> verdict Domain-separated ephemeral: SHA-256("NISHI-TLS13-P256-ECDH-V1" || seed32), reduced mod n, forced nonzero. Lets the session grow a P-256 keypair from the caller's existing 32 random bytes without changing the session-new entropy contract. p256_ecdh_pub(priv32, out_pub65) -> verdict out = 0x04 || X || Y (RFC 8446 wire form for secp256r1). p256_ecdh_shared(priv32, peer_pub65, peer_len, out_shared32) -> verdict Validates peer point (format, on-curve, not-infinity) then writes the x-coordinate of priv * peer as the 32-byte shared secret (RFC 8446 section 7.4.2). Variable-time scalar_mul note: the scalar here is an EPHEMERAL per-session secret, unlike ECDSA verify's public scalars. The shipped double-and-add is variable-time; constant-time ladder is a named follow-up rung (same lane as the x25519 ladder), accepted for B4 because the scalar lives for one handshake. KAT: RFC 5903 section 8.1 vectors in nx_p256_keyshare_test.nx (vectors re-read from rfc-editor.org 2026-06-10, not from memory). license_tier: INDEPENDENT_REDERIVE genealogy_id: international-research-sources/ietf/rfc_5903 + ietf/rfc_8446 lineage_id: nishi_p256_ecdh_q10