README

Generated bytes fed to the code that parses what comes off the wire.

Rounds one to ten asked prepared questions.  This one asks whether anything
breaks on input nobody chose.  What is looked for is memory safety rather
than wrong answers: these inputs are meant to be rejected, and the question is
how they are rejected.

The harnesses are the places where bytes from elsewhere are taken apart:

  ed25519  a public key and a signature, both the sender's to choose
  decaf    point decoding, EdDSA public key decoding, Ed448 verification
  p256     a point checked for being on the curve, then multiplied
  aead     AES-GCM decryption, with the iv, aad and tag lengths from the wire
  canary   the calibration

fuzz_canary reads one byte past a buffer when the input opens with four
particular bytes.  Four is the point: one chance in 2^32 puts it out of reach
of throwing random input at the harness, and well within reach of a fuzzer
that watches which comparisons it got past.  So a campaign that does not
report the canary is not exploring, and the silence of the others would mean
nothing.  Round five believed a ThreadSanitizer zero that meant nothing and
round ten twice believed a scrubbing zero that meant nothing; this is cheaper
than learning it a third time.

The corpus is seeded with inputs each harness accepts -- a signature that
verifies, the same with one bit of the message moved, a point that is on the
curve, a ciphertext that authenticates -- so that a campaign starts from the
far side of the checks rather than in front of them.  They were generated by
running the primitives, and checked: the valid signature verifies, the
tampered one does not, the point is on the curve.

Where clang has no libFuzzer runtime -- Apple's does not -- run.sh replays the
corpus and a deterministic stream through standalone.c instead.  That says the
harnesses build and run clean under the sanitizers.  It explores nothing, and
it says so rather than reporting a pass.