Mermaid to ProVerif

Reads a Mermaid sequenceDiagram describing a cryptographic protocol and produces a ProVerif model (.pv file) that can be passed directly to the ProVerif verifier.

Tools used: Read, Write, Grep, Glob.

The typical input is the output of the crypto-protocol-diagram skill — a Mermaid sequenceDiagram annotated with cryptographic operations (Sign, Verify, DH, HKDF, Enc, Dec, etc.) and message arrows.

When to Use

• User asks to formally verify a cryptographic protocol described as a Mermaid sequenceDiagram
• User wants to generate a ProVerif model (.pv file) from a protocol diagram
• User wants to prove secrecy, authentication, or forward secrecy properties
• Input is the output of the crypto-protocol-diagram skill

When NOT to Use

• No Mermaid sequenceDiagram exists yet — use crypto-protocol-diagram first to generate one
• User wants to verify properties of non-cryptographic systems (state machines, access control)
• User wants to run ProVerif on an existing .pv file — just run proverif model.pv directly

Rationalizations to Reject

Rationalization	Why It's Wrong	Required Action
"Reachability queries are just busywork"	If events aren't reachable, all other query results are meaningless	Always add reachability queries first as a sanity check
"Public channels are fine for all messages"	Private channels for internal state prevent false attacks	Use private channels for intra-process state threading
"I'll skip the forward secrecy test"	Ephemeral keys demand forward secrecy verification	Add the ForwardSecrecyTest process whenever the diagram shows ephemeral keys
"Unused declarations are harmless"	ProVerif may report spurious results from orphan declarations	Clean up all unused types, functions, and events
"The model compiles, so it's correct"	A compiling model can have dead receives, type mismatches, or impossible guards that make queries vacuously true	Validate reachability before trusting any security query
"I don't need to check the example first"	The example defines the expected output quality bar	Study examples/simple-handshake/ before working on unfamiliar protocols

---

Workflow

ProVerif Model Progress:
- [ ] Step 1: Parse participants and channels
- [ ] Step 2: Inventory cryptographic operations
- [ ] Step 3: Declare types, functions, and equations
- [ ] Step 4: Identify and declare events
- [ ] Step 5: Formulate security queries
- [ ] Step 6: Write participant processes
- [ ] Step 7: Write main process and finalize
- [ ] Step 8: Verify and deliver

Step 1: Parse Participants and Channels

From the Mermaid diagram:

1. Extract every participant or actor declaration. Each becomes a ProVerif process.
2. Count message arrows (->>, -->>, -x, --x). Each distinct A ->> B: label creates a communication step on a channel.
3. Decide channel model:
   • Public channel for any message sent over the network before a secure channel is established (e.g., ClientHello, ephemeral keys, ciphertext to be decrypted by the peer).
   • Private channel only for internal state threading within a single party process (not for cross-party messages).
   • Default: declare one shared public channel c for all cross-party messages. Add per-flow channels only when two distinct parallel sessions must be independent.

free c: channel.

Step 2: Inventory Cryptographic Operations

Walk through every Note over annotation and message label. Build a list of all distinct operations used. Map each to a ProVerif declaration category:

Mermaid annotation	ProVerif category
keygen() → sk, pk	New name (new sk), public key derived via function
DH(sk_A, pk_B)	DH function or exp with group
Sign(sk, msg) → σ	Signature function
Verify(pk, msg, σ)	Equation or destructor
Enc(key, msg) → ct	Symmetric or asymmetric encryption function
Dec(key, ct) → msg	Destructor (equation)
HKDF(ikm, info) → k	PRF/KDF function
HMAC(key, msg) → tag	MAC function
H(msg) → digest	Hash function
Commit(v, r) → C	Commitment function
Open(C, v, r)	Commitment equation

Consult references/crypto-to-proverif-mapping.md for exact ProVerif syntax for each.

Step 3: Declare Types, Functions, and Equations

Build the cryptographic preamble in this order:

1. Types — declare custom types used to distinguish key material:

type key.
type pkey.   (* public key *)
type skey.   (* secret key *)
type nonce.

