Security / Privacy / Cryptography Paper Writing

Expert guidance for writing publication-ready papers targeting IEEE S&P (Oakland), ACM CCS, USENIX Security, NDSS, PETS / PoPETs, CRYPTO, Eurocrypt, TCC, ACSAC, AsiaCCS. This skill complements (it does not replace) Orchestra-Research's ml-paper-writing skill and Imbad0202's academic-research-skills. It focuses on what those general-purpose skills under-cover for our domain: threat models, security definitions, game-based and simulation-based proofs, side channels, ethics / responsible disclosure, and venue-specific submission policies.

"A security paper without a threat model is a wish, not a result." — Iron rule of this skill.

When to Use This Skill

Trigger this skill when the user is:

Drafting a paper for IEEE S&P, ACM CCS, USENIX Security, NDSS, PETS, ACSAC, AsiaCCS, RAID, ESORICS.
Drafting an IACR paper for CRYPTO, Eurocrypt, Asiacrypt, TCC, PKC, FC, CHES, or TCHES.
Writing or rewriting a threat model, security definition / game, simulation-based ideal functionality, or proof sketch.
Discussing concrete attacks, CVEs, exploit PoCs, side-channel measurements, or fuzzing campaigns.
Preparing a privacy section that mentions DP, k-anonymity, MPC, ZK, or PSI.
Preparing camera-ready, artifact-evaluation submissions, or shepherded revisions.

When NOT to use it (defer instead)

| Situation | Defer to | |-----------|----------| | Reviewer-loop simulation, multi-perspective review, R&R traceability matrix | academic-paper-reviewer (Imbad0202) | | Pure ML/AI venue paper (NeurIPS, ICML, ICLR, ACL, AAAI, COLM) | ml-paper-writing (Orchestra-Research) | | Systems-only paper (OSDI, NSDI, ASPLOS, SOSP) | systems-paper-writing if available | | ML-internal content (architectures, training curves) inside a security paper | Co-invoke ml-paper-writing for that section only | | Free-form literature review unrelated to drafting | deep-research or academic-paper plan mode |

IRON RULE: This skill writes the manuscript. It must never copy the simulated-reviewer text generated by academic-paper-reviewer into the manuscript itself — that would leak reviewer-internal text to the program committee. Treat reviewer artifacts as read-only input.

Venue Selection Guide

A short decision tree. For full per-venue policies, see references/venues.md.

Is the contribution primarily a cryptographic construction with a formal proof?
├── Yes, foundational / theoretical    → CRYPTO, Eurocrypt, TCC, Asiacrypt
├── Yes, applied (protocols, MPC, ZK) → CCS, USENIX Sec, PETS (privacy lean), CHES (HW)
└── No (systems / attack / measurement / privacy-applied)
    ├── Network / web / distributed attacks         → NDSS, USENIX Sec, CCS
    ├── Systems security, OS, kernel, vulns         → IEEE S&P, USENIX Sec, CCS
    ├── Privacy-enhancing tech (PIR, PSI, DP, anon) → PETS, CCS, USENIX Sec
    ├── Empirical measurement / abuse studies       → USENIX Sec, IMC (border), CCS
    └── Hardware / side-channel                     → CHES / TCHES, IEEE S&P, USENIX Sec

Tiering shorthand: S&P, CCS, USENIX Sec, NDSS are the "Big Four" for security-systems; CRYPTO / Eurocrypt are the top theoretical-crypto venues; PETS is the standard for privacy. ACSAC, AsiaCCS, RAID, ESORICS, FC are reputable second-tier and frequently used as backup.

Section Scaffolding (per venue family)

All venues require some form of: Abstract → Introduction → Background → Threat Model → Construction/Design → Security Analysis (proofs or argument) → Evaluation → Discussion / Limitations → Related Work → Ethics / Disclosure (where applicable) → Conclusion. Order shifts by community.

Big-Four security / systems-security paper (S&P, CCS, USENIX, NDSS, ACSAC)

