Cryptography Research Skills

View saved version →

---
name: crypto-ai-acknowledgements
description: Draft or review AI-use disclosures and AI Methodology sections in cryptography papers from the actual account of assistance and human checking. Distinguish research, writing, code, experiments, and formalization; do not certify proofs or infer AI use.
---

# Cryptography AI Acknowledgements

Write a concise, informative account of how the work developed, what AI and humans contributed, and what was actually checked. For a new full disclosure, prefer an **AI Methodology** section with a six-category checklist and free-form Details, following the September 2026 AITCS working-group proposal. Read the [methodology pattern and category thresholds](references/drafting-patterns.md) for that format. This is a recommended format, not an established venue requirement; preserve a requested short paragraph or local edit and the manuscript's existing placement and style.

## Establish the facts

Use the supplied account and available records. Distinguish proposals from adopted contributions, and attempted checks from successful ones. Do not infer an entire paper's history from this conversation, model capabilities, or another paper's disclosure.

Identify relevant contributions: research ideas and proofs; drafting and editing; code and experiments; formalization; and human direction, correction, extension, or checking. Distinguish originating an idea from expressing it. Credit a discarded candidate for its actual influence when material, without describing it as a final result. Name results or sections when helpful, using existing labels.

For material contributions, establish what the authors had already obtained and supplied to the tool, what it proposed, what they retained, revised, or extended, and how the resulting claims and attributions were checked. Include consequential errors, unsuccessful approaches, or limitations and their resolution when they explain the final work. Detail should be proportionate to the contribution; a list of tasks or a blanket assurance of checking does not supply this account.

Use product and model/version only when known and useful; a product name does not identify its underlying model. Unknown optional versions need not block a draft. Reuse supplied facts; ask a compact factual question or use explicit provisional placeholders for a material unknown. Never fill gaps with assurances that all proofs were verified.

When input provenance matters, distinguish the stated prompt from other known context, including supplied files, earlier conversations, or enabled memory. Do not assume the prompt exhausts the tool's context. For a reconstruction or reproducibility claim, specify the inputs received and information withheld, the checks and outputs, and any known context limitations; generating a second implementation alone does not establish independence or reproduced results.

## Draft and check the allocation of credit

- Describe substantive research assistance directly; do not reduce it to proofreading or inflate editorial help into discovery.
- Name concrete human actions. Do not attribute a check to all coauthors or infer their agreement without support. Responsibility wording can express an agreed position or a clearly proposed clause; it does not establish verification.
- Keep code review, functional tests, reproduced experiments, manual proof checking, and machine-checked formalization separate. Generated proof-assistant code needs a successful check before being called machine-checked; coverage and correspondence with the paper still matter. An agent's report does not establish human checking.
- Preserve unrelated acknowledgements, LaTeX, and local edit scope. Drafting or review alone does not require editing a manuscript file.

Separate an AI suggestion's immediate source from its intellectual lineage: a model's proposal or failure to cite prior work does not establish originality. For substantive ideas, describe established connections to prior work 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: crypto-benchmarking
description: Design, run, or audit cryptographic experiments and evidence-to-table calculations with explicit timing, communication, memory, and statistical accounting. Use for measurements and their interpretation, not protocol implementation or evaluation prose alone.
---

# Cryptography Benchmarking

Define the measured object, included operations, units, and evidence source before running or comparing experiments. Resolve the actual protocol variant, workload, setup and hardware from the project.

## Workflow

1. Fix the measurement contract: construction/configuration, workload, prepared state, timer events, concurrency, cost aggregation, repetitions and statistic. Distinguish measured facts from unknown configuration details.
2. Collect or inspect the evidence needed for the request. Preserve raw observations, failures and source/build identity; derive summaries separately. A smoke request needs bounded functional coverage, while a performance claim needs repetitions and uncertainty appropriate to that claim.
3. Establish correctness coverage for the selected configuration. When executing checks, confirm the intended tests and executable ran; for reanalysis, report the retained validation evidence and gaps. Keep protocol-required checks inside measured execution; an external diagnostic audit is a different operation.
4. Compute each execution's metric before aggregating repetitions. Reconcile formulas, units and table values, then report what the evidence supports.

