Any algorithm can be recast as being "self-modifying", "aperiodic" etc. We don't gain any security by doing so. It's just a choice of how to model what the algorithm does which makes it harder to analyse. Sure, it makes it harder for an adversary to analyse too, but only if they stick to the author's way of modeling what the algorithm does - as opposed to finding a more concise description of what it does.
Show HN: Ariadne – A Rust implementation of aperiodic cryptography
11–20 of 33 posts
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#12Hi, 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.
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#13Any algorithm can be recast as being "self-modifying", "aperiodic" etc. We don't gain any security by doing so. It's just a choice of how to model what the algorithm does which makes it harder to analyse. Sure, it makes it harder for an adversary to analyse too, but only if they stick to the author's way of modeling what the algorithm does - as opposed to finding a more concise description of what it does.
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.
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#14Hi, 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…
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.
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#15How does this differ from the KDF chain in Signal?
Looking at it naively - deriving a new key sounds similar to picking a new function within a family of possible functions?
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#16The 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.
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#17Hi, 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…
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…
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.
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#18How does this differ from the KDF chain in Signal? Looking at it naively - deriving a new key sounds similar to picking a new function within a family of possible functions?
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.
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#19Could 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?
Re: Show HN: Ariadne – A Rust implementation of aperiodic cryptography
#20Earlier quoted context omitted.
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…
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. 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.