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