Abstract (5 sentences, Farquhar form, see ml-paper-writing).
Introduction — problem, why prior work fails, contributions bullets, threat-model one-liner, results headline.
Background — minimal, only what a non-specialist on the PC needs.
Threat Model — separate, named section. State adversary capabilities, goals, what is in/out of scope, trust assumptions (TEEs, PKI, hardware roots), network model. See references/threat-models.md.
Design / Construction — protocol or system description, with diagrams. Distinguish algorithm pseudocode from protocol message flows.
Security Analysis — formal claims as Theorem / Lemma; proof sketches in body, full proofs in appendix. Reduction structure must be explicit.
Evaluation — concrete attack baselines, adversary defined per experiment, metrics motivated.
Discussion / Limitations — required.
Related Work — methodological, not paper-by-paper.
Ethics & Responsible Disclosure — required when human subjects, vulns, or sensitive datasets involved. See references/ethics-disclosure.md.
Artifact Availability — required by USENIX and increasingly by S&P / CCS.

IACR theoretical-crypto paper (CRYPTO, Eurocrypt, TCC, PKC, Asiacrypt)

Abstract — must state assumption(s) and the construction class.
Introduction — motivation, prior work, our results, technical overview (often a separate subsection that previews the proof strategy).
Preliminaries — notation, hardness assumptions, primitives (PRF, ROM/CRS, NIZK, etc.).
Definitions — security games or simulation-based ideal functionality, stated formally.
Construction — formal description of the scheme.
Security Theorems — \begin{theorem}...\end{theorem}; proofs by hybrid / game-hop with explicit advantage tracking. Tightness must be quantified — see references/crypto-conventions.md.
Extensions / Optimizations — usually after the main proof.
Conclusion / Open Problems.
Implementation and evaluation are optional and usually placed at the end or in an appendix.

Privacy paper (PETS, CCS privacy track)

PETS culture is ethics-first. The Ethics section is read before the contribution. Always include:

IRB / ethics-board status (or principled justification for not needing one).
Data-handling: anonymization steps, retention policy, opt-in/opt-out where applicable.
Risk to vulnerable populations.
DP claims must include (ε, δ) (or RDP/zCDP order), composition treatment, and what unit privacy is over (user, record, query). See references/privacy-conventions.md.

Citation Verification Protocol

The following protocol is adapted verbatim from Orchestra-Research/AI-Research-SKILLs ml-paper-writing/SKILL.md (MIT). Source path on this machine: /Users/erkamuzun/.claude/skills/.claude/skills/ml-paper-writing/SKILL.md. The protocol below is reused as-is for the [CITATION NEEDED] discipline; the domain-specific extensions for IACR ePrint, USENIX URLs, CVE pinning, and PoC commit hashes follow it.

The Problem

AI-generated citations have a ~40% error rate. Hallucinated references — papers that don't exist, wrong authors, incorrect years, fabricated DOIs — are a serious form of academic misconduct that can result in desk rejection or retraction.

The Rule

NEVER generate BibTeX entries from memory. ALWAYS fetch programmatically.

| Action | Correct | Wrong | |--------|---------|-------| | Adding a citation | Search API → verify → fetch BibTeX | Write BibTeX from memory | | Uncertain about a paper | Mark as [CITATION NEEDED] | Guess the reference | | Can't find exact paper | Note: "placeholder - verify" | Invent similar-sounding paper |

When You Can't Verify a Citation

If you cannot programmatically verify a citation, you MUST:

% EXPLICIT PLACEHOLDER - requires human verification
\cite{PLACEHOLDER_author2024_verify_this}  % TODO: Verify this citation exists

Always tell the scientist: "I've marked [X] citations as placeholders that need verification. I could not confirm these papers exist."

Mandatory verification flow

Search via Exa MCP, Semantic Scholar, or arxiv API.
Cross-check existence in at least two sources.
Fetch BibTeX programmatically (DOI → CrossRef, arXiv ID → arXiv API).
Verify the cited claim actually appears in the paper.
On any failure → [CITATION NEEDED], inform the user.

Domain-specific extensions for security / crypto