Keep continuous elapsed time, party-local time, CPU work and sums of separately timed intervals distinct. Label each value as measured, rerun, inherited, derived, estimated, extrapolated or unavailable. A provider-rate calculation is an estimate, not a measured pipeline.

Functional validation, protocol correspondence, empirical performance and cryptographic security are separate conclusions. Preserve differences between the implemented sampler/configuration and the theorem's distribution; matching parameter widths does not establish matched security. Reanalysis need not trigger an expensive rerun or manuscript edits.

## References by task

- [Experiments and timing](references/experiments-and-timing.md): collecting measurements, comparing optimizations, repetition and resource accounting.
- [Optimization experiments](references/optimization-experiments.md): causal attribution, services, accelerators and distributed scaling.
- [Costs and interfaces](references/costs-and-interfaces.md): communication, rounds, workload alignment and correlation-supply estimates.
- [Evidence and tables](references/evidence-and-tables.md): reanalysis, provenance and manuscript-value reconciliation.

Load the applicable reference sections. For a calculation, return the formula, units, assumptions and result. For an experiment or project-data review, also report configuration/provenance, commands and evidence locations, correctness coverage, statistics and material limitations as relevant.

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: crypto-correlation-accounting
description: Define and compare cryptographic correlation counts, PCG expansion ratios, and throughput units by algebraic relation, domain, grouping, and denominator. Use when lanes, entries, blocks, calls, or correlation rates are ambiguous; not for protocol implementation or benchmark execution alone.
---

# Cryptographic Correlation Accounting

Give each counted output an algebraic meaning before comparing counts or rates. The word “correlation” does not make different interfaces interchangeable. Theoretical counts and expansion factors need definitions and formulas, not benchmark runs.

## Normalize the unit

- Specify the relation, domain/field, party holdings, dimensions, randomness, and shared keys or multipliers. Count one reconstructed relation once unless the metric explicitly counts shares or stored elements.
- Preserve the hierarchy from scalar entries through coordinates, vectors, blocks, batches, provider calls, and protocol executions. State coupling and requested versus padded outputs; scalar relations sharing a key need not be independent instances. An encoder's internal block is not automatically the primitive's block width.
- When connecting generation to consumption, attach validity and authentication state to the count. Separate raw, candidate, checked, usable, discarded, and consumed outputs; include the work required to reach the claimed state.
- For expansion ratios, name numerator, denominator, party aggregation, and exclusions. Keep logical output-share bits, private key bits, public parameters, setup traffic, and serialized storage distinct.
- For throughput, state the exact rate equation, field/bit width, timed phase, concurrency, and aggregation rule. A maximum of separately measured party times is a model, not measured concurrent wall time. Zero-interaction expansion does not remove setup cost.
- Preserve evidence status: reported or derived, measured or modeled, original or inherited. Scalarization alone does not justify protocol throughput; check consumption shape, coupling, scaling, overlap, and excluded work. Use “speedup” only for a comparable workload.

Read [relation and rate method](references/relation-and-rate-method.md) for grouped outputs, separate correlation-pool and communication counts, usable-output accounting, cross-construction comparisons, or rate conversions. It contains optional worksheets and equations; use only the fields the question needs.

Return the defining relation, reversible conversion, assumptions, and evidence status, adding timed operations when rates are involved. Prefer an explicit unit such as field-specific scalar VOLE entries/s to bare correlations/s. Counting does not establish security or choose parameters. Change code or tables only within the requested scope; optional literature, benchmarking, or writing skills do not block this self-contained calculation.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: cryptography-writing
description: Draft or minimally edit cryptography manuscripts, including definitions, theorem statements, security arguments, abstracts, and technical overviews. Preserve the construction and guarantee; use crypto-proof-auditor for substantive proof-validity review.
---

