Hey CJP, I am still not 100% through the SPHINX paper so it would be great if at least another pair of eyes could lookt at this. However from the original SPHINX paper I quote:
"Besides extracting the shared key, each mix has to be provided with authentic and confidential routing information to direct the message to the subsequent mix, or to its final destination. We achieve this by a simple encrypt-then-MAC mechanism. A secure stream cipher or AES in counter mode is used for encryption, and a secure MAC (with some strong but standard properties) is used to ensure no part of the message header containing routing information has been modified. Some padding has to be added at each mix stage, in order to keep the length of the message invariant at each hop." At first I thought this would mean that the HMAC ensures that the previous hop cannot change the routing information. which was the first answer that I wanted to give. However I am confused now too. The HMAC commits to the next onion. So if the entire onion was exchanged and a new HMAC was provided (as you suggest) the processing hop would not know this. Such a use case would obviously lead to a routing scenario which would not succeed and would hardly be useful (unless the previous hop plans a reverse dos attacks from error messages or some other sabotage attacks which are references in the SPHINX paper but not discussed explicitly). On a second thought I reviewed chapter 2.1 of the Sphinx paper in which the thread model for attackers is described. As far as I understand that section one attack vector for which the HMAC shall help are man in the middle attacks. If HMACs are being used some bitflipping by man in the middles would be detected. However I think if a man in the middle speaks the BOLT protocol they could exchange the entire package and provide a new HMAC as a previous hop could do. Also the Thread model does only speak about security of the message not so much about the reliability of the protocol. I believe it is quite clear that if a routing node wants to manipulate the onion they can do so. In the same way how they can decide not to forward the onion. --> So the mix network itself can make sure that no wrong messages are delivered it cannot make sure that messages (which are unseen and unknown from where they came) are intercepted. Besides the Bitflipping usecase that I mentioned I agree with your criticism and also don't see the necessity of the HMAC anymore. The message is encrypted anyway and if bits are flipped the decrypted version will just be badly formated. If the header was manipulated the next hop would not be able to decrypt. Best regards Rene Am Do., 29. Nov. 2018, 16:31 hat Corné Plooy via Lightning-dev < lightning-dev@lists.linuxfoundation.org> geschrieben: > Hi, > > > Is there a reason why we have HMACs in Sphinx? What could go wrong if we > didn't? > > A receiving node doesn't know anyway what the origin node is; I don't > see any attack mode where an attacker wouldn't be able to generate a > valid HMAC. > > A receiving node only knows which peer sent it a Sphinx packet; > verification that this peer really sent this Sphinx packet is (I think) > already done on a lower protocol layer. > > > AFAICS, The only real use case of the HMAC value is the special case of > a 0-valued HMAC, indicating the end of the route. But that's just silly: > it's essentially a boolean, not any kind of cryptographic verification. > > > CJP > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
