nx_tls13_transcript.nx

nx_tls13_transcript.nx -- TLS 1.3 transcript hash (RFC 8446 §4.4.1). Phase 0b §E of the Nishi TLS 1.3 stack per docs/NISHI_TLS13_GAP_AUDIT.md. Running SHA-256 over the concatenation of every handshake message in send/receive order, with the HelloRetryRequest synthetic-message replacement special case. Every Derive-Secret call in the schedule and the Finished MAC's HMAC(transcript_hash) all read from this state. The HRR rule: When the server responds to ClientHello with HelloRetryRequest, the value of ClientHello1 in the transcript is REPLACED with a special synthetic handshake message of type message_hash(254) containing Hash(ClientHello1). Every subsequent Derive-Secret computation sees this replaced prefix, not the original CH1. This exists so that the handshake transcript stays ~constant-size on resumption regardless of how large the original ClientHello was (the original CH1 might carry an arbitrarily large pre_shared_key extension). What it does today: - init / update / snapshot (non-destructive get) - HRR replace via synthetic-message-hash construction - sealed verdict + validity gate What it doesn't do yet: - SHA-384 variant (queued; composes against nx_sha512 / nx_sha384 if/when that's wired) - Multi-buffer message append (caller can call update() multiple times instead; covered by streaming SHA-256 already) KAT verified: - empty transcript -> SHA-256("") = e3b0c4...b855 - 3-message concatenation matches sha256_digest of the same bytes - snapshot non-destructive (subsequent update changes hash) - HRR replace produces transcript whose hash equals SHA-256(synthetic_message_hash_record) Composes with: