crypto-paper-writing

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:

1. Asymptotic optimality — prove your scheme achieves the best complexity
2. 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:

1. 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".
2. Concrete parameters (1-2 sentences): Give asymptotic complexity — O(C) prover, O(log C) proof size, etc.
3. Key technique (1 sentence): Name the core technical insight.
4. 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:

1. Implementation details: Language, libraries, lines of code, open-source link.
2. Hardware: Exact machine specs (CPU model, RAM, cores used).
3. Methodology: What systems you compare against, how you obtained their numbers (re-implementation, original code, numbers from their paper, communication with authors).
4. Benchmarks: Choose benchmarks that are standard in the field (e.g., Merkle tree, SHA-256 circuit, matrix multiplication for ZKP papers).
5. Results: Report prover time, proof size, verification time separately. Use log-scale plots (Figure 1) showing all systems on the same axes.
6. 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:

1. Search IACR ePrint using search_iacr MCP tool (primary source for crypto papers)
2. Cross-check with DBLP or Semantic Scholar for venue/year
3. Retrieve BibTeX from the verified source
4. 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:

1. After finding a paper on ePrint, check the publication_info field — it often says "Published elsewhere. Minor revision. CRYPTO 2019" or similar.
2. If a published version exists, search DBLP for the conference BibTeX entry.
3. Use the conference BibTeX (not the ePrint version) as the primary citation.
4. 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:

Conference	Template Source
CRYPTO / EUROCRYPT / ASIACRYPT	Springer LNCS: https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines
IEEE S&P	Conference website → "Author Information" or "Call for Papers" page
ACM CCS	https://www.acm.org/publications/proceedings-template
USENIX Security	Conference website → "Call for Papers" → template download link
NDSS	Conference website → "Call for Papers" → template download link

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:

1. Read the section carefully
2. Identify: imprecise claims, passive voice overuse, missing quantification, unclear antecedents, inconsistent terminology
3. Suggest concrete rewrites, not vague advice
4. Preserve the author's voice — do not over-edit
5. 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

• Abstract numbers match Evaluation section numbers exactly
• Every asymptotic claim in Table 1 is proved by a theorem in Section 4
• Every concrete number in Table 1 appears in Section 5 with methodology
• Contribution bullets in Introduction are each supported by a section
• Notation defined in Preliminaries is used consistently throughout
• All theorems/lemmas are referenced somewhere in the main text

Crypto-Specific Red Flags

• Security model is explicit: clearly state what is being proved (soundness? knowledge soundness? zero-knowledge?) and under what model (ROM? standard model? AGM?)
• Assumptions are standard: if using non-standard assumptions, justify them. Reviewers will push back on "novel" assumptions without strong motivation
• Reduction tightness: state the concrete security loss. A loose reduction (e.g., losing a factor of 2^λ) without justification will draw criticism
• Parameter selection: if claiming concrete security, explain how parameters are chosen to achieve λ-bit security
• Comparison fairness: compare on the same field/curve, same benchmark, same hardware. Footnote any differences
• Open-source code: provide a link. Papers without code face skepticism about reported numbers

Writing Quality

• No AI vocabulary red flags (see "Eliminating AI Writing Patterns" above)
• Consistent terminology throughout (no synonym cycling)
• All figures/tables are referenced in the text
• Figure captions are self-contained (readable without main text)
• No orphaned citations (every \cite has a corresponding \bibitem, and vice versa)
• No undefined abbreviations on first use

Formatting

• Page limit is met (verify with the latest CFP)
• Double-blind: no author names, no "our previous work [1]" with self-citation, no institution names in acknowledgments, no identifying GitHub URLs
• References are complete (no "To appear" without venue, no missing years)
• ePrint citations use published version where available

---

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