# Cryptography Writing

Make the contribution and argument precise and readable. Use established terms when they express the intended formal meaning; otherwise name the object or relationship plainly. Theory-only writing needs no implementation or experiments.

Use [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/STE_faq.html) as plain-language style guidance: prefer clear, focused sentences and active voice where appropriate. Judge clarity by continuity, emphasis, and grammatical structure as well as length; a longer or passive sentence may keep the relationship clearer. Do not impose the standard's restricted vocabulary or dictionary-based word-use restrictions. Preserve mathematical precision, established cryptographic terminology, notation, and the author's explicit instructions.

Prefer concrete cryptographic nouns and operations over generic labels such as “endpoints,” “layer,” “interface,” “publish,” or “pad.” Name the parties, OT roles, protocol phase, primitive, PRF outputs, messages, broadcast, or reconstruction actually meant. Prefer “corrupted parties” to “coalition” when describing the corrupted set, and name supplied correlations rather than calling them “scalar correlations” or “OT state.” Explain what is sampled or causes an abort instead of relying on “marginal” or “cutoff” alone.

For drafting or terminology revision, use the wording defaults in [terminology](references/terminology.md). They express preferred prose, not claims that the avoided words are unknown in cryptography. Preserve exact mathematical distinctions, formal interfaces, complete retained state, source-defined terms, and technically meaningful uses such as “one-time pad.” Local author instructions can override these defaults.

## State results directly

State the strongest supported contribution directly. Remove apologies, repeated caveats, and imagined reviewer objections that add no information. Express limitations as precise scope conditions or tradeoffs, without turning a local negative result into a judgment on the whole construction. Keep qualifications that change the claim, including the corruption model, setup, leakage, abort guarantee, and unresolved proof obligations. Do not ban words mechanically: “only the output is revealed” can state an essential guarantee.

## Work from the active claim

Check project guidance for the author's explicit wording corrections and
accepted replacements. Preserve their scope and later reverts. When an
existing term already names the intended object, prefer it to inventing and
defining another label; a terminology question alone does not authorize
manuscript edits.

1. Resolve the requested source version and active text. Read the relevant definitions, notation, theorem, and nearby argument before changing a technical claim.
2. Identify what the sentence relies on: the experiment or functionality, adversary and corruption, setup and oracle access, quantifiers and bounds, assumptions, composition, leakage, and output guarantee. State the material conditions or point to a definition fixing them; do not repeat the whole model in every sentence.
3. Distinguish the intended target, the theorem stated, the reasoning supplied, and any implemented variant. Draft only what the available material supports; never invent a citation, proof step, assumption, or result.
4. Match the work to the request. Reviewing or suggesting wording does not authorize file edits. For authorized edits, preserve unrelated changes and make the smallest technically correct repair unless a rewrite is requested. Keep notation, macros, labels, comments, wrapping, and the author's voice.
5. Check the resulting claim agai

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 12 — file references are metadata, not package contents.

View saved version →

---
name: crypto-implementation-evaluation-writing
description: Draft, revise, or review cryptography implementation and evaluation sections from code and experimental evidence. Use for supported performance claims, fair comparisons, and identifying missing evidence; not benchmark execution or raw analysis alone.
---

# Crypto Implementation Evaluation Writing

Make clear what was implemented, measured and inferred, and which conclusions the evidence supports. Build the section around its empirical argument rather than a mandatory sequence of headings.

Use established cryptographic terms: name the parties, protocol phases, subprotocols, primitives, or measured operations instead of generic “endpoints” or “layers.” Say whether a measured message is sent or broadcast rather than merely “published”; name PRF outputs, OT messages, and supplied correlations when those are the objects meant. Distinguish supplied correlations from complete retained state. Retain precise implementation terms, such as network endpoints, interfaces, or pipelining, and preserve source-defined usage.