These extend the Orchestra protocol with field conventions:

IACR ePrint URLs alongside DOIs: For any IACR-venue paper (CRYPTO, Eurocrypt, TCC, Asiacrypt, PKC, FC, CHES) include https://eprint.iacr.org/<year>/<id> in the BibTeX note or howpublished field. Many IACR papers are only on ePrint; verify both ePrint and the proceedings entry via DBLP.
USENIX / NDSS paper URLs: USENIX papers should cite the conference paper page (https://www.usenix.org/conference/<venue><year>/presentation/<slug>) — these URLs are stable and reviewer-friendly. NDSS papers live under https://www.ndss-symposium.org/ndss-paper/<slug>/.
DBLP cross-check: For any security/crypto venue, confirm the venue, year, and authors via DBLP (https://dblp.org). DBLP catches "right title, wrong venue/year" hallucinations that Semantic Scholar sometimes misses.
CVE IDs are pinned, not paraphrased: Always cite as CVE-YYYY-NNNNN; never write "the recent OpenSSL vulnerability". Verify via https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN. If the CVE is reserved-but-not-public, mark [CVE RESERVED — verify before camera-ready].
PoC / exploit commit hashes: When citing a public exploit, fix commit, or fuzzing campaign, pin the full git SHA (40 hex chars) and the repo URL. Branches and tags move; SHAs do not. Format: \url{https://github.com/<org>/<repo>/commit/<sha>}.
Standards documents: RFCs cite as RFC NNNN plus URL https://datatracker.ietf.org/doc/html/rfcNNNN. NIST publications cite as NIST SP 800-NNN with URL. ISO/IEC numbers must include the year (ISO/IEC 18033-3:2010).
Withdrawn / broken results: If a cited assumption or scheme has been broken (e.g., SIDH/SIKE post-2022), add a footnote acknowledging the break and explain why your construction is unaffected — or change the construction.

Citation summary table (security / crypto extensions)

| Source type | Primary verification | Required field | |-------------|---------------------|----------------| | IACR conference paper | DBLP + IACR ePrint | DOI or ePrint URL | | USENIX Security paper | USENIX site + DBLP | URL to USENIX page | | NDSS paper | NDSS site + DBLP | URL to NDSS page | | IEEE S&P / CCS paper | IEEE Xplore / ACM DL + DBLP | DOI | | CVE | NVD | CVE-YYYY-NNNNN | | RFC | datatracker.ietf.org | RFC number + URL | | NIST SP | NIST CSRC | Document number + URL | | Exploit / PoC | repo + git log | Full commit SHA + URL |

LaTeX Hardening

Templates live in templates/ (one per venue family). Common rules:

Anonymity per venue

| Venue | Review type | Author field at submission | |-------|-------------|---------------------------| | IEEE S&P | Double-blind | \author{Anonymous Submission \#NNN} | | ACM CCS | Double-blind | acmart anonymous option: \documentclass[sigconf,anonymous]{acmart} | | USENIX Security | Double-blind | \author{Paper \#NNN} (no affiliation) | | NDSS | Double-blind | \author{Anonymous} | | PETS / PoPETs | Double-blind | sciendo / popets style | | CRYPTO / Eurocrypt / TCC | Anonymous since 2018 for first review round | LNCS authblk omitted | | ACSAC | Double-blind (recent years) | [VERIFY: ACSAC current policy each year] |

Self-citations: write in third person ("Smith et al.~[12] previously showed ...") even when the cited work is yours; never reveal identity via "in our earlier work [12]".

Theorem / lemma / proof environments

For IACR-style proofs use amsthm:

\usepackage{amsthm}
\newtheorem{theorem}{Theorem}[section]
\newtheorem{lemma}[theorem]{Lemma}
\newtheorem{corollary}[theorem]{Corollary}
\newtheorem{definition}[theorem]{Definition}
\newtheorem{assumption}[theorem]{Assumption}
\theoremstyle{remark}
\newtheorem{remark}[theorem]{Remark}

Numbering: theorem-lemma-corollary share a counter (a Lemma 3.4 between Theorem 3.3 and Theorem 3.5 reads naturally). Definitions and assumptions are often given a separate counter — pick one convention per paper and stick with it.

Algorithm vs protocol pseudocode

Algorithm: single-party computation. Use algorithm + algorithmicx/algpseudocode.
Protocol: multi-party message exchange. Use pseudocode.sty (IACR) or a manual two-column layout — never algorithm for a protocol, because reviewers will (correctly) complain that message direction is unclear.

Citation style per venue

| Venue family | bib style | \cite form | |--------------|-----------|--------------| | IEEE S&P, NDSS | IEEEtran | numeric [12] | | ACM CCS, ACSAC | acmart (ACM-Reference-Format) | numeric [12] | | USENIX Sec | usenix-2020-09 / plain | numeric [12] | | IACR (CRYPTO etc.) | llncs / splncs04 | author-year [Ros21] (alphabetical key) | | PETS | sciendo | numeric [12] |

Math hardening

Always typeset \Pr, \Pr_{\text{game}}, \negl, \poly, \ppt as macros, not raw text.
Use \mid or \,|\, for conditional probability bars, never raw |.
Security parameter is \lambda by convention (occasionally n); never mix.
Adversary \mathcal{A}; simulator \mathcal{S}; environment \mathcal{Z} (UC); challenger \mathcal{C}.

Domain Anti-Patterns (read before writing)

Minimum eight. Detailed bad-→-rewritten examples in references/anti-patterns.md.

| # | Anti-pattern | Why it fails | Correct behavior | |---|--------------|--------------|------------------| | 1 | "Novel construction" with no threat model | Reviewer cannot tell what is being claimed; security is undefined | Dedicated Threat Model section before construction; state adversary capabilities, goals, scope | | 2 | Informal "we believe this is secure" where a game-based proof is expected | Theoretical-crypto venues (CRYPTO, Eurocrypt, CCS-crypto) require formal proofs | State a security definition; prove a Theorem with explicit reduction and advantage bound | | 3 | Missing hardness / setup assumptions | Proof is unverifiable; reviewer cannot place the result on the assumption hierarchy | List all assumptions explicitly (DDH, LWE, ROM, CRS, programmable RO, generic group) at start of security section | | 4 | Evaluation without baseline attacks or a defined adversary | "Our defense reduces attack success" against what attacker, with what budget? | Define attacker model per experiment; include strongest-known attack as baseline; state attacker queries / compute / data | | 5 | Conflating C / I / A | "Confidentiality and integrity are preserved" used interchangeably; AEAD vs MAC vs encryption are different claims | State C, I, A separately; use precise terms (IND-CPA, INT-CTXT, replay-resistance, etc.) | | 6 | Hand-wavy crypto ("we encrypt it") with no scheme, mode, or key management | Implementation cannot be reproduced; AES-ECB lurks behind such phrases | Specify: scheme (AES-256-GCM), nonce/IV policy, key derivation (HKDF-SHA256 with info=...), key rotation, storage | | 7 | Ignoring side channels (timing, cache, power, EM, microarchitectural) | Modern PC will reject without at least a discussion of constant-time / Spectre-class concerns | Explicitly state side-channel scope; if out-of-scope, justify; if in-scope, evaluate (e.g., dudect, cache-timing) | | 8 | Overclaiming DP without ε, δ, composition treatment | "Differentially private" alone is meaningless | State ε, δ; declare unit of privacy (record/user/query); show composition (basic / advanced / RDP) accounting; justify ε choice | | 9 | Conflating semi-honest with malicious adversaries in MPC | A semi-honest protocol does not imply malicious security; a covert protocol does not imply active | Name the adversary class (semi-honest, covert with deterrence ε, active/malicious, UC) and prove against that class | | 10 | "We use a TEE" with no attestation chain | Without remote attestation + measurement, TEE claims are unverifiable | Specify TEE (SGX, SEV-SNP, TDX, TrustZone, Keystone), attestation flow, what is in/out of TCB, recent break/CVE awareness |

[VERIFY: confirm anti-pattern list count after final edit]

Composition with Other Skills

This skill is small on purpose. Compose with:

ml-paper-writing (Orchestra-Research): writing philosophy (narrative, 5-sentence abstract, Gopen-Swan), LaTeX template practice, ML-internal sections (architectures, training curves) inside a security paper. Invoke explicitly when an ML-heavy section is being drafted.
academic-paper-reviewer (Imbad0202): pre-submission peer-review simulation, reviewer-loop / R&R workflows, Devil's-Advocate review, traceability matrix from reviewer comments to manuscript edits. Invoke before submission and after receiving R&R reviews.
academic-paper (Imbad0202): only for plan-mode Socratic guidance when the user is unsure of structure — this skill takes over once the paper has a contribution sentence.
deep-research (any): for systematic literature scans before drafting Related Work.

IRON RULE — anti-leakage: the manuscript must never contain text generated by academic-paper-reviewer, peer_reviewer_agent, or any reviewer-simulating agent. Reviewer artifacts are inputs to revision planning only.

Iron Rules (non-negotiable)

IRON RULE — No fabricated citations. Every BibTeX entry is fetched programmatically and verified in two sources. Unverified → [CITATION NEEDED].
IRON RULE — No security property without a threat model. Never write "is secure", "is private", "is unforgeable" without a stated adversary class and assumption set.
IRON RULE — No DP claim without (ε, δ), composition, and unit-of-privacy. "Differentially private" alone is rejected.
IRON RULE — No reviewer-text leakage. Never copy reviewer-simulator output into the manuscript body.
IRON RULE — Pin CVEs and exploit commits. CVE-YYYY-NNNNN and 40-char SHA, not paraphrases.
IRON RULE — Anonymity at submission. Self-citations in third person; affiliations stripped; acknowledgements removed.
IRON RULE — Ethics before publication. If the work touches humans, vulnerabilities, or sensitive data, the Ethics / Responsible-Disclosure section is mandatory and is drafted before the camera-ready, not after.
IRON RULE — Passive preprint only under review. A preprint may be posted passively (IACR ePrint / arXiv, no promotion). Never publicize a paper that is under blind review — no social posts, no repository announcements, and never name the submission venue in any public field. Active publicizing can be a policy violation, not just a bias risk. See references/lessons-from-practice.md §6.
IRON RULE — Every numeral traces to the fact pack. No figure, rate, or formula enters the manuscript unless it traces to the single source-of-truth fact pack; unknowns are visible placeholders ([TBD] / % TODO), never invented numbers. See references/lessons-from-practice.md §2.

Reference Documents (progressive disclosure)

| Document | Contents | |----------|----------| | references/venues.md | Per-venue page limits, anonymity, deadline patterns, artifact formats, distinctive expectations | | references/threat-models.md | Dolev-Yao, semi-honest vs malicious MPC, IND-CPA/CCA games, network adversaries, side channels | | references/crypto-conventions.md | Notation, hardness assumptions, proof structure (game hops, hybrids, simulation), tightness | | references/privacy-conventions.md | DP variants, composition, anonymization vs DP, ML privacy attacks | | references/ethics-disclosure.md | IRB language, 90-day disclosure, CVE process, artifact-eval expectations | | references/anti-patterns.md | Bad → rewritten examples for every anti-pattern in the table above | | references/lessons-from-practice.md | Process & workflow lessons: framing, fact-pack discipline, reviewer loop, figures, preprint/double-blind handling, evaluation rigor, repo & commit hygiene |

LaTeX templates live in templates/ — one per venue family with double-blind preamble, theorem environments, and a sample threat-model + security-claim block.

Acknowledgements

This skill builds on:

Orchestra-Research / AI-Research-SKILLs (MIT) — ml-paper-writing skill. The citation-verification protocol structure is reused with attribution.
Imbad0202 / academic-research-skills (license per repo) — academic-paper and academic-paper-reviewer. This skill defers reviewer-loop and R&R work to those skills.

See LICENSE and README.md for full attribution.