rich1.0npub1ly5vrg5ylhdkxrkj824jhlnfsy2z8fvlg8wcc0jqc4aezma6majsycdx6nhttps://nostr.ae/npub1ly5vrg5ylhdkxrkj824jhlnfsy2z8fvlg8wcc0jqc4aezma6majsycdx6nnjumphttps://nostr.ae📅 Original date posted:2018-12-04 📝 Original message: Thanks Christian, that makes sense. Unfortunately it's not very clear from the BOLT, at least not for me. Now that I think of this type of attack: *in general* the HMAC prevents this kind of attack, but isn't the attack still possible in certain specific cases? For instance, the attacking intermediate node might guess that the next node in the route is the final node; it can test this by completely replacing the onion packet it sends to the next node with a self-written onion packet that has the next hop as final node, with the same amount and payment hash as instructed by the incoming payment. If that succeeds, it has learned that the next node is indeed the final node (and nobody gets to know about the attack); if that fails, it might retry the payment with the original onion packet. In that case, it learned that the next node is *not* the final node. In this case, the attack is detectable by the next node though: it first receives an incoming payment with a payment hash it doesn't recognize, and then it receives a payment forwarding request with the same payment hash. Given that the attacker has good knowledge of the shape of the Lightning network, this type of attack can be generalized to test whether a certain second-degree neighbor, third-degree neighbor etc. is the final node; it scales pretty badly with increasing network distance though. An additional advantage for the attacker is that this gives plausible deniability: if the attack becomes visible, the attacker can always claim it wasn't him, but some node upstream in the route. A practical difficulty for the attacker might be that the exact amount forwarded in further-away hops is unknown, but it's probably not that difficult to guess. I think we could stop this type of attack by including some kind of shared secret in the onion message to the final node: * Payee generates shared secret and passes this to payer, as part of the invoice * Payer includes shared secret in the per hop data to payee * On receiving the incoming message, payee checks whether the received shared secret corresponds to the generated one. If this is not the case, behave in exactly the same way as when the payment hash is unrecognized (including timing, to prevent timing side-channel attacks). If this shared secret is encrypted like the rest of the per hop data, the attacker can't learn the shared secret, and can't include it in his own replacement onion. He can't copy-paste the encrypted shared secret from the original onion either, since he has to use his own, different ephemeral key in his own onion. With this protocol in place, a final node can no longer be distinguished from a non-final node with this attack. The shared secret doesn't need to be very large: the number of attempts per second (to guess the shared secret) is limited by network latency, bandwidth and maybe some artificial rate limiting. If an attacker can do 100 attempts per second, then a 32-bit shared secret will take (on average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of which node is the final node. In the mean time, people will have noticed the ongoing attack and will have taken countermeasures. Besides, the transaction lock time will likely have expired in the mean time as well. CJP On 29-11-18 18:13, Christian Decker wrote: > Hi Corne, > > the HMACs are necessary in order to make sure that a hop cannot modify > the packet before forwarding, and the next node not detecting that > modification. > > One potential attack that could facilitate is that an attacker could > learn the path length by messing with different per-hop payloads: set > n=0 the attacker flips bits in the nth per-hop payload, and forwards > it. If the next node doesn't return an error it was the final recipient, > if if returns an error, increment n and flip bits in the (n+1)th per-hop > payload, until no error is returned. Congratulation you just learned the > path length after you. The same can probably be done with the error > packet, meaning you can learn the exact position in the route. Add to > that the information you already know about the network (cltv_deltas, > amounts, fees, ...) and you can probably detect sender and recipient. > > Adding HMACs solves this by ensuring that the next hop will return an > error if anything was changed, i.e., removing the leak about which node > would have failed the route. > > Cheers, > Christian