Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-04 📝 Original message: Corné Plooy via ...

📅 Original date posted:2018-12-04
📝 Original message:
Corné Plooy via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> writes:
> 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)

This is always true, regardless of construction, with our current
scheme.

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

True. Note that we go as far as preventing forwarding of the same onion
(for traffic analysis), but we don't block this more obvious attack.

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

This would indeed be an incremental improvement: I generally prefer not
to rely on the privacy of the invoice delivery, but this certainly makes
it no worse.

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

We could really just use the last 4 bytes of the signature, AFAICT.

Cheers,
Rusty.