Venue calibration

Everything numeric in this file (page limits, word limits, cycles, dates) changes between years. Treat it as orientation only and CHECK THE CURRENT CFP. Record the CFP URL, the date you read it, and the exact quoted rules in SUBMISSION.md before you rely on them. Desk rejection "without consideration of merits" is common for format violations.

1. Format and process at a glance

Class files: never modify margins, fonts or spacing. LNCS: llncs.cls + splncs04.bst. IACR journals: follow the current class instructions; the submission option usually anonymises and adds line numbers ($$...$$ can break line numbering; use \[...\]).

2. What reviewers weigh (heuristic weights for mock review)

Venue-specific extra attention:

• CRYPTO/EUROCRYPT: proof tightness, standard vs idealised models, assumption minimality, a genuinely new technique. Pure constant-factor engineering is rarely enough.
• ASIACRYPT/PKC: slightly more tolerant of solid incremental improvements with a clear technique; implementation is a plus.
• TCC: new definitions/paradigms, broad applicability, connections to complexity.
• TCHES: real hardware/software measurements, fair comparison with best existing implementations, open source, side-channel considerations where relevant.
• ToSC/FSE: complete, conservative security analysis; design rationale backed by search evidence; test vectors; comparisons at equal failure probability and threads.
• Security conferences: threat model clarity, deployment realism, ethics and responsible disclosure, artifact availability, end-to-end evaluation.

3. Typical rejection reasons (and the pre-emptive fix)

4. Contribution type vs venue (observed heuristics, not rules)

From tracing publication lineages in several subfields:

• A new named algebraic structure (group action, module structure, known mathematical object) + measured gain → EUROCRYPT/ASIACRYPT/TCC-level.
• New assumption + reductions + attacks considered + measured gain + cross-scheme applicability → CRYPTO-level.
• Pure engineering (SIMD, memory layout, hardware) with real hardware numbers → TCHES.
• New key distribution with self-built security analysis → often security venues; the self-built analysis rarely convinces both crypto and performance reviewers.
• Porting a known trick to a neighbouring setting with a small gain → second-tier venues.
• "We organised the field" without a new result → workshop/SoK unless framed as SoK with a methodology.
• Speedup size correlates weakly with venue tier; the structure used to obtain it correlates strongly. Roughly ≥1.3× is a minimum for a performance claim to matter.

5. Scoring rubric used by mock-review

Normalised six-point scale (map to the venue form when known): 1 strong reject · 2 reject · 3 weak reject · 4 weak accept · 5 accept · 6 strong accept. Confidence 1–4. A paper that gets one champion (≥5, confidence ≥3) and no strong detractor usually survives discussion at IACR venues; one well-argued technical reject (e.g. a counterexample) usually sinks it.

Calibration anchors:

• 6: new technique that will be reused; clean proofs; convincing evaluation.
• 5: clear technical contribution, minor presentation issues.
• 4: useful result, some doubts (baseline fairness, scope) that a rebuttal can fix.
• 3: interesting but claims exceed evidence, or novelty unclear vs a named prior work.
• 2: a correctness problem, or contribution judged incremental.
• 1: wrong, out of scope, or format violation.

Never report a probability of acceptance as if it were statistical; if asked, give a subjective band with the conditions that move it.

6. Procedure

1. Fetch and quote the current CFP (WebFetch) into SUBMISSION.md §Venue.
2. Fill the table rows for the target venue with the quoted values.
3. Choose the mock-review personas and weights from §2.
4. Adjust the playbook budget (section shares, page limit, two-column vs LNCS).
5. Re-check the CFP one week before the deadline (rules and deadlines do change).