nx_tls13_kdf.nx

nx_tls13_kdf.nx -- TLS 1.3 HKDF-Expand-Label + Derive-Secret (RFC 8446 §7.1). Phase 0b §C of the Nishi TLS 1.3 stack per docs/NISHI_TLS13_GAP_AUDIT.md. The thin TLS-specific wrapper over plain HKDF-Expand that prepends the "tls13 " literal label and length-prefixes the label + context per the spec's HkdfLabel struct. Every traffic key, handshake secret, application secret, and Finished MAC key in TLS 1.3 derives from this. HkdfLabel layout (RFC 8446 §7.1): struct { uint16 length; // big-endian opaque label<7..255>; // = "tls13 " || Label // 1-byte length prefix opaque context<0..255>; // 1-byte length prefix } HkdfLabel; Then: HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand(Secret, HkdfLabel, Length). Derive-Secret is convenience: Context = Transcript-Hash(Messages), Length = hash output (32 for SHA-256, 48 for SHA-384). What it does today: - build HkdfLabel struct into a caller buffer - HKDF-Expand-Label one-shot - Derive-Secret one-shot (composes ExpandLabel + Transcript-Hash as caller-supplied buffer) What it doesn't do yet: - SHA-384 variant (composes against existing nx_hkdf_sha384; queued sub-phase) - Multi-block transcript-hash streaming (caller computes transcript hash via nx_sha256 incremental API) KAT verified: - HkdfLabel byte-exact construction for ("derived", empty hash, 32) - RFC 8448 §3 early_secret = HMAC-SHA256(0^32, 0^32) = 33ad0a1c607ec03b09e6cd9893680ce210adf300aa1f2660e1b22e10f170f92a