Cryptography Research Skills

View saved version →

---
name: crypto-ai-acknowledgements
description: Draft or review AI-use disclosures 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 the shortest truthful account of the system's contribution, the authors' contribution, and the checks actually performed. Match the manuscript's placement and style; no universal heading, model inventory, or responsibility formula is required.

## 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.

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.

## 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.

Use [drafting patterns](references/drafting-patterns.md) only when a starter clause would help; adapt it to supported facts. Use [source evidence](references/source-evidence.md) for example provenance or citation requests, reopening primary sources before making paper-exact claims. The selected examples establish neither community prevalence nor non-use where disclosures are absent.

If venue compliance is requested or constrains the draft, check the current official policy for the relevant year, track, and stage, with its date/version. Examples are not policy. If the policy is unavailable, state that limitation and continue fact-based drafting.

Return one usable paragraph or section, followed by material unresolved facts or policy qualifications. For review, identify concrete mismatches and offer minimal replacements. This disclosure reports a process; it is not a correctness certificate or an instruction to audit the paper's proofs.

Referenced files: 3

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

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.
- 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, 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

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.

## Work from the active claim

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 against its sources and inspect the diff. Follow applicable manuscript checks when editing source files. If a repair requires a new model, theorem, or authorial choice, report the ambiguity and a narrow alternative rather than silently changing it.

Local definitions take precedence over generic terminology. Keep correctness, security, and implementation evidence distinct; likewise joint distributions versus marginals, success probability versus advantage, concrete versus asymptotic bounds, and ideal-resource guarantees versus concrete instantiations. A stylistic edit cannot establish a missing theorem.

## Load details only for the current task

Use the entrypoint alone for a straightforward edit with fixed meaning. Read the relevant reference when drafting substantial material or resolving an uncertainty:

| Task | Reference |
| --- | --- |
| Abstract or introduction structure | [Abstracts and introductions](references/abstracts-and-introductions.md) |
| Explain a construction or proof idea | [Technical overviews](references/technical-overviews.md) |
| Ambiguous cryptographic word or claim verb | [Terminology](references/terminology.md) |
| Security statements, experiments, reductions, or full proofs | [Security claims](references/security-claims.md) |
| MPC, simulation, corruption, composition, or output guarantees | [Secure computation](references/secure-computation.md) |
| Proof systems, extraction, commitments, or oracle models | [Proof systems and oracles](references/proof-systems-and-oracles.md) |
| Construction interfaces, preprocessing, rounds, or costs | [Constructions and costs](references/constructions-and-costs.md) |
| Mixed edit authorization or multiple manuscript variants | [Conservative editing](references/conservative-editing.md) |

The narrative guides link optional source examples; those corpora are not required reading. Load multiple references only when the claim actually crosses their topics.

## Full proof drafting

For a new simulation-based proof or an authorized substantial rewrite, a useful default is to describe the simulator's information, interfaces, state, and behavior, then justify meaningful real-to-ideal transitions and accumulate their bounds. Preserve the complete joint view and conditional distributions, including for perfect security. A direct equality-of-distributions argument can suffice; do not invent intermediate experiments or impose particular labels. Follow the governing definition and the author's organization when another presentation is clearer.

A requested substantive validity audit or proof completion may need `crypto-proof-auditor`; source/PDF verification may need `crypto-manuscript-qa`. Use companions only for those additional tasks, not automatically during prose editing. Deliver the prose or minimal patch, with only material unresolved technical questions.

Referenced files: 10

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.

## 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

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, 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

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, 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

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.

## 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): properties drawn from incompatible variants or compressed quantitative premises.

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

View saved version →

---
name: crypto-proof-auditor
description: Audit or complete cryptographic proofs, reductions, simulators, and security theorems. Use for proof-validity questions; read-only unless completion or source edits are requested. Not for prose-only, code-conformance, or PDF reviews.
---

# Crypto Proof Auditor

Determine whether the conclusion follows under the stated definition, model, and assumptions. An audit is read-only unless completion or edits are requested. 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, conditioning, sampler changes, concrete loss, and tightness.
- [Simulation and composition](references/simulation-composition-and-resources.md): malicious behavior, 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 challenged steps as well as invalid ones when adjudicating a disputed inference.

Distinguish **confirmed error** (invalid inference or counterexample), **proof gap** (missing obligation), **unstated assumption**, **scope overclaim**, **ambiguity**, **unverified dependency**, and **presentation issue**. State impact and confidence; keep speculative concerns as questions.

End with the strongest supported disposition: theorem refuted by a counterexample satisfying its hypotheses; supplied proof incomplete; only a stated narrower scope established; or no confirmed defect found in the audited surface. State coverage and unchecked dependencies. An outline can contain no identified defect while still failing to discharge the theorem. An informal audit does not certify correctness or constitute machine-checked verification.

Referenced files: 9

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

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

View saved version →

---
name: crypto-research-framing
description: Turn an exploratory cryptography idea into a candidate lemma, construction approach, counterexample, or precise obstruction. Use for choosing the next mathematical step, not local prose edits or auditing an existing proof.
---

# Cryptography Research Framing

Find a useful next mathematical step. A precise obstruction can be as useful as a candidate construction; 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 example](references/mpc-worked-example.md): isolate a preprocessing interface and communication calculation.

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