OPEN RESEARCH
What CrypTool 2, CyberChef and CrypTool-Online suggest about a tool for applied protocol work.
Cryptography becomes easier to understand when its intermediate states are visible.
A hash should not be only a button and a digest. It should be possible to see the input bytes, encoding and selected construction. A signature should reveal the protected fields and the exact signing input. A protocol should expose how a challenge, key, header and payload become one authenticated statement.
Existing open tools address parts of this problem from different directions. CrypTool 2 provides visual workflows and algorithm demonstrations. CyberChef makes data transformations immediate and composable in a browser. CrypTool-Online offers focused applications that can be opened without installing a desktop environment.
Each is valuable. Together, they also reveal space for a different kind of instrument: an open workbench centred on the boundary between cryptographic primitives and real protocols.
This is not a proposal to place every algorithm behind another graphical interface. The interesting question is whether one environment can make exact bytes, protocol context, test vectors and implementation choices inspectable without hiding them behind convenience.
Three useful traditions
CrypTool 2: workflows that can be seen
CrypTool 2 is a Windows application for learning about cryptography and cryptanalysis. Its visual programming model lets users connect components into executable workflows. The project provides more than 200 templates and integrates explanations with algorithm visualisation.
Its central contribution is spatial. A cryptographic process becomes a graph rather than a sequence buried in source code. Inputs, transformations and outputs can be connected, rearranged and observed. The same environment can support classical cryptanalysis, modern primitives and educational demonstrations.
This is particularly effective for explaining composition. A learner can see that encoding, hashing and signing are separate operations, or that ciphertext moves through several analytic steps.
For applied protocol work, the graph model is promising but would need stronger concepts for typed structures, exact serialized bytes, protocol state and conformance assertions.
CyberChef: transformations with low friction
CyberChef is a browser application for encoding, encryption, compression and data analysis. Operations are assembled into recipes and applied immediately to the input. A recipe can be shared, repeated and adjusted without writing a full program.
Its strength is momentum. Base encodings, byte conversions, hashes, parsing and many other operations are available in one place. An analyst can test an idea quickly, then translate the proven sequence into code if needed.
This style is excellent for investigating unfamiliar data. It also exposes a recurring risk in cryptographic debugging: a convenient operation may silently convert between text, bytes and structured values. A protocol-focused tool should retain CyberChef’s speed while making every type conversion explicit.
CrypTool-Online: focused applications at a URL
CrypTool-Online presents individual applications for exploring cryptology in a browser. Its catalogue spans historical systems, modern encryption, quantum topics and post-quantum demonstrations. A user can select a focused instrument rather than build a complete workspace first.
The advantage is accessibility. A teacher can link directly to one concept. A researcher can publish a small interactive explanation. A visitor can begin without installing a large package.
This suggests that an applied workbench should not require every task to open the full editor. A saved experiment, parser or test vector should have a stable view that can be shared and inspected directly.
The missing object is the protocol statement
Most general cryptographic tools organise work around algorithms or transformations. Applied engineering often begins elsewhere.
The object under examination may be:
- a JWS signing input;
- a COSE
Sig_structure; - an ISO 18013-5 session transcript;
- a secure-messaging command and response;
- a certificate path;
- a QR payload with binary framing;
- a key-diversification input;
- an authenticated encryption construction;
- a token whose protected and unprotected fields differ.
In each case, the important question is not only how AES, SHA-256 or ECDSA works internally. It is how the protocol constructs the bytes given to that primitive and how the receiving implementation interprets the result.
A protocol workbench should make that statement a first-class object.
Exact bytes must remain visible
The tool should show several views of the same object without confusing them:
- original bytes;
- hexadecimal and base-encoded forms;
- decoded data structure;
- protected and unprotected fields;
- canonical or deterministic representation, when applicable;
- bytes passed to hashing, signing or authentication;
- cryptographic result;
- application interpretation.
Moving between views should not modify the underlying input unless the user creates an explicit transformation.
This is where many debugging sessions fail. A tool decodes JSON, reformats it for readability and later signs the reformatted text. Another tool displays a CBOR map but hides whether its original map ordering and integer widths were retained. Both are friendly to the eye and dangerous to the investigation.
Every transformation should state its input type, output type and assumptions.
Recipes need assertions
A transformation recipe answers, “what steps should run?” A protocol experiment also needs to answer, “what must remain true?”
The workbench should let a user attach assertions such as:
- this byte string has this expected digest;
- this field is protected by the signature;
- duplicate map keys are rejected;
- this nonce has the required length;
- this algorithm identifier is allowed by policy;
- this signature fails after one selected field changes;
- two independent constructions produce identical signing bytes;
- an unexpected field does not survive strict decoding.
Assertions turn an exploratory recipe into a reproducible test. They also make negative examples part of the artifact rather than informal notes beside it.
A useful result is not simply a green verification icon. It is a trace showing which preconditions were evaluated and where a modified input first diverged.
Protocols are stateful
A linear pipeline is appropriate for many data transformations. Interactive protocols require state.
The workbench should represent:
- participant roles;
- allowed message sequence;
- generated and received values;
- transcript accumulation;
- key derivation points;
- authentication decisions;
- timeouts, retries and terminal errors.
A small state-machine view could show why a message that is valid in isolation is invalid at that point in the exchange. It could also compare two participants’ transcripts and identify the first byte or state at which they disagree.
This capability would be useful for TLS-like handshakes, mobile document engagement, secure messaging with cards and challenge-response protocols. It would remain educational while addressing failures that occur in real implementations.
Secrets require deliberate handling
A browser workbench invites users to paste whatever they are debugging. Cryptographic data may contain production keys, personal information or operational credentials.
Local execution should be the default. The interface should make clear when any operation requires a network request. Sensitive fields should be marked, redacted in exported traces and excluded from URLs or analytics.
The tool should distinguish demonstration keys from imported secrets. It should discourage pasting production private keys and make ephemeral workspaces easy to clear. Saved projects should record whether secrets were removed before sharing.
Open source helps inspection, but source availability alone does not guarantee safe handling. Builds, dependencies, update channels and hosted deployments remain part of the trust model.
Reproducibility needs versioned operations
A shared recipe is useful only if it means the same thing later.
Every saved experiment should identify:
- workbench version;
- operation versions;
- protocol profile;
- algorithm and parameters;
- source input or its digest;
- expected intermediate values;
- assertions and expected results.
Operations that parse complex formats should link to the specification edition they implement. If behaviour changes, the old version should remain reproducible or the tool should report the difference explicitly.
This is especially important for emerging standards. A test artifact created against one draft should not silently run under the semantics of a later revision.
A possible architecture
The workbench could remain small at its core.
Typed operation engine
Each operation declares accepted and produced types, parameters, side effects and sensitivity. Bytes, text, integers, keys, structured protocol objects and diagnostic traces remain distinct.
Visual composition
Users connect operations into a graph or arrange them as a linear recipe. The same underlying model supports both views.
Protocol profiles
A profile packages schemas, construction rules, strict validation, example vectors and references for a defined protocol edition.
Execution trace
Every node can expose input, output, timing, encoding and assertions. Sensitive values follow redaction rules.
Portable artifact
An experiment exports as a versioned, text-based file suitable for review and source control. A read-only browser view can render it without executing unsafe extensions.
Extension boundary
New operations run through a documented interface and test suite. The core should prefer well-reviewed libraries to new cryptographic implementations.
The design goal is not to replace command-line tools or production libraries. It is to connect them through an inspectable model.
Start with one narrow experiment
The idea should be tested with a limited vertical slice rather than a catalogue of hundreds of operations.
A first experiment could compare signature constructions over structured data:
- accept raw JSON and CBOR bytes;
- show the decoded data model without discarding the originals;
- construct JWS and COSE signing inputs;
- display every intermediate byte string;
- sign or verify with test keys;
- mutate one field or encoding choice;
- show the first divergence;
- export the experiment with expected values.
This slice would exercise the central principles: explicit types, byte visibility, protocol-aware construction, assertions and reproducibility. It would also connect naturally to the practical problem of implementations that agree on meaning but disagree on signed bytes.
Later profiles could address key derivation, certificate paths, ISO 18013-5 session structures, smart-card secure messaging or post-quantum size experiments.
An instrument for questions
CrypTool 2 shows the value of visible composition. CyberChef shows the value of immediate, reusable transformations. CrypTool-Online shows the value of focused experiments that open directly in a browser.
An applied cryptographic workbench could bring those lessons to protocol construction. Its distinctive contribution would not be a longer algorithm menu. It would be the ability to inspect the exact statement a system protects, reproduce how it was constructed and test how it fails when one assumption changes.
The most useful cryptographic tool is not the one that makes the primitive disappear. It is the one that helps us see precisely what the primitive was asked to do.
