Protocol Lab

The ask

Me, to Claude

Let's make simulator / animation suite for some encryption protocols I want working on. The goal is to have a simple code structure you and I can write to describe a series of steps and actions taken, and the product should be an animation that displays the steps. For example, one such protocol would be a simple exchange of private/public key pairs between Alice and Bob. They publish public keys to a global knowledge base or channel - then they can communicate accordingly through a new channel. We'd need to show how the keys are used to decrypt each message. A more complex example may be a user who first generated a key with bip39, they make a UserIdentityKey and a Device key, they encrypt the UIDK with the DIDK and publish the UIDK - the UIDK private key is stored in their device, encrypted with the device key. They can share their user private key with other devices they own - then we add more to show how they communicate to Bob etc

What came back

Claude

Engine works as intended: both real protocols validate clean, and the broken one surfaces exactly the three bugs. Publishing.

First version is published as Protocol Lab. You describe a protocol as plain text, one step per line, and it plays it back as an animation.

gen alice: alice.pub alice.priv
publish alice: alice.pub -> registry
fetch bob: alice.pub <- registry
encrypt bob: hi.msg with alice.pub as hi.enc
send bob -> alice: hi.enc via wire
!decrypt eve: hi.enc with eve.priv    ; "!" = must fail
decrypt alice: hi.enc with alice.priv
assert alice has hi.msg               ; the round-trip check

Playback

Actors hold vaults of keys and messages, and channels sit between them. Items fly around, and ciphertexts show what they're sealed under. You can play, step, scrub, and change speed.

Symbolic, not real crypto

Each step is checked against who actually holds what, so a wrong key, a missing fetch, or a leaked secret shows up as a concrete error. That's the round-trip feedback you want.

Presets: Alice ↔ Bob

Alice ↔ Bob with Eve tapping the wire.

Presets: the identity

Your BIP39 → UIK → device key flow, with a second device enrolled and Bob talking to the identity.

Presets: the broken one

A deliberately broken protocol, so you can see the errors.

Editing

The source is editable and re-runnable from the page.

Two decisions

Two decisions I made on the identity flow, so tell me if they're wrong. The device key is symmetric (it seals uik.priv at rest). The second device enrolls with a throwaway keypair.

What next

Next things I'd add: signatures, ratcheting or session keys, and a "recover from seed" flow. If you'd rather write protocols in Python as Dizzy commands, the same engine could take that as input.

Open the full page to write your own.