nx_chacha20_extvec_gate.nx

nx_chacha20_extvec_gate.nx -- FIFTH provably third-party-validated claim: ChaCha20 block function vs RFC 8439 2.3.2, read from the same pinned document the Poly1305 gate uses. ★★★★★THIS GATE EXISTS BECAUSE ONE DOCUMENT CONTAINS TWO DIALECTS. RFC 8439 states its INPUTS as colon-separated hex (Key = 00:01:...) and its OUTPUT as a HEXDUMP with an offset column and an ASCII gutter: 000 10 f1 e7 e4 d1 3b 59 15 50 0f dd 1f a3 20 71 c4 .....;Y.P.... q. 032 d2 82 64 46 07 9f aa 09 14 c2 d7 05 d9 8b 02 a2 ..dF............ The nibble-stream reader that is CORRECT for the Poly1305 section would produce COMPLETE GARBAGE here: it would swallow the offset column (000/016/032/048 -- every character hex-valid) and then the ASCII gutter (d, F, 3, a, b ... all hex-valid). ★A PARSER PROVEN ON ONE SECTION IS NOT PROVEN ON THE DOCUMENT. THE DISCRIMINATOR, chosen by looking at the layout rather than by guessing: a data byte is a whitespace-delimited token of EXACTLY TWO hex characters. The offset is three characters; the ASCII gutter contains no two-character all-hex token. So "accept only 2-char all-hex tokens" cleanly selects the 64 data bytes and rejects both decorations -- no line/column arithmetic, nothing to drift. ★AND THE TARGET IS THE *SERIALIZED BLOCK*, NOT the "state after 20 rounds" printed just above it. 2.3.2 shows THREE near-identical 16-word blocks (input state, after-20-rounds, and the final serialized output = after-rounds PLUS input state). chacha20_block() returns the THIRD. Comparing against the second is a silent mis-selection that yields a confident RED against a correct implementation -- a document that shows its INTERMEDIATE STATES is more dangerous than one that shows only answers, and the discriminator is SEMANTIC (what does the function return?), never syntactic. license_tier: ORIGINAL expect_exit: 0