2. Constants — for fixed strings used as domain separators or labels:

const msg1_label: bitstring.
const msg2_label: bitstring.
const info_session_key: bitstring.

3. Functions — constructors and destructors. Destructors use inline reduc so that the process aborts on verification or decryption failure:

(* Asymmetric encryption *)
fun aenc(bitstring, pkey): bitstring.
fun adec(bitstring, skey): bitstring
    reduc forall m: bitstring, k: skey;
        adec(aenc(m, pk(k)), k) = m.
fun pk(skey): pkey.

(* Symmetric encryption / AEAD *)
fun aead_enc(bitstring, key): bitstring.
fun aead_dec(bitstring, key): bitstring
    reduc forall m: bitstring, k: key;
        aead_dec(aead_enc(m, k), k) = m.

(* Digital signatures — verify returns the message on success, aborts on failure *)
fun sign(bitstring, skey): bitstring.
fun verify(bitstring, bitstring, pkey): bitstring
    reduc forall m: bitstring, k: skey;
        verify(sign(m, k), m, pk(k)) = m.

(* KDF — first arg is key (from DH), second is bitstring (info/context) *)
fun hkdf(key, bitstring): key.

(* MAC *)
fun mac(bitstring, key): bitstring.

(* Hash *)
fun hash(bitstring): bitstring.

(* DH *)
fun dh(skey, pkey): key.
fun dhpk(skey): pkey.

(* Serialization — ProVerif is strongly typed: pkey cannot appear
 * where bitstring is expected. Use these to build signed payloads. *)
fun pkey2bs(pkey): bitstring.
fun concat(bitstring, bitstring): bitstring.

4. Equations — algebraic identities on constructors only (not on destructors, which already have their rewrite rules inline):

equation forall sk_a: skey, sk_b: skey;
    dh(sk_a, dhpk(sk_b)) = dh(sk_b, dhpk(sk_a)).

Only declare what the diagram actually uses. Do not add functions for operations not present.

Step 4: Identify and Declare Events

Events mark security-relevant moments in the protocol execution. Extract them by identifying:

