crypto-audit-context
Start here before claiming vulnerabilities.
Core principle: verify what the code actually enforces, not what the docs
claim.
When to Use
- Beginning a ZK or cryptographic audit
- Reading unfamiliar verifier, prover, signature, DKG, or serialization code
- Building a threat model before bug hunting
- Prioritizing which files and functions deserve the deepest review first
When NOT to Use
- Verifying whether a specific suspected finding is a true positive
- Writing final severity decisions or report-ready findings
- Querying prior-art or disclosure state
Audit Priority
Review highest-risk code first:
- Critical path —
verify, batch_verify, deserialize, from_bytes, transcript/challenge generation, keygen, sign, prove
- Trust boundary —
unsafe blocks, FFI modules, unchecked constructors, parameter loading
- Supporting — caches, zeroization, type conversions, error conversion, optimized backends
Rationalizations to Reject
| Rationalization |
Why it is wrong |
| "The README explains the architecture" |
READMEs describe intent, not enforcement |
| "I'll map trust boundaries later during domain review" |
Domain skills assume the dimension map is already built |
| "The codebase is small, I can hold the context in my head" |
Small codebases have the same attack-surface density |
Workflow
Phase 1: Map the critical path
- Identify verifier, transcript, parsing, and randomness entrypoints
- Mark code that handles attacker-controlled or externally supplied values
Phase 2: Build the dimension map
- Read
references/dimensional-analysis.md
- Assign dimensions to values that cross trust boundaries
- Treat every unknown or inherited dimension as suspicious until proven safe
Phase 3: Build the protocol threat model
- Read
references/threat-model-checklist.md
- Record replay surfaces, authentication roots, downgrade surfaces, and corruption model assumptions
Phase 4: Produce the audit handoff
- Summarize the highest-risk paths
- Name unresolved assumptions
- Hand off to a domain auditor or verification skill
- Initialize or update session state in
zk-findings/sessions/<engagement-id>.json
using zk-findings/sessions/session-state-schema.json
- Persist trust boundaries, open findings, and next-step routes so follow-on
conversations continue from the same state
Output Contract
Produce a context handoff that includes:
- Critical paths and trust boundaries that deserve deepest review
- Dimension-map anomalies and unresolved assumptions
- Threat-model notes that the next skill must preserve
- Recommended next skills, with a brief reason for each route
- Session state path updated in
zk-findings/sessions/ for downstream handoffs
Reference Index
- references/dimensional-analysis.md
- references/threat-model-checklist.md
1---2name: crypto-audit-context-23description: Builds initial audit context for ZK and cryptographic code before vulnerability hunting. Use when starting a crypto audit, mapping trust boundaries, prioritizing code paths, or applying dimensional analysis to protocol values.4---56# crypto-audit-context78Start here before claiming vulnerabilities.910**Core principle:** verify what the code actually enforces, not what the docs11claim.1213## When to Use1415- Beginning a ZK or cryptographic audit16- Reading unfamiliar verifier, prover, signature, DKG, or serialization code17- Building a threat model before bug hunting18- Prioritizing which files and functions deserve the deepest review first1920## When NOT to Use2122- Verifying whether a specific suspected finding is a true positive23- Writing final severity decisions or report-ready findings24- Querying prior-art or disclosure state2526## Audit Priority2728Review highest-risk code first:29301. **Critical path** — `verify`, `batch_verify`, `deserialize`, `from_bytes`, transcript/challenge generation, `keygen`, `sign`, `prove`312. **Trust boundary** — `unsafe` blocks, FFI modules, unchecked constructors, parameter loading323. **Supporting** — caches, zeroization, type conversions, error conversion, optimized backends3334## Rationalizations to Reject3536| Rationalization | Why it is wrong |37|---|---|38| "The README explains the architecture" | READMEs describe intent, not enforcement |39| "I'll map trust boundaries later during domain review" | Domain skills assume the dimension map is already built |40| "The codebase is small, I can hold the context in my head" | Small codebases have the same attack-surface density |4142## Workflow4344### Phase 1: Map the critical path4546- Identify verifier, transcript, parsing, and randomness entrypoints47- Mark code that handles attacker-controlled or externally supplied values4849### Phase 2: Build the dimension map5051- Read `references/dimensional-analysis.md`52- Assign dimensions to values that cross trust boundaries53- Treat every unknown or inherited dimension as suspicious until proven safe5455### Phase 3: Build the protocol threat model5657- Read `references/threat-model-checklist.md`58- Record replay surfaces, authentication roots, downgrade surfaces, and corruption model assumptions5960### Phase 4: Produce the audit handoff6162- Summarize the highest-risk paths63- Name unresolved assumptions64- Hand off to a domain auditor or verification skill65- Initialize or update session state in `zk-findings/sessions/<engagement-id>.json`66 using `zk-findings/sessions/session-state-schema.json`67- Persist trust boundaries, open findings, and next-step routes so follow-on68 conversations continue from the same state6970## Output Contract7172Produce a context handoff that includes:7374- Critical paths and trust boundaries that deserve deepest review75- Dimension-map anomalies and unresolved assumptions76- Threat-model notes that the next skill must preserve77- Recommended next skills, with a brief reason for each route78- Session state path updated in `zk-findings/sessions/` for downstream handoffs7980## Reference Index8182- [references/dimensional-analysis.md](references/dimensional-analysis.md)83- [references/threat-model-checklist.md](references/threat-model-checklist.md)
Yue-Zhou1