💻 computer science

CrypFormBench: Benchmarking Formal Analysis Capability of Large Language Models for Cryptographic Schemes

This paper introduces CrypFormBench, a comprehensive benchmark comprising 700 instances across 677 cryptographic schemes and 7 formal verification languages, to evaluate and reveal the current limitations of large language models in generating and correcting formal security proofs while offering practical strategies to improve their performance.

Original authors: Zhaoxuan Li, Qionglu Zhang, Hengyuan Liu, Xiaoyan Gu, Xianhui Lu, Hongbo Liu, Bingzheng Wang, Haihui Fan, Ziming Zhao, Rui Zhang, Li Zhou

Published 2026-06-25

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Zhaoxuan Li, Qionglu Zhang, Hengyuan Liu, Xiaoyan Gu, Xianhui Lu, Hongbo Liu, Bingzheng Wang, Haihui Fan, Ziming Zhao, Rui Zhang, Li Zhou

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: The "Translator" Problem

Imagine you are a master architect who designs incredibly secure vaults (cryptographic schemes). You write your blueprints in plain English so anyone can understand the plan. However, to actually build and test these vaults for weaknesses, you need to translate those English blueprints into a very strict, ancient, and complex language that only specific, high-tech security robots (formal verification tools like Scyther or Tamarin) can understand.

This translation is hard. It requires a human expert who knows both the vault design and the robot's strict language. If you miss one tiny comma or use the wrong word, the robot rejects the blueprint, or worse, it builds a vault that looks secure but has a hidden backdoor.

The Question: Can Large Language Models (LLMs)—the AI chatbots we use today—act as these expert translators? Can they take a plain English description of a security protocol and instantly write the perfect, error-free code for the security robots?

The Answer (according to this paper): Not quite yet. They are getting better at reading and fixing, but they still struggle to write from scratch.

The Solution: CrypFormBench (The "Gym" for AI)

To find out exactly how good these AI translators are, the researchers built a massive testing ground called CrypFormBench (or C.F.B).

Think of this as a gym with 700 different workout stations.

The Equipment: They gathered 700 real-world security protocols (like the ones used in your phone, banking, or the internet).
The Languages: They translated these protocols into 7 different "robot languages" (formal languages like SPDL, HLPSL, EasyCrypt, etc.).
The Tests: They didn't just ask the AI to write code. They tested five specific skills:
1. Interpretation: "Here is a robot code; explain it to me in English." (Reading)
2. Generation: "Here is an English description; write the robot code." (Writing from scratch)
3. Completion: "Here is a robot code with holes in it; fill in the blanks." (Fixing partial work)
4. Transformation: "Here is the code in Language A; rewrite it in Language B." (Translating between robots)
5. Correction: "This robot code has an error; fix it." (Debugging)

The Results: The AI's Report Card

The researchers tested 9 of the smartest AI models available (including GPT-4o, Claude-3.5, and DeepSeek). Here is what they found:

1. The "Good at Reading" Skill (Interpretation & Completion)

Analogy: Imagine a student who is great at reading a textbook and can fill in the missing words in a sentence because the context is already there.
Result: The AIs were surprisingly good at this. When given a code snippet with a few missing parts, or asked to explain what a piece of code does, they performed very well. They understood the "grammar" of the security languages.

2. The "Bad at Writing" Skill (Generation & Transformation)

Analogy: Now imagine asking that same student to write a whole new textbook from scratch, or translate a book from French to Japanese without a dictionary. They start hallucinating, making up rules, or forgetting the strict grammar.
Result: This is where the AIs failed.
- Generation: When asked to write a full security protocol from a plain English description, most AIs produced code that the robots couldn't even run. It was like writing a sentence with broken syntax.
- Transformation: When asked to translate code from one robot language to another, the AIs often got confused. They would mix up the rules of the two languages, creating a "frankenstein" code that didn't work in either.
- The Score: Even the best AI (Claude-3.5) only scored 48.7 out of 100. This means less than half of their attempts were actually usable by the security tools.

