| name | signature-scheme-auditor |
| description | Audit classical signature schemes — generic ECDSA across curves, Schnorr/ BIP-340, EdDSA/Ed25519, RSA-PSS and PKCS#1 v1.5 — for verification-equation correctness, malleability, canonical encoding, public-key validation, and hash/prehash semantics. Use for standalone signature library review outside Ethereum application encoding, BLS, or threshold protocols.
|
| allowed-tools | ["Read","Grep","Glob","Bash"] |
signature-scheme-auditor
Domain auditor for classical single-party signature schemes: the
verification equations, encodings, and key-validation rules of ECDSA,
Schnorr/BIP-340, EdDSA, and RSA signatures.
When to Use
- Auditing generic ECDSA signing/verification across ecosystems and curves
(P-256, secp256k1, brainpool, etc.)
- Reviewing Schnorr and BIP-340 x-only key handling, tagged hashes, and
verification equations
- Reviewing EdDSA/Ed25519 canonical encoding, cofactor semantics, and
batch/single verification consistency
- Reviewing RSA-PSS and PKCS#1 v1.5 verification and padding rules
- Assessing malleability, public-key validation, and hash/prehash semantics
When NOT to Use
- Ethereum-specific EIP-712, ecrecover, or application encoding ->
ethereum-crypto-auditor
- BLS signatures, pairings, aggregation ->
ecc-pairing-auditor
- Threshold schemes ->
dkg-threshold-auditor (FROST/MuSig2) or
threshold-ecdsa-auditor (GG/CGGMP)
- Nonce generation/derivation mechanics ->
randomness-auditor
- Fault-attack resistance of signing hardware paths ->
implementation-safety skills (verify-after-sign handoff)
Core Review Areas
- Verification equations: exact equation per scheme, all components
checked (never trusting a library's partial verification)
- Range and canonicality: ECDSA r,s in [1, n-1]; Ed25519 s < L and
canonical point encodings; BIP-340 x-only lift and even-y convention;
PSS salt and v1.5 DigestInfo strictness
- Malleability: ECDSA (r, s)/(r, n-s); Ed25519 non-canonical s or A;
scheme-level implications for consumers that key on signature bytes
- Public-key validation: on-curve, non-identity, correct subgroup (or
cofactored equation), small-order rejection policy
- Hash and prehash semantics: which hash, truncation rules
(FIPS 186-5 leftmost-bits), Ed25519ph/ctx variants, cross-protocol
hash-domain reuse
- Batch vs single consistency: batch equations (cofactored) accepting what
single (cofactorless) rejects, and consensus divergence risk
- Nonce integration: signing paths call correct derivation (RFC 6979 /
RFC 8032) — deep RNG review hands off to
randomness-auditor
- Verify-after-sign and fault-check posture at the API boundary
Workflow
Phase 1: Scheme inventory
- Read
references/signature-scheme-checklist.md
- Identify every scheme/curve/hash triple in scope and the governing
standard for each
Phase 2: Verification-path review
- Execute
workflows/signature-verification-review.md
Phase 3: Pattern hunt
- Read
references/finding-patterns.md
- Prioritize missing range checks, permissive decoders, batch/single
divergence, and v1.5 parsing tolerance
Phase 4: Handoff
- Send surviving findings to
crypto-fp-check
- Cross-route nonce lifecycle to
randomness-auditor, Ethereum encoding to
ethereum-crypto-auditor, BLS/pairing math to ecc-pairing-auditor
Output Contract
Produce a signature-scheme handoff that includes:
signature_familyverification_or_signing_pathequation_or_encoding_invariantevidencedisposition (one of verified, false_positive, unverified,
observation, residual_risk)next_route
Reference Index