## Workflow

1. Identify the evaluated construction/configuration and the evidence for each result. Fix workload, guarantees, included phases, prepared state/reuse, metric, aggregation and provenance. A compact working table is enough when useful; a local edit need not create planning documents.
2. Describe implementation scope and material deviations so readers know which algorithm produced the data. Distinguish original artifacts, reproductions, ports and transformed variants. Keep the implemented sampler and concrete parameter support separate from the formal theorem.
3. Present results before interpretation. Align comparisons on functionality, guarantees, workload, costs and resource budgets; expose uncontrolled differences. Separate protocol comparisons on a common workload from whole-system comparisons on an application.
4. Connect observations to a supported explanation and qualified conclusion. Profiles can support an explanation; uncontrolled correlation does not isolate causality. Label untested explanations and proposed optimizations accordingly.
5. Recompute arithmetic and reconcile prose, tables, captions and legends. Keep exclusions, failures and evidence classes discoverable beside affected results.

A component benchmark, ideal-resource fixture or modeled cost is valid evidence for its stated scope, but is not an end-to-end measurement. Builds, tests and smoke runs establish only their tested coverage. Preserve unknowns instead of filling them by unstated extrapolation.

## References by task

- [Evaluation method](references/evaluation-method.md): result records, measurement semantics, evidence labels and final checks; read the relevant sections when these are uncertain.
- [Argument and experiments](references/argument-and-experiments.md): substantial sections, comparison design and evidence gaps.
- [Setup, phases and amortization](references/setup-phases-and-amortization.md): role topology, correlation consumption, proof-system setup and reuse.
- [Evidence sources](references/evidence-sources.md): optional historical examples and their provenance; select entries rather than loading the corpus.

Match the deliverable: findings for a review, a scoped edit for revision, or a supported section for drafting. Preserve existing notation, wrapping and unrelated prose. Missing evidence calls for a narrower claim or a specific follow-up; run experiments or change code only when the user's task authorizes that work.

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: crypto-literature-evidence
description: Find and verify primary-source cryptography claims, compare paper versions, and synthesize literature or research methods with exact source locators. Use for citation checks and surveys; not for proof-validity audits or prose revision alone.
---

# Cryptography Literature Evidence

Establish what a source actually says and whether it applies to the question. Titles, search snippets, secondary summaries, and other agents' reports are discovery aids. Inspect the primary paper and relevant official artifact before relying on their technical claims.

## Evidence workflow

1. Fix the requested proposition and the axes that distinguish a match: relation/interface, model, parameters, guarantee, cost, or writing pattern. A keyword mention does not establish a formal definition or result.
2. Identify the exact source version, date, and locator. Reconcile full, proceedings, appendix, and local versions; check current primary sources and errata when currentness or candidate viability matters.
3. Separate source statements, paraphrases, calculations, interpretations, and unresolved inferences. Preserve reported versus derived values, units, denominators, and measured versus analytical evidence.
4. Cross-check material claims against definitions, theorem premises, captions, footnotes, and appendices. Inspect rendered equations or tables when extraction is unreliable. Accurate attribution alone does not establish applicability to a different model, field, distribution, or setup.
5. Report conflicting and contrary evidence. Do not strengthen a source's security guarantee, empirical status, or scope, or infer universal absence from an incomplete search.

For a single claim, give the conclusion, source/version, exact locator, and decisive qualification. For a survey, also state coverage, strict matches versus related discussions, inaccessible sources, and unresolved dependencies. No corpus worksheet is required for a narrow question.

## Further detail

- [Evidence method](references/evidence-method.md): multi-paper reviews, scoped novelty searches, version conflicts, numerical attribution, and completeness claims.
- [Researcher studies](references/researcher-studies.md): attribution, reading depth, and conditional lessons from a researcher's or collaboration's work.

