Show HN: Ariadne – A Rust implementation of aperiodic cryptography

Hi, cryptography researcher here!

I'm sorry, but not having a mathematical formulation makes it extremely tedious to look into the protocol and get a feeling if it is secure or not (or if what you are doing makes even sense). If you plan to do some additional work, focus on clearly defining what you are doing for a (maths-)cryptography audience. This would definitely help!

But, I can try and give you my 2-cents after skimming the code: as far as I understand, the primitive is intrinsically sequential and encrypts chunk by chunk. Depending on the "type", you either use a stream-cipher or some OTP-like (with pad related to the hash of part of the message). You have a public way to decide (from the current chunk ciphertext?) which encryption method you use for the next chunk. Am I getting it correctly?

If this is the case, I have to admit that the OTP-like part looks weird and definitely would be the first place where to look into. Especially how the secret key is effectively expanded for the different "rounds", and if there might be some weird property for when the encryption scheme selects twice the same path.

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.

Despite it might sound weird, the format spec is exactly what is needed to scrutiny any cryptographic primitive. It should be the first output during the design of a security-oriented primitive/protocol. See it in this way, if you soon publish the specs and there is a massive cheese-hole, your implementation is kaput! And since security products (sometimes sadly) live in reputation-system, your product lost all the reputation regardless if it will be secure or not.

So, the path is determined step by step taking into account the initial chunk or the output chunk? I'm confused on what this "CVM state" is. Your primitive has a secret key and that it, right? Or is this state yet another secret that must be shared to use the primitive? Again, without a formal specification, it is tricky for me to understand what that "chunk" effectively is and why should allow a decryption. If chunk is the "input chunk", how can you reconstruct the same path if you do not have the input?

Wait, the "CVM state" is the "round" key? Why do you care about "path collision"? This "property" does not make any sense without some appropriate context.

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.

1. Sorry, without a formal specification what I see are too many "pieces" with non-standard names that play too many roles.

0. You know that all your replies, code and webpage look extremely like AI outputs? If this is the case, it would be way better if you are open about using such tools.

2. Meaning that encryption is way slower than decryption.

3. You are making this concept quite confusing. Path collision is inevitable because you only have two options to choose from, making it easy to get collisions. Round-key collisions are something different and merely depends on how you effectively derive such keys. I might be wrong because I would need time to think about, but I believe that to get a "catastrophic key reuse" you would have to get the same state, the same inputs for the round key derivation function, the same ciphertext to be used and, most probably, some additional information a-la chosen-plaintext to effectively get something out that would break that specific chunk. Since you claim you have some ratcheting mechanism, push the attack to other rounds might not even be possible. If not, then you might not really achieve forward secrecy.

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.