3. The "Fixing" Skill (Correction)

Analogy: If you give the student a sentence with a clear typo (e.g., "recieve" instead of "receive"), they can fix it easily. But if the sentence is grammatically correct but logically wrong (e.g., "The vault is open to everyone, but it is secure"), they struggle to find the logic error.
Result: The AIs were good at fixing simple syntax errors (typos). However, they struggled with "semantic" errors—fixing the logic of the security protocol itself.

Why is this so hard?

The paper explains that these "robot languages" are not like Python or Java. They are extremely strict.

The "One Mistake" Rule: In normal coding, if you miss a semicolon, the computer might just complain. In these security languages, one missing word can change the entire meaning of the security proof, making a secure vault look insecure, or vice versa.
The "Context" Problem: These protocols often depend on long chains of events (e.g., "If Alice sends a message at step 1, Bob must reply at step 2, but only if he hasn't seen a message from step 0"). AIs often lose track of these long chains.

What Can We Do? (The "Training Wheels")

The paper suggests that while we can't rely on AIs to do the whole job alone yet, we can use them as assistants if we give them the right help:

Few-Shot Prompting: Instead of just saying "Write this," show the AI three examples of how to write it first. This acts like a cheat sheet.
Pass@K: Ask the AI to try writing the code 5 times, and then pick the best one. This increases the odds of getting a working version.
Human-in-the-Loop: Use the AI to draft the code, but have a human expert check it before the security robot runs it.

The Bottom Line

The paper concludes that Large Language Models are currently excellent research assistants for understanding and fixing security code, but they are not yet reliable architects for building new security protocols from scratch.

They can help you read the manual and fix your typos, but you still need a human expert to ensure the vault is actually secure before you hand the keys over. The benchmark (CrypFormBench) is now available for other researchers to test new AI models against these same strict standards.

Technical Summary: CrypFormBench

1. Problem Statement

Manual formal analysis of cryptographic schemes is labor-intensive, requiring deep expertise in both cryptography and formal specification languages. While automated tools like Scyther, Tamarin, CryptoVerif, and EasyCrypt exist, they still rely on experts to abstract scheme logic into specialized, error-prone formal languages (e.g., HLPSL, SPDL, applied $\pi$ -calculus). Large Language Models (LLMs) offer a potential solution for automating the derivation of formal specifications from natural language. However, their effectiveness in this domain remains unexplored due to the absence of standardized evaluation methodologies.

Existing benchmarks are insufficient because they often:

Support only symbolic security, neglecting computational security.
Cover limited scales (e.g., ~18 protocols) and exclude diverse threat models or advanced primitives (e.g., Zero-Knowledge, Post-Quantum).
Lack a unified framework to evaluate LLMs across multiple formal verifier languages and task types (generation, transformation, correction).

2. Methodology: CrypFormBench (C.F.B)

The authors introduce CrypFormBench, a comprehensive benchmark designed to evaluate LLM capabilities in formal cryptographic analysis. The methodology involves three core components:

A. Dataset Construction

Scale and Diversity: The dataset comprises 700 curated instances derived from 4,549 open-source projects and tool datasets. These instances cover 677 distinct cryptographic schemes (ranging from classical authentication to modern MPC, ZK, and post-quantum designs) and 160 security properties.
Language Coverage: It spans 7 mainstream formal verifier languages associated with tools including Scyther (SPDL), Tamarin (SPTHY), AVISPA (HLPSL), ProVerif (PV/HORN), Maude-NPA (MAUDE), CryptoVerif (CV/OCV), and EasyCrypt (EC).
Adversarial Models: The dataset includes diverse adversary assumptions, from passive/active Dolev-Yao models to extended models (CK, eCK) and domain-specific threats (e.g., IoT password guessing).
Quality Control: A rigorous pipeline was employed involving deduplication, executability checks, and manual verification. Instances were labeled as "safe" (no known attacks) or "unsafe" (known attacks), with tool outputs aligned against canonical labels from cryptographic literature.