Literature review does not itself authorize manuscript edits. Source verification does not establish proof validity; use the proof-audit workflow when that is requested. Writing and implementation skills are optional follow-on help, not prerequisites. Theory-only research needs no code or experiments.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: crypto-manuscript-qa
description: Check cryptography manuscript sources, LaTeX builds, PDF locations, references, layout, and requested paper/code consistency. Use for source or rendered-document QA; not for prose-only drafting, proof validity, or benchmark collection.
---

# Cryptography Manuscript QA

Resolve the authoritative manuscript, requested version, and active include graph before citing pages or editing. Project paths, frozen files, and construction choices come from the current project, never another paper's conventions.

## Check the requested surface

- Distinguish review, language edits, technical repair, reorganization, and evidence updates. Follow the authorized scope and later decisions; preserve unrelated prose, notation, macros, labels, comments, and wrapping.
- Resolve findings and annotations against their actual document/version. Reviewer suggestions are evidence to assess, not authority to change the theorem.
- Compare implicated active definitions, construction, theorem, and evaluation. Keep intended claims, checked proof support, and implemented experiments distinct; unused or commented material establishes no live claim.
- For code/evidence correspondence, identify the revision, variant, parameter/sampler distribution, and measurement contract. Inspect the sources directly; do not alter a theorem to rationalize code. Theory-only QA needs no implementation or experiments.

Read [source and PDF validation](references/source-and-pdf-validation.md) for version/page resolution, checking manuscript guidance against source and decision records, affected LaTeX builds, rendered-page inspection, actual hyperlink destinations, or submission checks. Apply only the checks relevant to the change.

For review, give focused findings with current locations, consequences, and proposed corrections. For edits, report changes and completed checks, separating arithmetic, build, and layout results from proof support. Compilation does not certify security. Use writing or proof-audit guidance when that distinct work is requested; companion skills are optional.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: crypto-prior-work-comparison
description: Draft or review cryptography prior-work comparisons and comparison tables by aligning models, construction variants, costs, and evidence. Use for positioning results, not literature discovery alone or benchmark execution.
---

# Crypto Prior-Work Comparison

Make clear what improves, under which conditions, and at what cost. Compare complete supported variants: one theorem's guarantee and another's efficiency do not form a new result.

Use established cryptographic terms for the objects compared. Prefer “corrupted parties” when that is the set meant; name the supplied correlations, protocol phases, subprotocols, and comparison criteria instead of generic “endpoints,” “layers,” or “scalar” modifiers. Describe the actual communication operation and the specific overhead or parameter dependence that improves. Preserve precise technical uses and source-defined terms; wording does not establish a stronger comparison.

## Fix what is being compared

Recover the target claim before selecting baselines. Identify the task and output guarantee; adversary, corruption, assumptions and setup; construction version and parameter regime; and the cost's phase, unit, aggregation, denominator, and exclusions. Include only axes that matter to this comparison. Theory-only comparisons use definitions, theorems, and analytical bounds; they need no code or benchmarks.

Select the smallest baseline set that answers the claim: the closest predecessor, the strongest relevant result on each claimed axis, and other work that changes the interpretation. Use relevance, not the largest available ratio. A separate literature search is needed only if the supplied sources cannot support that choice.

## Build and write the comparison

1. Map each substantive claim or table cell to a primary-source version and locator. Verify attributions against that source; distinguish unverified supplied evidence. Preserve author implementations, independent reproductions, ports, and transformed variants as different lineages.
2. Separate theorem-level, asymptotic, concrete analytical, and empirical results. Label numbers as measured, rerun, inherited, derived, estimated, or projected as applicable. A component rate or ideal-resource proxy is not end-to-end performance.
3. Normalize comparable axes and disclose differences affecting the conclusion next to it. Missing or unreported work is not zero. A measured configuration without established concrete security cannot support a security-matched ranking merely from its parameter width.
4. State the result and its mechanism or tradeoff under the aligned conditions. Give absolute values before ratios; recompute totals, conversions, amortization, and break-even points. Reconcile text, headers, captions, and formulas.
5. Use the narrowest supported conclusion. Preserve prior work's remaining advantages and state incomparability where a conversion is unsupported.

