Crypto Theorem Review

Crypto Theorem Review

Audit the exact mathematical object supplied. Keep statement validity, proof completeness, reduction validity, and protocol security as separate conclusions.

Scope

In scope:

• review a supplied theorem, lemma, proof, proof sketch, reduction, game sequence, or formal security argument;
• reconstruct omitted steps when possible while marking them as reviewer reconstruction;
• inspect cited dependencies and document versions when accessible;
• audit assumptions, adversary/setup model, parameters, probability bounds, reduction loss, and complexity;
• report which protocol-level claim follows from the reviewed result.

Out of scope:

• open-ended literature discovery, general paper summarization, prose-only polishing, implementation/side-channel certification, or inventing a missing proof;
• claiming mechanized verification unless the intended checker actually ran successfully on the identified artifact;
• editing or publishing the source artifact unless separately requested.

Required Inputs

• exact statement and proof/argument text or formal artifact;
• stable artifact identity: file/version/hash/date or publication version and theorem location;
• definitions, assumptions, notation, parameter regime, and cited dependencies needed by the argument;
• claimed security notion/model and desired review depth.

If the exact statement or argument is missing, ask for it and stop the verdict. Infer only notation or low-risk presentation details, and label every inference.

Success Criteria

• Every consequential claim has a type and evidence status.
• Statement, proof, reduction, and security implication receive separate verdicts.
• Every blocking gap has a location, missing obligation, consequence, and evidence required to resolve it.
• Security notion, adversary powers, setup/model, assumptions, parameter regime, and concrete reduction loss are recorded when applicable.
• Citations and theorem/section numbers are checked against the inspected version or marked unverified.
• Parameters, probability/failure terms, asymptotic variables, and concrete cost models are internally consistent or receive findings.
• The final conclusion is bounded by the evidence actually inspected.

Failure Modes

• Missing or inaccessible dependency: mark all dependent steps unverified; never infer the cited result from title, snippet, or memory.
• Conflicting versions: preserve each version, identify the one reviewed, and report changed hypotheses, numbering, or conclusions.
• Undefined notation or parameters: request only research-critical definitions; otherwise give a partial syntactic review with the limitation visible.
• Proof gap: record it; any reviewer-supplied repair is a proposed lemma/argument, not verification of the original proof.
• Unavailable checker: perform manual review only and state that mechanized verification was not executed.
• Unsupported security upgrade: return the narrower theorem/model actually supported.

Never fabricate a citation, theorem statement, proof step, parameter value, checker run, reduction, or security conclusion.

Workflow

1. Freeze the exact object, version, requested depth, and conclusion boundary.
2. Apply core-review-protocol.md to classify claims, normalize the statement, build proof obligations, and audit local reasoning, games, reductions, citations, parameters, and implications.
3. If the result concerns a ZKP, proof/argument of knowledge, Fiat-Shamir transform, polynomial commitment, recursion, folding, aggregation, or IVC, apply zkp-review.md.
4. If it concerns LWE/SIS or a ring/module/structured lattice assumption, reduction, distribution, norm, correctness bound, or concrete security estimate, apply lattice-review.md.
5. Run an available formal checker only when the supplied artifact targets it; retain the checker/version/configuration and raw success/failure status.
6. Produce report-schema.md. Keep verified, supported-with-limitations, unverified, contradicted, and not-assessable statuses distinct.
7. When evaluating this skill itself, use evaluation-scenarios.md; do not claim those scenarios ran unless independent fresh-context outputs were inspected.

Output Contract

Return, in order:

1. reviewed object and exact version;
2. scope and evidence inspected;
3. statement verdict;
4. proof verdict and obligation table;
5. reduction/security implication verdict;
6. ZKP/lattice findings when applicable;
7. parameter, probability, and complexity ledger/findings;
8. citations checked and version discrepancies;
9. blocking, major, and minor findings;
10. unverified items and bounded conclusion.