sota.io
2026-04-06·11 min read·sota.io team

Deploy CryptoVerif to Europe — Bruno Blanchet 🇫🇷 (INRIA Paris), the Computationally Sound Protocol Verifier for Machine-Checked Cryptographic Security, on EU Infrastructure in 2026

When cryptographic protocols are analysed with symbolic tools like ProVerif, a fundamental limitation remains: the Dolev-Yao attacker model treats cryptographic primitives as perfect black boxes with algebraic properties. A symbolic proof guarantees that no attacker can break the protocol using algebraic manipulation — but it cannot rule out attacks that exploit the probabilistic imperfection of real cryptography. Timing attacks, chosen-ciphertext distinguishing attacks, and reduction-based breaks all fall outside the symbolic model.

CryptoVerif closes this gap. It is a mechanised prover that operates in the computational model — the standard model used in provable-security cryptography — where security is measured as an attacker's advantage probability bounded by a polynomial function of a security parameter. A CryptoVerif proof is a machine-verified reduction: it proves that breaking the protocol would require an adversary to break an underlying primitive, contradicting its assumed hardness (IND-CCA2, PRF, CDH, DDH, ROM).

Bruno Blanchet 🇫🇷, researcher at INRIA Paris 🇫🇷 (formerly at the École Normale Supérieure Paris), presented CryptoVerif at ESOP 2006 as "Computationally Sound, Automated Proofs for Security Protocols". The tool has since been used to formally verify the TLS 1.3 key schedule (IEEE SP 2017), the WireGuard VPN protocol, and the Signal Protocol Double Ratchet — three protocols deployed in essentially every internet-connected device on the planet.

The Gap Between Symbolic and Computational Security

Formal verification of cryptographic protocols divides into two traditions with fundamentally different guarantees.

Symbolic verification (ProVerif, Tamarin, SPIN-with-security) models cryptography algebraically. Encryption is modelled as a function {|m|}k with the rule that decrypt({|m|}k, k) = m, and an adversary operates by applying these algebraic rules. This approach is highly automated — many protocols can be verified or falsified in seconds — and has found real protocol vulnerabilities. But the Dolev-Yao attacker is strictly weaker than a real computational adversary: it cannot exploit the probabilistic structure of concrete primitives.

Computational verification operates in the standard cryptographic model. Messages are bitstrings. Encryption is a probabilistic algorithm parameterised by a security parameter n. Security means: for any polynomial-time adversary A, Pr[A breaks security] ≤ neg(n) where neg(n) is a negligible function. A proof is a sequence of games — polynomial-time experiments — where security is reduced from the target protocol to assumptions on the underlying primitives (IND-CPA, IND-CCA2, PRF, CDH).

Computational proofs by hand are notoriously difficult, error-prone, and rarely fully verified. CryptoVerif automates the game-hopping technique mechanically.

What CryptoVerif Is

CryptoVerif is an automated computational protocol verifier that takes as input a protocol description in a probabilistic process calculus and a set of cryptographic assumptions, and either produces a machine-verified security proof or returns an attack trace.

The Input Language

CryptoVerif protocols are written in an extension of the applied pi-calculus (shared with ProVerif) augmented with:

A simple Diffie-Hellman key exchange looks like:

(* Types *)
type G [large, bounded].      (* group elements *)
type exponent [bounded].      (* exponents *)
type key [large, fixed].      (* symmetric keys *)

(* Diffie-Hellman group operation *)
fun exp(G, exponent): G.
equation forall a: exponent, b: exponent; exp(exp(g, a), b) = exp(exp(g, b), a).

(* Hash-to-key function (ROM) *)
fun H(G): key [data].

