nx_poly1305_extvec_gate.nx

nx_poly1305_extvec_gate.nx -- FOURTH provably third-party-validated claim: Poly1305 vs RFC 8439 2.5.2. Fourth authority, fourth primitive, same construction -- but a THIRD vector dialect, which is the point: RFC 7748 plain 64-char hex runs RFC 8032 wrapped at 32 chars/line (even, so byte pairs never split) RFC 8439 COLON-SEPARATED AND WRAPS MID-BYTE: "...a8:01:0" / newline / "3:80:..." splits the byte 03 An adjacent-hex-pair parser (what the first three gates use) drops a nibble at that break and SILENTLY SHIFTS EVERY SUBSEQUENT BYTE. It does not fail loudly -- it yields a plausible wrong key, a red gate, and an hour spent blaming Poly1305 instead of the reader. ★★★★★LAW: EACH STANDARDS BODY PUBLISHES IN ITS OWN DIALECT, AND THE PARSER MUST BE PROVEN AGAINST THAT DIALECT BEFORE THE GATE'S VERDICT MEANS ANYTHING. There is no general parser, only a proven one. So this gate uses a NIBBLE-STREAM reader: accumulate hex nibbles, skip ':' and whitespace, pair them afterwards. That is immune to both colon separators and mid-byte line wraps. ⚠ONE INPUT IS TYPED, DELIBERATELY, AND HERE IS WHY IT IS STILL SOUND: the RFC gives the message as the ASCII string "Cryptographic Forum Research Group". I supply those 34 bytes rather than parsing prose out of the document. That does NOT weaken the claim, because THE ANSWER STILL COMES FROM THE DOCUMENT: if my message were wrong by one byte the computed tag would not match the published tag, and the gate would go RED. A PASS therefore proves BOTH that the message was right AND that our Poly1305 agrees with the IETF. ★The rule this respects: an agent may supply an INPUT whose correctness the published ANSWER verifies; an agent may NEVER supply the ANSWER. That distinction is the whole of the third-party property. license_tier: ORIGINAL expect_exit: 0