The Mix protocol, as currently specified, deviates from the original Sphinx paper in a way which completely breaks message integrity.
Message integrity in this context is tricky, because to allow replies in Mix, you have to separate the Sphinx header from the message payload (as one needs to be able construct headers without knowing the payload).
Because of this, the way message integrity works in (the original version of) Sphinx, is to prepend kappa = 128 zero bits to the payload, and then use a pseudo-random permutation (PRP) to encrypt the payload. Note that a completely different encryption (XOR-ing with the output of a pseudo-random stream generator) is used for encrypting the routing information in the header - neither of these can play the role of the other in Sphinx.
The property of a PRP that we use here, is that if even a single bit of the input is flipped, the output is totally scrambled (for example, on average half of the bits of the output will flipped). This means that if the encrypted payload is tampered with, then after the final decryption step, you have a negligible 2^-128 chance to have those zero bits intact.
However, the spec uses AES-CTR to encrypt the payload, where this is absolutely not true - in fact, a malicious node can flip ANY selected bits of the payload (except these test bits) at will.
Possible solutions:
- ignore message integrity - not a good idea
- use the Lioness PRP as recommended by the paper to encrypt the payload
- look at potential alternatives using more modern cryptography
As Lioness is pretty simple, that could be an easy immediate solution.
The Mix protocol, as currently specified, deviates from the original Sphinx paper in a way which completely breaks message integrity.
Message integrity in this context is tricky, because to allow replies in Mix, you have to separate the Sphinx header from the message payload (as one needs to be able construct headers without knowing the payload).
Because of this, the way message integrity works in (the original version of) Sphinx, is to prepend
kappa = 128zero bits to the payload, and then use a pseudo-random permutation (PRP) to encrypt the payload. Note that a completely different encryption (XOR-ing with the output of a pseudo-random stream generator) is used for encrypting the routing information in the header - neither of these can play the role of the other in Sphinx.The property of a PRP that we use here, is that if even a single bit of the input is flipped, the output is totally scrambled (for example, on average half of the bits of the output will flipped). This means that if the encrypted payload is tampered with, then after the final decryption step, you have a negligible
2^-128chance to have those zero bits intact.However, the spec uses AES-CTR to encrypt the payload, where this is absolutely not true - in fact, a malicious node can flip ANY selected bits of the payload (except these test bits) at will.
Possible solutions:
As Lioness is pretty simple, that could be an easy immediate solution.