| name | crypto-paper-writing |
| description | Write and polish publication-ready cryptography papers, especially in the SNARK/zero-knowledge proof domain, targeting top security conferences (IEEE S&P, CCS, USENIX Security, NDSS) and top cryptography conferences (CRYPTO, EUROCRYPT, ASIACRYPT). Use this skill whenever the user works on cryptography papers, ZKP/SNARK manuscripts, asks to draft or revise sections of a crypto paper, wants to structure a paper around a new protocol or proof system, or needs help with crypto-specific LaTeX environments. Trigger on: write paper, draft paper, crypto paper, ZKP paper, SNARK paper, 写论文, 密码学论文, polish manuscript, revise section, structure paper, paper outline, zero-knowledge, proof system, protocol description, security proof writing. Do NOT trigger on: ML/AI papers, medical papers, general scientific writing without crypto context, slide/presentation creation (use beamer or powerpoint-slides skill instead).
|
Cryptography Paper Writing
Write publication-ready papers for top cryptography and security venues. This skill encodes
writing patterns distilled from high-impact SNARK/ZKP papers (Libra, Virgo, Orion, Pianist)
and adapts them to the broader applied cryptography landscape.
When to Use
- Drafting a new cryptography paper from scratch
- Structuring a paper around a new construction or proof system
- Writing or revising specific sections (abstract, intro, technical overview, etc.)
- Polishing prose for submission to a top venue
- Setting up LaTeX project with correct conference template
Core Principle
A crypto paper tells a story: "Here is a problem. Here is why existing solutions fall short.
Here is our construction. Here is why it is correct/secure. Here is how fast it is."
The two pillars of persuasion in modern applied cryptography (especially SNARK/ZKP) are:
- Asymptotic optimality — prove your scheme achieves the best complexity
- Concrete efficiency — show your implementation outperforms existing systems
Traditional security proofs remain important but are increasingly placed in appendices,
with the main body focusing on construction intuition and efficiency.
Paper Structure
Crypto papers do NOT follow IMRAD. Use this structure instead:
Abstract
1. Introduction
1.1 Our Contributions (bullet list with formal claims)
1.2 Comparison Table (Table 1: asymptotic + concrete numbers)
1.3 Technical Overview (intuitive explanation of key ideas)
1.4 Related Work
2. Preliminaries
2.1 Notation
2.2 Definitions (formal crypto definitions)
2.3 Building Blocks (existing protocols/assumptions used)
3. Construction / Protocol
3.1 Core algorithm or protocol
3.2 Extensions and optimizations
4. Security / Correctness Analysis
4.1 Theorem statements (in main body)
4.2 Proof sketches (full proofs in appendix if space-constrained)
5. Implementation and Evaluation
5.1 Implementation details
5.2 Benchmark methodology
5.3 Performance comparison
5.4 Discussion
6. Conclusion
Appendix A. Deferred Proofs
Appendix B. Additional Benchmarks
Flexibility notes:
- For theory-heavy papers, Section 4 may be the bulk; Section 5 may be brief or absent.
- For systems-oriented papers (e.g., zkVM, zkEVM), Section 5 may dominate.
- Some papers merge Sections 3-4 when construction and proof are tightly interleaved.
- The ordering of subsections in the Introduction may vary, but Our Contributions,
Comparison Table, and Technical Overview should all appear.
Section-by-Section Guide
Abstract (150-250 words)
Follow this pattern — the same one used by Libra, Virgo, Orion:
- Problem + strongest claim (1-2 sentences): State what you built and why it is the
first/best. Use superlatives when warranted: "the first", "optimal", "with the best".
- Concrete parameters (1-2 sentences): Give asymptotic complexity — O(C) prover,
O(log C) proof size, etc.
- Key technique (1 sentence): Name the core technical insight.
- Practical numbers (1-2 sentences): Concrete benchmarks — "takes X seconds for Y,
Z× faster than the state of the art."
Example pattern (Libra):
We present [Name], the first [system type] that has both [property A] and [property B].
In particular, [asymptotic bounds]. Underlying [Name] is [key technique]. Not only does
[Name] have excellent asymptotics, but it is also efficient in practice. For example,
[concrete numbers], outperforming all existing [systems].
What NOT to do:
- Do not start with "Zero-knowledge proofs have attracted significant attention..."
- Do not spend the abstract on motivation — jump to your contribution.
- Do not omit concrete numbers; reviewers want to see them immediately.
1. Introduction
Goal: In 1.5-2 pages, convince the reader your paper is worth reading.
1.1 Our Contributions — Use a bullet list. Each bullet is a self-contained claim:
\begin{itemize}
\item \textbf{Linear-time prover for GKR.} We present a new algorithm...
Our result subsumes all prior improvements assuming special circuit structures.
\item \textbf{Efficient zero-knowledge.} We show how to mask the protocol
with small random polynomials...
\item \textbf{Implementation and evaluation.} We implement [Name] and conduct
thorough comparisons. The open-source code is at~\cite{repo}.
\end{itemize}
1.2 Comparison Table (Table 1) — This table is arguably the most important element:
| Column | Description |
|---|
| Scheme names | All competing systems, yours last (or highlighted) |
| Setup type | Per-statement / universal / transparent |
| Prover time | Asymptotic (e.g., O(C log C)) |
| Verifier time | Asymptotic |
| Proof size | Asymptotic |
| Assumptions | Type of assumption (pairing, hash, lattice) |
| Concrete P time | Actual seconds on a reference benchmark |
| Concrete V time | Actual milliseconds |
| Concrete proof size | Actual KB |
Bold your best numbers. Use \mathbf{} for asymptotically optimal entries.
Include footnotes for caveats (e.g., "STARK operates in the RAM model").
1.3 Technical Overview — This is the soul of the paper.
- Explain your construction without formalism — use intuitive language.
- Walk the reader through the key ideas in 1-2 pages.
- Structure it as: "The naive approach does X. The challenge is Y. Our insight is Z."
- Each major technique gets its own paragraph with a bold heading.
- A reader who only reads the abstract + technical overview should understand your contribution.
1.4 Related Work — Organize by technique family, not paper-by-paper:
QAP-based systems. Following [refs], ...
IOP-based systems. Based on [refs], ...
Discrete-log based. Before [ref], ...
Interactive proofs. The line of work closest to ours is ...
Cite generously — reviewers may have authored related work.
2. Preliminaries
This section establishes notation and reviews tools your construction builds on.
- Notation: security parameter λ, negl(λ), PPT, field F, vectors in bold, etc.
- Formal definitions: State Definition environments for the core primitives
(interactive arguments, zero-knowledge, knowledge soundness, polynomial commitments, etc.)
- Building blocks: Review existing protocols (e.g., sumcheck, GKR, KZG) with enough
detail that the reader can follow your construction.
Keep this section minimal but self-contained — a knowledgeable reader should not need to
look up references to follow your paper.
3. Construction
Present your protocol/algorithm formally:
- Use
Algorithm or Protocol environments for step-by-step descriptions.
- For interactive protocols, clearly mark Prover (P) and Verifier (V) messages.
- For each step, include complexity annotations where helpful.
- Separate the construction into clean subsections (one per building block or phase).
- End with a "Putting Everything Together" subsection that assembles the full protocol.
4. Security / Correctness
- State Theorems and Lemmas formally in the main body.
- For space-constrained submissions, put full proofs in the appendix with a brief
proof sketch or intuition in the main body.
- For each theorem, clearly state: what is being proved, under what assumptions,
and what the concrete security loss (tightness) is.
5. Implementation and Evaluation
This section provides concrete evidence for your efficiency claims.
Structure it like Libra/Virgo:
- Implementation details: Language, libraries, lines of code, open-source link.
- Hardware: Exact machine specs (CPU model, RAM, cores used).
- Methodology: What systems you compare against, how you obtained their numbers
(re-implementation, original code, numbers from their paper, communication with authors).
- Benchmarks: Choose benchmarks that are standard in the field
(e.g., Merkle tree, SHA-256 circuit, matrix multiplication for ZKP papers).
- Results: Report prover time, proof size, verification time separately.
Use log-scale plots (Figure 1) showing all systems on the same axes.
- Discussion: Honestly discuss where your system is worse and why,
and suggest potential improvements.
Reporting numbers:
- Always specify: single-threaded vs. multi-threaded, field size, curve.
- For prover: wall-clock time in seconds.
- For verifier: wall-clock time in milliseconds.
- For proof size: in KB.
- Use
× for speedup ratios: "3.4× faster than Hyrax".
- Show how the gap grows with circuit size — this demonstrates asymptotic advantage.
LaTeX Environments
Crypto papers use these environments extensively. See references/latex-environments.md
for complete definitions and examples.
Essential environments:
\begin{definition} — Formal crypto definitions (security notions, primitives)\begin{theorem} / \begin{lemma} / \begin{corollary} — Formal claims\begin{proof} — Proofs (use \begin{proof}[Proof Sketch] in main body)\begin{algorithm} — Algorithms (use algorithmic or algorithmx package)\begin{protocol} — Interactive protocols (custom environment, see references)\begin{game} — Security games (custom environment, see references)\begin{remark} — Clarifying notes\begin{assumption} — Cryptographic assumptions
Custom macros commonly used in crypto papers — define these in preamble:
\newcommand{\secpar}{\lambda} % security parameter
\newcommand{\negl}{\mathsf{negl}} % negligible function
\newcommand{\poly}{\mathsf{poly}} % polynomial
\newcommand{\PPT}{\mathsf{PPT}} % probabilistic polynomial time
\newcommand{\Adv}{\mathcal{A}} % adversary
\newcommand{\Sim}{\mathcal{S}} % simulator
\newcommand{\F}{\mathbb{F}} % finite field
\newcommand{\G}{\mathbb{G}} % group
\newcommand{\Z}{\mathbb{Z}} % integers
Writing Style
Precision Over Hedging
Crypto papers demand precision. Avoid vague language:
- ❌ "Our scheme significantly improves efficiency"
- ✅ "Our prover runs in O(C) time, improving over the O(C log C) of [ref]"
- ❌ "We achieve better performance"
- ✅ "Our proof size is 51KB vs. 185KB for Hyrax on the same benchmark"
Use superlatives when they are factually correct:
- "the first zero-knowledge proof system with both optimal prover time and succinct proof size"
- "outperforming all existing systems"
Consistent Terminology
Pick one term and stick with it throughout:
- "prover" (not sometimes "prover" and sometimes "proving party")
- "argument system" vs. "proof system" — choose based on whether soundness
is computational or information-theoretic, and be consistent.
Technical Overview Writing
The Technical Overview is the hardest section to write well. Guidelines:
- Start from what the reader knows: "Recall that the GKR protocol..."
- Name the challenge: "The key challenge is that naively running sumcheck
incurs S² prover time..."
- Present your insight: "Our key observation is that the polynomial can be
decomposed into..."
- Explain why it works: "This decomposition allows us to use dynamic programming
to compute all messages in O(S) time."
- Do NOT write formulas in the technical overview unless absolutely necessary.
Use words: "linear in the circuit size" rather than "O(|C|)".
Sentence-Level Tips
- Subject-verb proximity: Keep them close. Break long parenthetical insertions.
- Stress position: Put the important information at the end of the sentence.
❌ "The prover time is O(C), which is optimal"
✅ "The prover achieves optimal running time O(C)"
- Active voice for your contributions: "We present..." "We show..." "We prove..."
- Passive voice for known results: "It was shown in [ref] that..."
Eliminating AI Writing Patterns
When drafting or polishing, actively avoid these patterns that signal AI-generated text.
Reviewers are increasingly sensitive to AI writing artifacts.
Vocabulary red flags — replace or delete these words:
- Additionally, Furthermore, Moreover (as sentence openers — use sparingly, vary connectors)
- crucial, pivotal, landscape (abstract usage), delve, foster, garner, showcase,
underscore, tapestry, testament, vibrant, intricate, interplay
Structural red flags:
- Forced "Not only X, but also Y" parallelisms — use simpler connectors
- Rule of three (listing exactly 3 items every time) — vary list lengths
- "serves as" / "stands as" — just use "is"
- Excessive em dashes (keep under 2 per page)
- Synonym cycling (switching between "scheme" / "protocol" / "system" for the same thing)
Content red flags:
- Significance inflation: "This groundbreaking work..." — let the results speak
- Vague attributions: "Studies have shown..." — cite specifically or remove
- Generic conclusions: "This opens exciting new directions..." — be specific about what
- Excessive hedging: remove unnecessary "may", "might", "could potentially"
Section-specific focus:
| Section | Primary risk |
|---|
| Abstract | All patterns — highest scrutiny area |
| Introduction | Significance inflation, vague attributions |
| Technical Overview | Filler phrases ("It is important to note that") |
| Evaluation | Promotional language ("remarkable improvement") |
| Conclusion | Generic positive statements |
Citation Workflow
Never Hallucinate Citations
This is critical — AI-generated citations have high error rates.
Rule: Never generate BibTeX from memory. Always verify programmatically.
Workflow for adding a citation:
- Search IACR ePrint using
search_iacr MCP tool (primary source for crypto papers)
- Cross-check with DBLP or Semantic Scholar for venue/year
- Retrieve BibTeX from the verified source
- If you cannot verify: mark as
[CITATION NEEDED] and inform the user
Primary sources for crypto papers:
- IACR ePrint (
eprint.iacr.org): Preprints and published versions of all major crypto papers
- DBLP (
dblp.org): Verified publication metadata for conference/journal papers
- Semantic Scholar: Cross-reference and citation counts
ePrint → Published Version Tracking
Many crypto papers are first posted on IACR ePrint and later published at a conference.
Always cite the published version when available:
- After finding a paper on ePrint, check the
publication_info field — it often says
"Published elsewhere. Minor revision. CRYPTO 2019" or similar.
- If a published version exists, search DBLP for the conference BibTeX entry.
- Use the conference BibTeX (not the ePrint version) as the primary citation.
- Only cite the ePrint version if no published version exists yet.
Citation Style
IACR conferences (CRYPTO/EUROCRYPT/ASIACRYPT) use LNCS format:
\bibliographystyle{splncs04}
IEEE conferences (S&P) use:
\bibliographystyle{IEEEtran}
ACM conferences (CCS) use:
\bibliographystyle{ACM-Reference-Format}
USENIX and NDSS have their own styles — check the template.
Conference Setup: Always Fetch Latest CFP & Template
CFP and templates are updated every year. Before each submission, always fetch the
latest Call for Papers and official LaTeX template from the conference website. Never
rely on templates from previous years — page limits, formatting requirements, required
sections, and style files may change.
Step 1: Fetch the latest CFP
When the user specifies a target venue, use WebSearch or WebFetch to find the
current year's Call for Papers page and extract:
- Submission deadline(s)
- Page limit (main body vs. total)
- Required sections (e.g., ethics statement, limitations, broader impact)
- Anonymization requirements
- Supplementary material policy
- Any special requirements (e.g., mandatory checklists, AI disclosure)
Step 2: Download the official LaTeX template
Fetch the template from the official source:
Step 3: Verify template compiles
After downloading, copy the entire template directory and verify it compiles as-is
before making any changes.
Quick Reference (approximate — always verify with latest CFP)
| Conference | Typical Page Limit | Format | Template |
|---|
| CRYPTO / EUROCRYPT / ASIACRYPT | 30 pages (LNCS) | Springer LNCS | llncs.cls |
| IEEE S&P | 13 pages + refs | IEEE double-column | IEEEtran.cls |
| ACM CCS | 15 pages + refs | ACM double-column | acmart.cls |
| USENIX Security | 13 pages + refs | USENIX single-column | custom .sty |
| NDSS | 15 pages + refs | NDSS format | Custom template |
Important notes:
- IACR conferences allow 30 pages total (including references and appendices)
but reviewers are NOT required to read beyond page 30. Put essential content early.
- IEEE S&P and USENIX have strict page limits; appendices go to supplementary material.
- All venues require double-blind review — anonymize your submission.
- Page limits and policies change — the numbers above are approximate baselines.
Workflow
Starting a New Paper
1. Choose target venue → set up LaTeX template
2. Write the comparison table (Table 1) first — this forces you to
understand the landscape and articulate your advantage
3. Write the Technical Overview — if you cannot explain your idea
intuitively, the construction is not ready for a paper
4. Write the Abstract using the 4-part formula
5. Write Introduction (contributions + related work)
6. Write Preliminaries (only what the reader needs)
7. Write Construction with formal algorithms
8. Write Security/Correctness theorems + proof sketches
9. Write Implementation and Evaluation
10. Write Conclusion
11. Final pass: check all cross-references, theorem numbering,
bibliography completeness
Recommended Writing Order
Write in dependency order, not reading order. This produces tighter, more coherent papers:
1. Comparison Table (Table 1) — forces you to understand the landscape
2. Technical Overview — if you can't explain it intuitively, it's not ready
3. Preliminaries — only what the construction needs
4. Construction — formal protocol/algorithm description
5. Security/Correctness theorems — theorem statements + proof sketches
6. Implementation and Evaluation — benchmarks and comparison
7. Abstract — now you know exactly what to claim
8. Introduction (contributions + related work) — frame around your results
9. Conclusion — mirror the contributions
10. Title — last, when the contribution is crystal clear
Polishing an Existing Draft
When the user provides a draft section for polishing:
- Read the section carefully
- Identify: imprecise claims, passive voice overuse, missing quantification,
unclear antecedents, inconsistent terminology
- Suggest concrete rewrites, not vague advice
- Preserve the author's voice — do not over-edit
- Flag any claims that lack citation or evidence
Pre-Submission Self-Review Checklist
Run through this checklist before submitting. These catch the most common reasons
crypto papers are rejected or receive negative reviews.
Cross-Section Consistency
Crypto-Specific Red Flags
Writing Quality
Formatting
Reference Files
| File | Contents |
|---|
references/conference-guide.md | Page limits, templates, submission portals, deadlines |
references/latex-environments.md | Definition/Theorem/Proof/Protocol/Game environments with examples |
references/writing-patterns.md | Sentence patterns and paragraph structures from top crypto papers |