B. Task Definition

The benchmark evaluates five core LLM capabilities essential for tool-usable formal specification:

Interpretation: Generating notation-level comments and global scheme summaries from formal code.
Generation: Creating complete formal code from natural-language logic descriptions.
Completion: Filling in missing fragments of partially masked formal specifications.
Transformation: Translating scheme specifications from one formal language to another while preserving semantics.
Correction: Repairing code that fails to compile (syntax errors) or produces incorrect verification results (semantic errors).

C. Evaluation Pipeline

Automated Verification: An end-to-end pipeline integrates multiple tools, versions, and execution commands to verify LLM outputs. It handles varying call behaviors (e.g., multiple backends for AVISPA) and version incompatibilities.
Scoring Framework: Performance is measured via a weighted scoring system balancing:
- Executability (Analyzability): Whether the code compiles and runs.
- Functional Correctness: Whether the verified security properties match ground truth (SAFE/UNSAFE), measured by Accuracy ( $ACC_A$ ) and F1 ( $F1_A$ ).
- Similarity: Code similarity for completion tasks and semantic similarity (via embeddings) for interpretation tasks.
- Efficiency: Runtime and file size.

3. Key Results

The authors evaluated 9 state-of-the-art LLMs (including GPT-4o, Claude-3.5-Sonnet-Coder, DeepSeek-Coder, and LLaMA4-Instruct).

Overall Performance: Performance is generally limited. The highest-performing model, Claude-3.5-Sonnet-Coder, achieved an overall score of 48.7 out of 100.
Task-Specific Insights:
- Strengths: Models perform well on Interpretation and Completion, leveraging their code-awareness. For example, DeepSeek-Coder and GPT-4o show high accuracy in interpreting existing code.
- Weaknesses: Models struggle significantly with Generation, Transformation, and Correction.
  - Generation: Even top models achieve low analyzability ratios (e.g., ~15% for Claude-3.5) and struggle with strict syntax/semantics in complex languages like EasyCrypt and Maude.
  - Transformation: This is the most difficult task. Cross-language interference and semantic mismatches lead to very low analyzability (often <10%), with models frequently copying source fragments that are incompatible with the target language's idioms.
  - Correction: While models can fix localized syntax errors (compiler-guided), they struggle with semantic repairs (e.g., fixing false reports of security properties).
Language Variability: Performance varies sharply by language. Models generally perform better on ProVerif (PV) due to its similarity to mainstream programming syntax, while struggling with rewriting-based tools like Maude-NPA.
Optimization Strategies:
- Few-Shot Prompting: Significantly improves analyzability for generation (from 6.6% to 24.9% with 3-shot) and correctness for correction.
- Pass@K: Increasing the number of generation attempts ( $K$ ) improves the probability of obtaining an analyzable output, particularly for hard tasks, though it does not guarantee semantic correctness.
- Fine-Tuning: Lightweight LoRA fine-tuning on Qwen2.5-Coder-3B improved completion and correction capabilities but had minimal impact on generation or transformation.

4. Significance and Claims

The paper claims to provide the first comprehensive benchmark that jointly covers symbolic and computational security for evaluating LLMs in cryptographic scheme analysis.

Grounded View: The authors assert that while LLMs are promising assistants for interpretation and localized correction, they are not yet reliable for end-to-end automation of formal scheme generation or cross-language transformation.
Bottleneck Identification: The primary barrier is not just semantic reasoning but executability—the ability to produce code that satisfies strict formal syntax and tool-specific constraints without triggering timeouts or parse errors.
Practical Guidance: The study offers concrete directions for improving LLM-assisted analysis, including the use of few-shot prompting, Pass@K sampling, and lightweight fine-tuning to mitigate the executability bottleneck.
Reproducibility: The benchmark and dataset are released to enable systematic, standardized, and reproducible evaluation of future models in this domain.

The authors conclude that current LLMs serve as strong "drafting" tools but require human-in-the-loop validation or tool-guided repair workflows to be practically useful for formal cryptographic analysis.