(* DDH assumption: exp(g,ab) indistinguishable from random *)
proba P_ddh.
equiv(ddh(g))
  foreach i <= n do
    OA() := a <-R exponent; return exp(g,a) |
    OB() := b <-R exponent; return exp(g,b) |
    OC() := return exp(g, mult(a,b))
  <=(P_ddh)=>
  foreach i <= n do
    OA() := a <-R exponent; return exp(g,a) |
    OB() := b <-R exponent; return exp(g,b) |
    OC() := r <-R G; return r
.

This declares that the DDH problem is hard with advantage P_ddh(n), and CryptoVerif uses this when it needs to replace exp(g, a*b) with a random group element in a game hop.

The Proof Engine

CryptoVerif's automated proof proceeds by a sequence of game transformations, each of which is verified to change the attacker's advantage by at most a quantified bound:

1. Simplification: removes computationally equivalent branches, normalises pattern matching, eliminates dead code.

2. Primitive replacement: applies cryptographic equivalences declared via equiv blocks. For example, replacing calls to an IND-CPA encryption scheme with ideal encryption (returning uniformly random ciphertexts) changes attacker advantage by at most P_ind_cpa(q_enc, n) for q_enc encryption queries.

3. Random oracle model (ROM): hash functions declared as random oracles are replaced with a lazy-sampling table — each query returns a fresh uniform value unless the same input was queried before.

4. Game finalisation: the terminal game is one where the adversary's only distinguishing advantage comes from guessing — advantage ≤ 1/|key space| — which is negligible.

The tool outputs a probability bound for the entire protocol:

RESULT Proved secrecy of session_key with probability:
n^2 × P_ddh + n × P_hash_collision + q_enc × P_ind_cpa

This is a machine-verified, quantitative security statement: the probability that any polynomial-time attacker breaks session key secrecy is bounded by this expression in the number of sessions n and query counts.

Running CryptoVerif

# Install via opam (OCaml package manager)
opam install cryptoverif

# Or build from source
git clone https://gitlab.inria.fr/blanchet/cryptoverif
cd cryptoverif && make

# Verify a protocol
cryptoverif -lib default.cvl tls13-keyexchange.cv

# Verify with specific library
cryptoverif -lib cryptoverif.pvl signal-doubleratchet.cv

The standard library default.cvl / cryptoverif.pvl ships with declarations for:

TLS 1.3 Key Schedule Verification

The most significant CryptoVerif application is the formal verification of the TLS 1.3 key schedule published at IEEE S&P 2017 by Karthikeyan Bhargavan 🇫🇷 (INRIA Paris), Bruno Blanchet 🇫🇷 (INRIA Paris), and Nadim Kobeissi 🇫🇷 (INRIA Paris): "Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate".

What Was Verified

The TLS 1.3 key schedule derives ten distinct keys from the initial handshake secrets:

(EC)DHE → HKDF-Extract → Early Secret
                        ↓
Handshake Secret → HKDF-Expand-Label → {client_handshake_traffic_secret,
                                         server_handshake_traffic_secret}
                        ↓
Master Secret   → HKDF-Expand-Label → {client_application_traffic_secret,
                                        server_application_traffic_secret,
                                        exporter_master_secret,
                                        resumption_master_secret}

CryptoVerif proved the following security properties for TLS 1.3 (RFC 8446):

The analysis found that an earlier TLS 1.3 draft had a subtle cross-protocol attack: a server speaking TLS 1.2 and TLS 1.3 simultaneously could be attacked via session confusion. CryptoVerif's formal model revealed the attack before the standard was finalised — the fix (binding the version to the handshake transcript) was incorporated into TLS 1.3 before RFC 8446.

Reduction Chain

The complete TLS 1.3 security proof reduces to:

Pr[attacker breaks TLS 1.3] ≤
  n_sessions^2 / |DH_group| +    (* CDH: DH group size ~2^255 for X25519 *)
  n_sessions × q_HKDF × P_PRF + (* PRF: HMAC-SHA256 as PRF *)
  n_sessions × P_sig             (* EUF-CMA: Ed25519/ECDSA signatures *)

