Crypto Protocol Diagram · SKILL
Provide protocol source code, an RFC, a paper excerpt, or a formal model. Get a sequence diagram that identifies participants, message direction, cryptographic operations, and failure branches.
See exactly what each signature covers, whether verification happens before key derivation, and where processing stops after a failed check. Details scattered across functions and sections become one flow you can review against the source.
See the bundled cases
Turn protocol logic scattered across functions, sections, and models into a message chain that can be checked against the source.
Before
Entry points, message structures, signatures, and key derivation live in different files. A reviewer has to jump between them to reconstruct who sends and who verifies.
After
Participants and messages appear in their actual order. Local computations sit beside the party performing them, with setup, handshake, and data phases clearly separated.
Instead of holding the protocol in your head, follow one diagram back into the source.
Before
A conventional diagram says “send message” and “return result,” while signatures, DH, HKDF, and encryption remain implicit.
After
The diagram names key operations and their inputs and outputs. A review can ask precisely what a signature binds and which material produces the session key.
The result shows protocol semantics, not only traffic direction.
Before
Signature failures, MAC mismatches, and rejected conditions are often buried in branches.
After
Known failure conditions become explicit branches. Unspecified ordering, implied roles, and unnamed algorithms are flagged for follow-up.
The review sees the abort conditions alongside the happy path.
Reading a handshake implementation means finding the entry point, then following send, recv, message structures, and state changes through several functions. In a specification, roles may be defined early, wire formats later, and rejection conditions somewhere else. Formal models express the same interaction through in, out, rules, and facts.
General diagramming tools can draw arrows, but they do not determine who computes DH, what a signature covers, or whether a conditional branch terminates the exchange. The reviewer still has to align code, specification, and diagram by hand.
That gap matters when the diagram enters a security review, design discussion, or research note. A reversed arrow or missing verification step can put the rest of the conversation on the wrong flow.
What the review needs is not a prettier arrow chart. It needs a message chain that can be checked against the original material.
Extracting roles, messages, and computations before drawing gives every arrow a source and every cryptographic operation an owner.
Provide source code, an RFC or paper excerpt, pseudocode, a ProVerif file, or a Tamarin model, and name the part of the protocol you want to inspect.
The Skill first classifies the input as code, specification, or both. It identifies participants, matches sends and receives in order, annotates signing, verification, DH, HKDF, encryption, hashing, or commitments, then writes phases, loops, parallel actions, and failure paths into a Mermaid sequenceDiagram.
When both specification and implementation are available, the specification becomes the baseline and implementation differences are marked on the diagram. Inferred ordering, unnamed roles, and underspecified algorithms are flagged rather than silently resolved.
The main deliverable is an editable Mermaid Markdown file. An ASCII sequence diagram and protocol summary are included for quick review without a renderer.
Code, specification, or both
Participants, messages, and order
Signing, DH, HKDF, and checks
Mermaid, ASCII, and a protocol summary
$ python protocol.py Handshake complete. Session keys match. Decrypted: b'hello, responder'
Both parties derived the same session key and successfully encrypted and decrypted application data.
For this page, the bundled protocol.py was executed directly. The initiator and responder authenticate ephemeral X25519 keys with long-term Ed25519 keys, derive a session key with HKDF-SHA256, then encrypt and decrypt application data with ChaCha20-Poly1305.
The terminal returned Handshake complete. Session keys match. and successfully decrypted hello, responder. The same source was converted into simple-authenticated-key-exchange.md, covering both handshake messages, both signature checks, DH, HKDF, local exception branches, and application-data processing.
The second example is a ProVerif model. Alice sends an identity, Bob creates a fresh nonce, Alice returns HMAC(k, nonce || identity), and Bob either accepts or aborts.
The expected output pairs out and in operations as messages, converts if/then/else into success and failure branches, and notes that all traffic crosses a Dolev-Yao adversary network.
The first case includes a run log and the Mermaid file generated in this project. The second comes from the bundled formal model and expected output. They demonstrate the workflow and artifact format; they do not establish that an arbitrary protocol is secure.
The run log and Mermaid file are stored in the project actual-run folder. AI-generated imagery on this page is conceptual and is not presented as run evidence.
The Skill reads source or specification systematically before extracting the message flow. Participants, arrows, and computations can be checked against the input instead of being filled in from a protocol name.
Signing, verification, DH, HKDF, encryption, and hashing are not reduced to “secure processing.” Reviewers can see who computes each value, what material it uses, and whether it happens before or after a message.
When both are supplied, the diagram can expose missing checks, extra fields, or different message ordering. The team no longer has to compare two descriptions verbally.
Mermaid source can live in project documentation, review records, or research notes. When the protocol changes, regenerate the affected flow and retain a clear basis for version-to-version discussion.
Protocol discussions often begin with different mental versions of the same flow. Developers remember code branches, auditors focus on checks, and researchers may infer ordering from a different section of the specification.
Putting roles, messages, computations, and failure paths on one diagram gives the team concrete steps to discuss. Saving that diagram beside a specific source or specification version also creates a clear starting point for later changes.
The lasting value is not drawing arrows faster. It is avoiding the repeated work of reconstructing protocol logic before every review.
View the official Skill source
Provide protocol source code, a specification section, paper pseudocode, or a formal model, and identify the phase you want to inspect.
Receive an annotated Mermaid sequence diagram, an ASCII trace, and a protocol summary to start the next code review or security discussion.