Field notes on differential testing, fuzzing, and the security of multi-implementation systems — Ethereum clients, cryptographic libraries, and compilers.
In a system with more than one implementation there is no ground truth available to the test harness — only witnesses that can disagree. That changes how I test Ethereum clients, cryptographic libraries, compilers, and AI-assisted security pipelines.
The KEM keeps a web conversation private; the signature decides whom you're talking to. I differential-fuzzed ML-DSA-65 across CIRCL, BoringSSL, and mldsa-native — and the real lesson wasn't the clean negative. It's that a clean negative is worth exactly as much as the coverage behind it, and my first attempt had a hole big enough to drive 16 million executions through without noticing.
We obsess over test inputs and coverage and almost never examine the oracle — the thing that decides an answer was correct. A passing test isn't proof of correctness; it's a statement that the system and its oracle agree. Here's why that distinction is suddenly everyone's problem, especially in how we evaluate AI.
Part 2 of 3. G1, a §7.3 hash-check gap in BoringSSL found by reading rather than fuzzing; the assurance-coverage share across the encrypted web; who each finding affects; and the Compress/Decompress clean sweep.
Part 1 of 3. One in twelve web connections rides X25519MLKEM768. I wired the five ML-KEM libraries behind it into one diff-fuzz harness — and it caught F1, a FIPS 203 §7.2 modulus-check bypass in CIRCL's expanded-SK parser.