Verify the claims
ZIFFER is built on an open specification, and the claims on this site are meant to replay on your machine rather than be believed.
Every claim ZIFFER makes about what it refuses is a claim you can run.
The open specification
The decision rules, the wire formats and the conformance suites are published under an open specification, with a reference implementation beside them. It is public because a security argument nobody can read is a security argument nobody can check.
Replay it
Clone the repository and run the suites. No account, no key, no network:
./tools/verify.sh --suitesThat command runs the proofs, the conformance suites and the external-corpus harness, and prints one result line per suite. If a claim on this site does not replay on your machine, do not believe it.
The full gate is a second command, and it is deliberately not this one: it also checks the release signature, which only the key holder can make green. A gate you cannot run is not a gate, so the one above needs nothing you do not have.
What the suites actually check
The interesting part is not that the checks pass. It is that they have been made to fail on purpose.
Each control is verified by deleting it and confirming the matching attack then succeeds. A check that kills no attack is not a control, and at least one check has been removed from the reference implementation on those grounds rather than kept as reassurance.
What it does not prove
Passing the conformance vectors is a partial claim, and the specification says so in as many words.
- Vectors express input to verdict. They do not express ordering properties, behaviour under a network partition, or the deletion tests above. Those are per-implementation obligations.
- Signatures are not portable between implementations. Signing is randomised unless a deployment pins it, so a vector carrying a signature could not be checked without also carrying key material.
- Some parts are disclosed as open rather than closed. They are listed as open in the repository, not omitted from it.
Why the specification is separate from ZIFFER
The specification is not ZIFFER's property. Implementers are the people who have to trust it, and nobody implements one vendor's private format. So the protocol keeps its own name and its own repository, and ZIFFER is one implementation of it, the one you can buy.
That separation is also what makes the claims on this site checkable. You can verify the rules without asking us anything.