Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Ariadne – A Rust implementation of aperiodic cryptography

codeberg.org

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#21

Post by ciphernomad-org »

ur-whale wrote: post #16

The claim "This makes the cipher aperiodic" should be justified. As an immediate counter, I would say that if your code runs on a physically finite machine (an however large, yet finite number of bits to store state), this strikes me as very unlikely to be theoretically true.

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.

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#22

Post by CharlieTrip »

ciphernomad-org wrote: post #20
CharlieTrip wrote: post #17

Earlier quoted context omitted.

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 r…

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.…

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.

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#23

Post by ciphernomad-org »

willvarfar wrote: post #19

Could some of the paths result in insecure ciphers and those moments of insecurity lead to a broader compromise? E.g. the program goes through a state that is effectively 2DES which enables a meet-in-the-middle attack which allows an attacker to jump into the path at that point and dramatically reduce the search space for the next or preceding block etc?

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.

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#24

Post by conradludgate »

Hi, interesting project. Looking into the code, it seems that when the random round is Hash, you're not encrypting half of the chunk:

https://codeberg.org/CipherNomad/Ariadne/src/branch/main/cra...

You split the chunk in half, use right to derive the cipher material and then only apply it to left. This leaves right unchanged.

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#25

Post by ciphernomad-org »

conradludgate wrote: post #24

Hi, interesting project. Looking into the code, it seems that when the random round is Hash, you're not encrypting half of the chunk: https://codeberg.org/CipherNomad/Ariadne/src/branch/main/cra... You split the chunk in half, use right to derive the cipher material and then only apply it to left. This leaves right unchanged.

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.

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#26

Post by ciphernomad-org »

CharlieTrip wrote: post #22
ciphernomad-org wrote: post #20

Earlier quoted context omitted.

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.…

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 inev…

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.

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#27

Post by Medea »

I am having trouble understanding the main purpose of this protocol. After looking at your code example, I want to ask: what is the benefit of using this instead of an AEAD (Authenticated Encryption with Associated Data) that is already available in Rust? What specific security guarantee does this give me that would help when I am building protocols?

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#28

Post by bilekas »

Medea wrote: post #27

I am having trouble understanding the main purpose of this protocol. After looking at your code example, I want to ask: what is the benefit of using this instead of an AEAD (Authenticated Encryption with Associated Data) that is already available in Rust? What specific security guarantee does this give me that would help when I am building protocols?

It's just a privacy-preserving network layer communication protocol, think onion router. Removing the dependency on third party verification.

Some further reading : https://netsec.ethz.ch/publications/papers/ariadne.pdf

it's generally seen as more secure and in cases more efficient.

> Ariadne enhances previous approaches to preserve communication privacy by introducing two novelties. First, the source route is encoded in a fixed size, sequentially encrypted vector of routing information elements, in which the elements' positions in the vector are pseudo-randomly permuted. Second, the temporary keys used to process the packets on the path are referenced using mutually known encrypted patterns. This avoids the use of an explicit key reference that could be used to de-anonymize the communications.

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#29

Post by Medea »

bilekas wrote: post #28
Medea wrote: post #27

I am having trouble understanding the main purpose of this protocol. After looking at your code example, I want to ask: what is the benefit of using this instead of an AEAD (Authenticated Encryption with Associated Data) that is already available in Rust? What specific security guarantee does this give me that would help when I am building protocols?

It's just a privacy-preserving network layer communication protocol, think onion router. Removing the dependency on third party verification. Some further reading : https://netsec.ethz.ch/publications/papers/ariadne.pdf it's generally seen as more secure and in cases more efficient. > Ariadne enhances previous approaches to preserve communication privacy by introducing two novelties. First, the source route is encode…

Are you sure it is the same Ariadne? The paper you linked is from 2002 and does not mention aperiodic or "Cryptographic Virtual Machine"

Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography

#30

Post by bilekas »

Medea wrote: post #29
bilekas wrote: post #28

Earlier quoted context omitted.

It's just a privacy-preserving network layer communication protocol, think onion router. Removing the dependency on third party verification. Some further reading : https://netsec.ethz.ch/publications/papers/ariadne.pdf it's generally seen as more secure and in cases more efficient. > Ariadne enhances previous approaches to preserve communication privacy by introducing two novelties. First, the source route is encode…

Are you sure it is the same Ariadne? The paper you linked is from 2002 and does not mention aperiodic or "Cryptographic Virtual Machine"

It's related only to the protocol.

> Ariadne is efficient, using only highly efficient symmetric cryptographic primitives.

Your implementation is up to you really. As I see the OP's link, this is just an aperiodic implementation of the Ariadne protocol in Rust ?

Post reply on HN