Review or suggested wording is read-only unless edits are requested. When editing, preserve the manuscript's notation and voice. Do not strengthen security, performance, or priority claims for rhetorical effect.

## Optional detail

- [Comparison method](references/comparison-method.md): substantial sections/tables, uncertain normalization, or mixed numerical provenance.
- [Source patterns](references/source-patterns.md): examples of comparison structures and known table-consistency pitfalls.
- [Theorem variant cases](references/theorem-variant-cases.md): incompatible variants, compressed quantitative premises, or a correction that changes a comparison's cost.

Use `cryptography-writing` only when the task also requires broader narrative organization, and `crypto-literature-evidence` when additional source research is needed. The comparison itself should remain self-contained. Return reconstructible claims and material unresolved mismatches, without forcing a fixed paragraph order or evidence template onto a small edit.

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: crypto-proof-auditor
description: Audit or complete cryptographic proofs, reductions, simulators, and security theorems. Use for proof-validity questions; source edits follow the requested deliverable or existing authorization. Not for prose-only, code-conformance, or PDF reviews.
---

# Crypto Proof Auditor

Determine whether the conclusion follows under the stated definition, model, and assumptions. Audits are read-only unless edits are also authorized. A completion request authorizes developing the missing argument; edit source files when the requested deliverable or existing session authorization calls for it. Never conceal a gap by silently adding an assumption, weakening the theorem, or changing the construction. Different proof organization or labels alone are not defects.

## Audit workflow

1. Resolve the active theorem, definitions, construction, proof, and source revision. Separate the intended target from the supplied statement and checked argument. Identify imported results you will check and those left unverified.
2. Fix the theorem's objects, domains, parameter regime, quantifier order, and permitted dependencies. Record the adversary/corruption model, setup and oracle interfaces, compared joint outputs or success event, leakage, assumptions, bound, abort/delivery guarantee, and composition or reuse scope.
3. Trace each part of the conclusion to the lemmas, calculations, simulators, extractors, or reductions supporting it. Check hypotheses, types, parameter substitutions, model compatibility, efficiency, and accumulated error. A dependency graph is useful for a large proof, not a required deliverable for a local question.
4. For game or hybrid arguments, check complete experiments, endpoints, each adjacent justification, challenge embedding, the correctly correlated surrounding view, and the final advantage/runtime bound. For simulation, check that every action uses information available at that time. Inspect the actual experiment rather than importing a familiar template.
5. Test disputed inferences with boundary parameters, adversarial choices, conditioning, schedules, reuse, or small counterexamples as relevant. A counterexample to a step need not refute the theorem; failure to find one is not a proof. Do not call a missing derivation routine until checked.
6. Compare the established conclusion with the claimed scope. Mathematical proof support, implementation conformance, and empirical evidence are distinct conclusions; tests and builds do not establish a security theorem.

## Read only the needed detail

- [Audit method](references/audit-method.md): dependency tracing, probability, quantifiers, counterexamples, and optional diagnostic examples.
- [Reductions and bounds](references/reductions-hybrids-and-bounds.md): game hops, hidden challenge keys, bounded rejection, concrete loss, and tightness.
- [Batching and release order](references/batching-and-release-order.md): conditional field checks, powers of one challenge, ring counterexamples, and delayed verification.
- [Simulation and composition](references/simulation-composition-and-resources.md): conditional share sampling, adaptive state opening, causality, abort, sessions, and ideal-resource replacement.
- [Extraction and oracles](references/extraction-and-oracles.md): knowledge claims, commitments, proof systems, Fiat--Shamir, ROM, and QROM.
- [Repair and validation](references/repair-and-validation.md): authorized completion or edits.