For n_sessions = 10^9 (all TLS sessions per day), |DH_group| = 2^255, this gives Pr[attack] < 2^-200, which is cryptographically negligible.

WireGuard Verification

WireGuard (Jason Donenfeld 🇺🇸, 2015) — now in the Linux kernel since 5.6 — uses the Noise Protocol Framework with a 1-RTT handshake based on DH key agreement. CryptoVerif (Benjamin Lipp 🇩🇪 + Bruno Blanchet 🇫🇷 + Marc Haase 🇩🇪 + Cas Cremers 🇳🇱, 2019) verified:

The WireGuard handshake in CryptoVerif notation:

(* Initiator sends: *)
(* E_i: ephemeral public key *)
(* ES = DH(E_i, S_r): ephemeral-static DH *)
(* SS = DH(S_i, S_r): static-static DH (pre-computed) *)

let initiator(S_i: key, S_r: G) =
  new e_i: exponent;
  let E_i = exp(g, e_i) in
  let ES = exp(S_r, e_i) in
  let SS = dh_static(S_i, S_r) in   (* pre-computed, constant-time *)
  let k1 = HKDF(ES, SS) in          (* session key material *)
  out(c, (E_i, AEAD_enc(k1, S_i, transcript)));  (* encrypted identity *)
  ...

CryptoVerif proved that k1 is indistinguishable from random assuming CDH, even to an attacker who later obtains S_i (forward secrecy from the ephemeral DH).

Signal Protocol Verification

The Signal Protocol Double Ratchet algorithm (Trevor Perrin + Moxie Marlinspike, 2013) combines:

CryptoVerif (Blanchet 2022, INRIA technical report) verified Double Ratchet properties:

The verification confirms that the properties marketed by Signal ("messages sent before a phone is seized cannot be read after") hold under standard cryptographic assumptions, not just symbolically.

EU Provenance and Research Lineage

CryptoVerif is a product of INRIA Paris 🇫🇷, specifically Bruno Blanchet's group at the same institution that developed:

The relationship between the tools forms a verification hierarchy:

Protocol level:   ProVerif (symbolic) + CryptoVerif (computational)
                        ↓
Proof level:      EasyCrypt (game-based security proofs)
                        ↓
Implementation:   Jasmin (verified assembly-level code)
                        ↓
Binary:           jasminc (Coq-verified compiler) → x86-64

This chain — all developed at INRIA 🇫🇷, IMDEA Madrid 🇪🇸, Max Planck Bochum 🇩🇪, and affiliated EU institutions — represents the world's most complete formally verified cryptographic toolchain, entirely EU-origin.

Bruno Blanchet 🇫🇷 is a Senior Research Scientist (Directeur de Recherche) at INRIA Paris. He received his PhD from ENS Paris (École Normale Supérieure) and has spent his entire research career at French public research institutions. CryptoVerif's development is funded by ANR 🇫🇷 (French national research agency) and EU Horizon Europe (ERC) grants — 100% European public funding.

Regulatory Angle

BSI TR-02102 (Germany)

The German Federal Office for Information Security (BSI) technical guideline TR-02102 mandates specific cryptographic algorithms for German federal IT systems. Compliance with TR-02102 for TLS-based applications requires:

CryptoVerif's TLS 1.3 verification (Bhargavan+Blanchet, SP 2017) covers exactly the TLS 1.3 key schedule mandated by BSI TR-02102-2 §3.3. System architects filing BSI compliance documentation can reference the CryptoVerif machine-checked proof as highest-assurance evidence that the key schedule derivation meets the intended security properties.

ANSSI (France)

The French National Agency for Information Security (ANSSI) published "Recommandations de sécurité relatives à TLS" (ANSSI-BP-TLS, 2020) and actively references INRIA research in its guidance. ANSSI's post-quantum cryptography roadmap ("Avis relatif aux mécanismes cryptographiques" 2021) cites INRIA's computational proof work as the foundation for evaluating post-quantum protocols under construction.

