nx_x25519_extvec_gate.nx

nx_x25519_extvec_gate.nx -- THE FIRST PROVABLY THIRD-PARTY-VALIDATED CLAIM. Proven GREEN on the laptop 2026-07-31 (pass=2 fail=0). Shipped here so it runs where claims are served. Every other KAT in this corpus embeds its expected values as constants a developer copied out of a specification. Honest work, but NOT provably external: nothing in the artifact distinguishes a value transcribed from the IETF from one an author -- or an AGENT -- merely believed. This gate closes that: 1 it reads the vectors FROM knowledge/extvec/rfc7748.txt AT RUN TIME. NO expected value appears in this source at all, so there is nothing here for anyone to have mistyped or invented. 2 it PINS the acquisition digest: the file must sha256 to the value nx_vecfetch computed IN-PROCESS, at the socket, before the bytes ever touched disk. Edited, truncated or substituted -> pin fails. 3 only then does it run x25519() and compare. THE PIN IS THE SECURITY PROPERTY, NOT THE RUN-TIME PARSE. Parsing from a file is necessary but NOT sufficient: an agent could edit the fetched file to contain whatever answers make its implementation pass, and the parse would faithfully read the forgery. Pinning to an ACQUISITION-TIME digest is what turns "we read it from a file" into evidence. AND THE PIN MAKES TRANSPORT UNTRUSTED-BUT-VERIFIED: whoever carries rfc7748.txt to this host -- scp, an agent, a USB stick -- cannot corrupt it undetected, because sha256 preimage resistance means bytes that hash to ab200228.. ARE the fetched bytes. The carrier never has to be trusted. That is the whole point of content-addressing, and it is why this gate is safe to ship even though its data file is not. TO MAKE IT GREEN HERE: place knowledge/extvec/rfc7748.txt (any byte-exact copy; the pin checks it), or build+run nx_vecfetch on this host. Until then it reports RED-and-honest: absent file, never a fallback to constants. license_tier: ORIGINAL expect_exit: 0