A theory audit requires no implementation or experiments. These references are self-contained; optional writing or implementation skills are useful only when that additional work is requested.

## Report findings

Lead with supported findings, ordered by consequence. For each, give the claim and source anchor, failed obligation, evidence, consequence, smallest defensible repair or missing lemma, and residual uncertainty. Scale the format to the question; a fixed worksheet is unnecessary. Identify valid challen

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.

View saved version →

---
name: crypto-protocol-implementation
description: Implement, optimize, reproduce, or review cryptographic protocol code against its specification. Use for circuit, transcript, state, sampler, and adapter fidelity and security obligations affected by code changes; not a full proof-validity audit.
---

# Cryptographic Protocol Implementation

Connect the governing specification to the code and the behavior being changed. Keep formal constructions, engineering variants, test fixtures and claimed guarantees distinguishable.

## Workflow

1. Identify the specification/version, target code and exposed interface. Map the relevant algorithms and message schedule to APIs, state, randomness, serialization, checks, outputs and aborts. Mark ideal resources, trusted fixtures and omitted phases.
2. For a correspondence review, report discrepancies. For implementation work, make scoped changes. For optimization, identify the target metric, observed or hypothesized bottleneck, replaced cost and added work before choosing a technique.
3. Identify the contract affected by the change. Byte equivalence, algebraic output equality, distributional equivalence and realization of the same ideal functionality are different obligations. Small edits to challenges, checks, parameters or scheduling can change the protocol.
4. Validate changed behavior with focused checks and the project's required checks; for reviews, report available evidence and gaps. Reuse a security argument only where its contract and hypotheses remain supported, without rewriting the theorem to fit the code.

For MPC, track party-local views and correlation ownership. For proof systems, track statement/witness separation, setup, transcript challenges and acceptance. Functional correctness, memory/runtime safety, specification conformance, cryptographic security, leakage and measured performance require distinct evidence.

## References by task

- [Specification and distributions](references/specification-and-distributions.md): reproductions, variants, samplers, correlations and setup.
- [State and validation](references/state-and-validation.md): peer messages, secret lifetimes, arithmetic preconditions and tests.
- [Optimization strategy and execution](references/optimization-strategy-and-execution.md): bottlenecks and tradeoffs, with selective MPC and ZK routes.
- [Security preservation and proof reuse](references/security-preservation.md): changed components, parameters or schedules and affected proof obligations.
- [Verification scope and trust](references/verification-scope-and-trust.md): formal evidence, verified code and verification-tool selection.

Load only the implicated references. Return the implemented/reviewed scope, source-to-code mapping, variant/setup qualifications, validation results and unresolved dependencies. For optimizations, state the preserved or changed contract and whether the claimed gain is measured or still hypothetical.

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: crypto-research-artifacts
description: Prepare, document, anonymize, validate, or package cryptography research artifacts. Use for reviewer workflows, claim-to-command maps, and validation from a fresh extraction; not protocol proofs or benchmark execution alone.
---

# Cryptography Research Artifacts

Build the smallest complete reviewer workflow for the selected paper claims and release scope. Reproducibility, correctness, performance evidence and security support are distinct outcomes.

## Workflow

1. Resolve the exact paper version/entrypoint, selected claims and release stage. Verify current official venue rules when making compliance claims; historical guides are examples.
2. Map each selected claim to its configuration, evidence and reproduction command. Include required source, pinned dependencies, fixtures, analysis and interpretation. Keep ideal resources, unsupported platforms and unresolved instantiation claims visible.
3. Prepare the requested deliverable using the project's release layout and export policy. Planning, local cleanup, packaging, validation and publishing are different actions; follow the user's authorized scope. Retain attribution and licenses without inventing a license choice.
4. For a built package, validate a fresh extraction away from the developer checkout and bind the report to the final checksum. A planning request receives a validation plan; documentation edits need checks of the affected instructions and paths. Revalidate affected commands when package contents change.