• Begin events (event beginRole(params)): triggered immediately before a party sends a message that depends on a long-term identity commitment (e.g., right before sending a signed message or a MAC'd message).
• End events (event endRole(params)): triggered immediately after a party successfully verifies the peer's identity (e.g., after Verify(...) or MAC check passes, session key confirmed).
• Secrecy markers: any key or nonce that should remain unknown to the attacker after the handshake.

event beginI(pkey, pkey).     (* pk_I, pk_R — fired before sending the signed message *)
event endI(pkey, pkey, key).  (* pk_I, pk_R, session_key — fired after accepting *)
event beginR(pkey, pkey).
event endR(pkey, pkey, key).

Parameters should uniquely identify the session: the parties' public keys, plus the session key or a transcript hash.

Step 5: Formulate Security Queries

Write one query per security property. Choose from:

Reachability (always add first — structural sanity check):

Verify that the success events are actually reachable. If ProVerif reports any of these as false, the model has a structural bug (dead receive, type mismatch, impossible guard) and no other query result should be trusted. Once the model is validated, comment them out if they slow down the main property checks:

(* Sanity: both endpoints must be reachable — comment out once validated. *)
(*
query pk_i: pkey, pk_r: pkey, k: key; event(endI(pk_i, pk_r, k)).
query pk_i: pkey, pk_r: pkey, k: key; event(endR(pk_i, pk_r, k)).
*)

Secrecy (key not derivable by attacker):

Declare a private free name and encrypt it under the session key. The attacker knowing private_I is equivalent to breaking the session key:

free private_I: bitstring [private].

(* In process, after deriving sk_session: *)
out(c, aead_enc(private_I, sk_session));

(* Query: *)
query attacker(private_I).

Weak authentication (if B accepted, A ran at some point with matching params — does not prevent replay):

query pk_i: pkey, pk_r: pkey, k: key;
    event(endR(pk_i, pk_r, k)) ==> event(beginI(pk_i, pk_r)).

Injective authentication (prevents replay — each B-accept corresponds to a distinct A-run):

query pk_i: pkey, pk_r: pkey, k: key;
    inj-event(endR(pk_i, pk_r, k)) ==>
    inj-event(beginI(pk_i, pk_r)).

Forward secrecy: add a ForwardSecrecyTest process to the main process that leaks both long-term secret keys to the attacker, then check that a past session key remains secret. Pair it with a free fs_witness: key [private] declaration and query attacker(fs_witness). See references/security-properties.md → Forward Secrecy, and the worked example in examples/simple-handshake/sample-output.pv.

Choose the strongest applicable query for each property. See references/security-properties.md for the full decision tree.

Step 6: Write Participant Processes

Write one let process per participant. Structure each process to mirror the Mermaid diagram step-by-step, in order.

Template for a two-party protocol:

let Initiator(sk_I: skey, pk_R: pkey) =
    (* Step: generate ephemeral key *)
    new ek_I: skey;
    let epk_I = dhpk(ek_I) in
    (* Step: sign and send msg1 — pkey2bs casts pkey to bitstring *)
    let sig_I = sign(concat(msg1_label, pkey2bs(epk_I)), sk_I) in
    event beginI(pk(sk_I), pk_R);
    out(c, (epk_I, sig_I));
    (* Step: receive msg2 *)
    in(c, (epk_R: pkey, sig_R: bitstring));
    (* Step: verify responder signature — destructor aborts on failure *)
    let transcript = concat(pkey2bs(epk_I), pkey2bs(epk_R)) in
    let _ = verify(sig_R, concat(msg2_label, transcript), pk_R) in
    (* Step: derive session key *)
    let dh_val = dh(ek_I, epk_R) in
    let sk_session = hkdf(dh_val, concat(info_session_key, transcript)) in
    event endI(pk(sk_I), pk_R, sk_session);
    (* Secrecy witness: encrypt private_I under the session key.
     * Declared as: free private_I: bitstring [private].
     * The query attacker(private_I) checks the attacker cannot derive it. *)
    out(c, aead_enc(private_I, sk_session)).

Rules for writing processes:

• Each A ->> B: msg_contents in the diagram becomes:
  • out(c, msg_contents) in A's process
  • in(c, x) (with matching destructuring) in B's process
• Each Note over A: op → result becomes a let result = op in binding
• Each Note over A: Verify(...) becomes a let _ = verify(...) in binding (the destructor aborts on failure — no explicit else needed, modeling abort)
• Use alt blocks in the diagram as if/then/else in the process
• Long-term keys are process parameters; ephemeral values use new

N-party or MPC protocols: write one process per distinct role. For threshold protocols, write a single role process and replicate it !N times in the main process.

Step 7: Write Main Process and Finalize

The main process:

1. Generates long-term keys with new
2. Publishes public keys to the attacker via out(c, pk(sk))
3. Runs participant processes in parallel under replication (!) to allow multiple sessions
4. Optionally leaks long-term keys for forward-secrecy analysis

process
    new sk_I: skey; let pk_I = pk(sk_I) in out(c, pk_I);
    new sk_R: skey; let pk_R = pk(sk_R) in out(c, pk_R);
    (
        !Initiator(sk_I, pk_R)
      | !Responder(sk_R, pk_I)
    )

Place the full file in this order:

(* 1. Channel declarations (free c: channel. / free ch: channel [private].) *)
(* 2. noselect directives (if needed for termination) *)
(* 3. Type declarations *)
(* 4. Constants *)
(* 5. Function declarations *)
(* 6. Equations (algebraic identities on constructors only) *)
(* 7. Table declarations *)
(* 8. Events *)
(* 9. Queries *)
(* 10. Let processes *)
(* 11. Main process *)

Step 8: Verify and Deliver

Before writing the file:

• Every participant in the diagram has a matching let process
• Every out(c, ...) has a matching in(c, ...) on the other side with compatible types
• Every function used in a process is declared in the preamble
• Every destructor uses inline reduc (not a separate equation block)
• Every event in a query is declared and triggered in a process
• Long-term public keys are output to channel c in the main process (attacker can see them — that is the Dolev-Yao model)
• No unused declarations (clean up anything added speculatively)
• If table declarations are present: every insert T(...) has a corresponding get T(...) with compatible column types and matching pattern constraints (=key vs bare name)
• If noselect is used: its tuple structure matches the actual message shapes sent on c (e.g., pairs → mess(c, (x, y)))
• If the Key Exposure Oracle pattern is used: event key_exposed(sk_type) is declared, the oracle in(c, guess: sk_type); if pk(guess) = pk_new then event key_exposed(guess) appears at the end of the process that holds the secret, and the query is query x: sk_type; event(key_exposed(x))

Write the model to a .pv file. Choose a filename from the protocol name, e.g. noise-xx-handshake.pv or x3dh-key-agreement.pv.

After writing, print a brief summary:

Protocol:   <Name>
Output:     <filename>
Queries:    <list each query and what property it tests>
Assumptions: <list modeling decisions and simplifications>

---

Decision Tree

├─ No Mermaid diagram provided?
│  └─ Ask the user: "Please provide the Mermaid sequenceDiagram,
│     or run the crypto-protocol-diagram skill first."
│
├─ Diagram uses DH (not just symmetric crypto)?
│  └─ Use dh/dhpk with commutativity equation
│     See references/crypto-to-proverif-mapping.md → DH section
│
├─ Diagram uses asymmetric signatures (Sign/Verify)?
│  └─ Use sign/verify with inline reduc (not equation)
│     verify returns the message on success; let _ = verify(...) in to abort on failure
│     Distinguish signing key (skey) from verification key (pkey)
│
├─ Diagram has an "alt" block (abort path)?
│  └─ Model as if/then only — the else branch aborts (process terminates)
│     Do NOT add out(c, error_message) unless the diagram shows it
│
├─ Protocol has N > 2 parties?
│  └─ Write one process per role, use ! for replication
│     Pass participant index as a parameter if roles differ by index only
│
├─ Forward secrecy requested?
│  └─ Add a ForwardSecrecy variant in the main process that leaks
│     long-term sk after session; add secrecy query for past session_key
│     See references/security-properties.md → Forward Secrecy
│
├─ Type-checker rejects the model?
│  └─ ProVerif is typed: check every function arg type matches declaration.
│     bitstring is the catch-all; key/pkey/skey/nonce are stricter.
│     Cast with explicit constructors when needed.
│
├─ Protocol has cross-process state coordination (e.g., one process must wait
│  for another to record acceptance before proceeding)?
│  └─ Use ProVerif tables (table/insert/get)
│     See references/proverif-syntax.md → Tables
│
├─ Verification does not terminate after several minutes?
│  └─ Add noselect directive matching the message tuple structure on c
│     See references/proverif-syntax.md → noselect
│
├─ Protocol generates a private-type key (type sk [private]) that is never
│  output directly but whose secrecy should be verified?
│  └─ Use the Key Exposure Oracle pattern instead of query attacker(sk)
│     See references/security-properties.md → Key Exposure Oracle
│
└─ Unsure which security properties to verify?
   └─ Default set: secrecy of session key + injective authentication
      (both directions). Add forward secrecy if diagram shows ephemeral keys.

---

Example

examples/simple-handshake/ contains a worked example:

• diagram.md — Mermaid sequenceDiagram for a two-party authenticated key exchange (X25519 DH + Ed25519 signing + HKDF)
• sample-output.pv — exact ProVerif model the skill should produce, with secrecy and injective authentication queries

Study this before working on an unfamiliar protocol.

---

Supporting Documentation

• references/crypto-to-proverif-mapping.md — Mapping table from Mermaid cryptographic annotations to ProVerif function declarations, equations, and process patterns
• references/proverif-syntax.md — ProVerif language reference: types, functions, equations, processes, events, queries, and common pitfalls
• references/security-properties.md — Decision guide for choosing the right queries: secrecy, authentication (weak vs injective), forward secrecy, unlinkability, and how to model them