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