Start reviewers with a deterministic correctness example, then staged experiments with realistic requirements. Developer history and optional variants need not lead the workflow, but limitations that qualify selected claims must remain discoverable. Include historical observations only when the export policy and reproduction route call for them; required input fixtures are a separate category.

## References by task

- [Release workflow](references/release-workflow.md): policy, anonymity, package construction and detached validation.
- [Claims and reviewer commands](references/claims-and-commands.md): claim records, README structure, experiment progression and formal-evidence qualifications.

Load the relevant sections. Report PASS, FAIL and NOT RUN by validation scope, the resulting package or plan, and remaining limitations. A build or smoke run does not establish publication performance or instantiate a security theorem; packaging cannot repair missing evidence.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: crypto-research-framing
description: Clarify exploratory cryptography ideas into precise questions, definitions, candidate lemmas, construction approaches, counterexamples, or obstructions. Use to organize research reasoning and choose the next mathematical step, not polish manuscript prose or audit an existing proof.
---

# Cryptography Research Framing

Organize rough ideas into a clear research question and a useful next mathematical step. Separate established facts, assumptions, conjectures, and unresolved choices before developing a candidate. If the idea is not ready for a construction, a precise formulation of the question and obstacle is a useful result; a modest question needs no grand unifying objective.

## Keep the target fixed

Separate the desired capability from the assumptions and setup available to realize it. Fix, or explicitly leave open, the functionality, leakage, adversary and corruption, composition, abort or delivery, interaction, and quantitative goal when relevant. A missing choice does not authorize selecting an easier theorem. Label changes to these conditions as alternative targets and continue work that does not depend on unresolved choices.

A request for research directions does not authorize manuscript edits or experiments. Do not imitate a researcher's persona, infer individual contributions from coauthorship, or use reputation as evidence for a lemma.

## Develop a candidate

1. State the capability and obstacle. Distinguish an impossibility theorem, a limitation of the current approach, and an intuition.
2. Isolate the intermediate object the argument needs: inputs, outputs, joint law, adversarial choices, exposed state, and simulator information. An ideal functionality performing the entire target may only rename the problem.
3. Compare a few meaningfully different mechanisms. For each serious candidate, identify the missing lemma and a plausible failure. Test the smallest instance that retains the relevant correlations, auxiliary information, and adaptive choices; a passing example is not a proof.
4. Connect the local property to its consumer. Assign correctness, privacy, simulation/extraction, consistency, and error bounds to the components actually responsible. Account for repeated use and retained state.

Select additional guidance by the obstacle:

- [Research moves](references/research-moves.md): change a definition, representation, component role, or assumption.
- [Proof representations](references/proof-representations.md): missing reduction capabilities, proof-only modes, or adaptive timing.
- [Definition and interface gaps](references/definition-and-interface-gaps.md): intended use exceeds the available theorem or quantitative bound; includes an optional simulation example.
- [MPC worked examples](references/mpc-worked-example.md): isolate preprocessing and communication, or prove a double-sharing masking claim for a collector's complete view.

These are optional methods and hypothetical exercises, not a sequence every project must complete.

## Return the mathematical result

Give a candidate lemma with a proof attempt, a counterexample identifying the violated requirement, a justified local transformation, or a precise remaining obstacle. State what is derived, assumed, source-supported, or open, and which unresolved premise most affects the next step. Do not promote a local calculation to whole-construction security.

Verify paper-specific mechanisms and theorem premises against versioned primary sources. Separate their claims from proposed adaptations and explanatory failed candidates. Use `crypto-literature-evidence` for additional source research, `crypto-proof-auditor` for a substantive validity audit, or `cryptography-writing` for authorized manuscript drafting only when that separate task is needed.

Referenced files: 6 — file references are metadata, not package contents.