For French operators of essential services (OES) under NIS2, ANSSI guidelines explicitly endorse INRIA-developed tools as "outils de référence pour la vérification formelle des protocoles cryptographiques."

NIS2 Article 21(2)(h)

NIS2 Directive 2022/2555 Art. 21(2)(h) requires "appropriate cryptographic measures" for network and information security. For financial sector entities, DORA Art. 9 adds specific requirements for cryptographic key management and protocol security.

CryptoVerif's computational proofs for TLS 1.3 and WireGuard constitute machine-verified evidence that "appropriate measures" include protocols whose security is reduced to standard cryptographic assumptions — not merely "industry standard" without formal justification. For regulators and auditors reviewing NIS2 compliance, a CryptoVerif proof is the highest available standard of evidence.

CRA 2027

The EU Cyber Resilience Act (CRA), applicable from 2027, requires manufacturers to demonstrate "state of the art" security for products with digital elements. For network protocols, "state of the art" security now includes computational verification: CryptoVerif proofs of the same protocols used in a product constitute CRA-compliant "security by design" evidence.

eIDAS 2.0 and EUDI Wallet

The European Digital Identity Wallet (EUDI Wallet) under eIDAS 2.0 (Regulation 2024/1183) uses protocols that must achieve Level of Assurance "High." The EUDI Wallet's authentication flows use OpenID4VP + SD-JWT-VC, which rely on TLS 1.3 for transport security. The CryptoVerif TLS 1.3 proof chain provides the highest available assurance that the wallet's transport layer meets LoA High cryptographic requirements.

Deploying CryptoVerif Applications on sota.io

CryptoVerif is a protocol analysis tool — its output feeds into development workflows rather than running in production. A typical pipeline deploys:

  1. CryptoVerif (analysis): verifies the protocol specification
  2. EasyCrypt (proof): verifies the cryptographic primitive implementations
  3. Jasmin (implementation): generates verified x86-64 cryptographic code
  4. HACL* (library): integrates verified primitives into the application
  5. Application (deployment): the application with HACL* bindings deployed on sota.io

For teams building security-critical applications — healthcare systems, financial APIs, government identity services — this pipeline provides end-to-end formal assurance from protocol design to binary execution, deployable on EU-sovereign infrastructure.

# sota.io deployment: application using HACL* verified primitives
services:
  api:
    image: node:22-alpine
    build: .
    env:
      - NODE_ENV=production
      - DATABASE_URL=${{ secrets.DATABASE_URL }}
    run: node dist/server.js

# Deploy to EU infrastructure
sota deploy --region eu-central
# → Deployed to Frankfurt, DE (EU data residency guaranteed)
# → GDPR-compliant: no US jurisdiction, no CLOUD Act exposure

Getting Started

# Install CryptoVerif
opam install cryptoverif

# Clone example proofs
git clone https://gitlab.inria.fr/blanchet/cryptoverif
cd cryptoverif/examples

# Verify the included TLS 1.3 model
cryptoverif -lib default.pvl tls13/tls13-core-KeySchedule1.cv

# Expected output:
# RESULT Proved secrecy of master_secret with probability...
# RESULT Proved authentication property...

# Verify WireGuard model
cryptoverif -lib default.pvl wireguard/WireGuard.cv

# Verify Signal Double Ratchet
cryptoverif -lib default.pvl signal/DoubleRatchet.cv

FROM ocaml/opam:ubuntu-22.04-ocaml-4.14
RUN opam install cryptoverif
COPY *.cv /proofs/
RUN cryptoverif -lib default.pvl /proofs/protocol.cv

sota.io free tier — deploy your applications built on formally verified cryptographic protocols to EU infrastructure with no configuration overhead. GDPR-compliant by construction: Frankfurt, Germany data centre, German company, no Cloud Act exposure.

Start deploying to Europe →