nx_tls13_hrr.nx

nx_tls13_hrr.nx -- HelloRetryRequest detection (RFC 8446 §4.1.4). Phase 0b §G of the Nishi TLS 1.3 stack per docs/NISHI_TLS13_GAP_AUDIT.md. The trivial-but-load-bearing detector that distinguishes a real ServerHello from a HelloRetryRequest -- which arrives on the wire formatted IDENTICALLY to a ServerHello but uses a specific magic value in the Random field. Per RFC 8446 §4.1.3: When sent by the server in response to a ClientHello to request a different key share or to update the cookie, HelloRetryRequest has the same structure as ServerHello but with Random set to the special value of the SHA-256 of "HelloRetryRequest": CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C Receiving a ServerHello with the legacy Random matching this value MUST be treated as a HelloRetryRequest. When the detector returns 1, the caller MUST: 1. Call nx_tls13_transcript_replace_with_hrr (already shipped Gap E) to substitute the original ClientHello with the synthetic message_hash record 2. Emit a new ClientHello with whatever the HRR's extensions asked us to change (typically a different key_share group; the supported_groups extension in the HRR tells us which) This module DOES NOT do either of the above -- it just gives the caller's state machine the boolean it needs to fork on. The rewrite of the transcript + emission of CH2 belongs in the state machine driver (Gap L). What it does today: - fill caller buffer with the 32-byte HRR magic random - boolean: is the message we just received actually HRR? What it doesn't do yet: