ciphernomad-org

You are correct, it is not the same project. That's a name collision with a 2002 paper.

To your original question on the benefits over a standard AEAD:

For stateless encryption, our `ariadne-etm` crate offers no major advantage. The core protocol, however, is a programmable, stateful cryptographic engine. This enables new protocol designs.

For example:

1. Smarter Transport Layers. The Labyrinth can be a public parameter derived from a server's key. This allows building in features like proof-of-work for DoS resistance or cryptographic watermarks for traitor-tracing directly into the transport layer.

2. Verifiable Stateful Computation. The architecture allows proving that a secret, stateful program was honestly executed over a verifiable duration. The program's execution path leaves an irreversible "scar" on a one-time-use Labyrinth, creating a commitment to the entire computational history.

The point isn't to replace AES. It's a new foundation for different kinds of cryptographic systems.

1. Formal Spec: You're right. A formal specification is the top priority. We released the code first as a concrete artifact to invite this exact kind of direct scrutiny.

0. Process: Our focus is on the technical merits of the work itself.

2. Encryption Speed: The process is computationally symmetric. Encryption is not slower than decryption. For each block, both operations perform one permutation and the navigation/state-update hashes.

3. Collisions & Key Reuse: This is the crucial distinction. A geometric path collision (e.g., L-R-L) is common and harmless. A catastrophic round key collision is what we prevent. The key for each round is derived from (master_key, state, node_nonce). Since the state is a cryptographic ratchet of the entire history and the node_nonce is unique to the position in the Labyrinth, a key-reusing state collision is cryptographically negligible.

This is a classic Feistel network round: L_new = L_old ^ F(key, R_old). It's a deliberate design.

The security of the Labyrinth relies on the composition of many rounds, not any single one. The unchanged right half from a Hash round is fully encrypted if the next round is a Stream round. Since the Labyrinth is a deep, aperiodic mix of both round types, the entire block is guaranteed to be diffused and encrypted.

The security does not depend on the path's structure. It depends on the CVM's state ratchet.

The key and IV for every single round are derived from a keyed hash of the CVM's current state. This state is a cryptographic digest of the entire operational history up to that point.

So, even if a path structurally resembled a weak cipher like 2DES, the rounds would not have related keys. Each step is effectively a fresh cipher instance with a unique, unpredictable key. A meet-in-the-middle attack is not possible because there is no "middle" with a key relationship to exploit.

You are correct from a formal perspective. Any finite state machine is periodic.

In cryptography, "aperiodic" means the period is computationally unreachable. We use a 256-bit state, making the probability of a collision negligible (on the order of 2^256). This is a parameter of the CVM; it could be increased to 512 bits or more if required.

This is the standard security model for all modern hash-based constructions.

Let's clarify.

1. CVM State: It's an internal 32-byte register, not pre-shared. For each operation, it's initialized from a unique nonce (e.g., enc_nonce). This nonce is transmitted publicly with the ciphertext as part of a structured payload. The CVM's subsequent state evolution is secret, as it depends on the master key and operational history. It's an input to the round key derivation, not the round key itself.

2. Path Determination: The path is determined by the ciphertext chunk. During decryption, the ciphertext is used with the key and current state to find the path before it's decrypted.

3. Path Collision: This is critical because it implies a state collision. Since round keys are derived from the state, a state collision at the same Labyrinth node would cause catastrophic key reuse. The state ratchet is designed to make this negligible.

The core difference is what is being ratcheted.

Signal's Double Ratchet evolves the keys for a static algorithm like AES.

In Ariadne, the ratchet evolves the algorithm itself. The path through the Labyrinth, the sequence of cryptographic permutations, is a function of the CVM's state. The state ratchets, so the algorithm ratchets.

Signal gives you a new key for the same lock. We use a new key to build a new lock for every message, and the shape of that lock depends on the history of every one opened before it. This architectural difference is what allows the CVM to be reconfigured for other tasks like VDFs or cooperative proofs-of-work, where the "program" itself must be dynamic.

A formal spec is the next priority. We released the implementation first as the protocol is novel and we invite direct scrutiny of the work.

The path selection is secret, not public. It is determined by `hash(key, state, chunk)`. An attacker lacks the secret `key` and internal CVM `state` and cannot compute the path.

The key expansion and path collision mechanisms are as follows: 1. A round's key is derived from the master key, the CVM's state, and the unique nonce of the Labyrinth node being processed. 2. The CVM state ratchets forward after every block, making path collision negligible.

That's the key distinction. This isn't just a complex function, but a programmable machine that enables new capabilities.

For example: verifiable, time-locked proof of computation on a secret program. A standard hash or ZK-SNARK can't prove the when or how long of a simulation. Our model can.

The execution of the secret program leaves an irreversible "scar" on a one-time-use Labyrinth. The final state of this scarred structure is a commitment to the entire computational history, which is then time-locked by a Verifiable Delay Function (VDF).

The proof isn't just an output; it's the final, mutated state of the Labyrinth itself. An adversary can't find a more concise model because the history of the computation is inseparable from the proof.

You are correct. The probability of a state collision is cryptographically negligible, on the order of breaking a 256-bit hash function.

You're also right that AES-GCM is faster and has hardware support. Ariadne explores a different trade-off. Its primary advantage is its architectural agility.

Instead of a fixed algorithm, the sequence of operations in Ariadne is dynamic and secret, derived from the key and data history. An attacker doesn't just need to break a key; they have to contend with an unknown, ephemeral algorithm.

This same flexible structure allows the core CVM to be reconfigured into other primitives. We've built concepts for programmable proofs-of-work, verifiable delay functions, and even ring signatures.

Yes. The core architecture is crypto-agile. Its foundation is quantum-resistant because it's built on symmetric primitives like hashing and stream ciphers.

We used X25519 and Ed25519 in the transport layer examples for clarity, as they are well-understood, not as a production baseline.

A post-quantum implementation would swap these out. The key exchange would use a hybrid model, combining X25519 with a PQC KEM like CRYSTALS-Kyber. The signature would be replaced with a PQC scheme like CRYSTALS-Dilithium.

This modularity is a fundamental part of the design.