| name | vrf-auditor |
| description | Audit Verifiable Random Function implementations (RFC 9381 ECVRF and RSA-FDH-VRF) for key validation, ciphersuite/suite-string domain separation, encode-to-curve and cofactor handling, proof-to-hash ordering, and uniqueness/pseudorandomness assumptions, plus application-level output grinding. Use when reviewing VRF provers, verifiers, or consumers of VRF outputs (leader election, lotteries, randomness beacons).
|
| allowed-tools | ["Read","Grep","Glob","Bash"] |
vrf-auditor
Domain auditor for VRFs: proof generation, verification, and the trust
rules consumers must follow before treating a VRF output as random.
When to Use
- Auditing RFC 9381 ECVRF (any ciphersuite) or RSA-FDH-VRF provers and
verifiers
- Reviewing encode_to_curve/hash_to_curve usage, cofactor handling, and
ciphersuite/suite-string domain separation
- Reviewing proof_to_hash ordering and whether outputs are consumed before
verification
- Assessing uniqueness (full uniqueness vs trusted-key uniqueness),
pseudorandomness assumptions, and application-level grinding resistance
When NOT to Use
- VDF sequential-delay proofs (Wesolowski/Pietrzak) ->
vdf-auditor
- Ordinary signature scheme review without VRF output semantics ->
signature-scheme-auditor
- Elliptic-curve point validation/subgroup mechanics in isolation ->
ecc-pairing-auditor
- Nonce/CSPRNG generation mechanics ->
randomness-auditor
- Line-by-line RFC conformance diffing ->
spec-delta-checker
Core Review Areas
- Key validation: ECVRF public keys decoded and validated per the
ciphersuite's validate_key rules (small-order/identity rejection for
full uniqueness/collision resistance claims); RSA key sanity
- Domain separation: suite string, DST, and challenge-generation
separation octets exactly per RFC 9381; no cross-suite or cross-protocol
hash reuse
- encode_to_curve: correct method for the ciphersuite (TAI vs
hash_to_curve per RFC 9380), including the salt and loop rules
- Cofactor handling: Gamma multiplied by the cofactor in proof_to_hash;
verification equation component checks
- Nonce generation in proving: RFC 9381 §5.4.2 deterministic derivation
(RFC 6979-style / RFC 8032-style) — reuse leaks the secret key
- proof_to_hash ordering: beta computed only from a proof that verified;
consumers must never use outputs before verify returns VALID
- Uniqueness and pseudorandomness caveats: which property holds for
adversarial keys under the chosen ciphersuite, and whether the
application needs full uniqueness
- Application grinding: can a participant re-key, re-input, or withhold
outputs to bias the consuming protocol (leader election, lotteries)
Workflow
Phase 1: Construction and ciphersuite mapping
- Read
references/vrf-checklist.md
- Pin the exact construction (ECVRF ciphersuite ID or RSA-FDH-VRF
parameters) and the RFC 9381 sections that govern it
Phase 2: Prove/verify path review
- Execute
workflows/vrf-review.md
Phase 3: Pattern hunt
- Read
references/finding-patterns.md
- Prioritize outputs used before verification, missing key validation,
wrong cofactor handling, and grinding-by-withholding
Phase 4: Handoff
- Send surviving findings to
crypto-fp-check
- Cross-route RFC conformance deltas to
spec-delta-checker, EC point
rules to ecc-pairing-auditor, and nonce generation to
randomness-auditor
Output Contract
Produce a VRF handoff that includes:
vrf_familyprove_or_verify_pathuniqueness_or_pseudorandomness_invariantevidencedisposition (one of verified, false_positive, unverified,
observation, residual_risk)next_route
Reference Index
