[Feature Request] Add optional jitter to forwarded HTLCs

[ajpwahqgbi]

The precise timing of HTLC forwards can enable an on-path adversary to determine with some accuracy the full payment path. One possible mitigation is to add jitter to each forwarded HTLC, like this C-Lightning plugin.

Serious thought needs to be put into this feature to actually withstand serious statistical analysis. Of course it should be optional, and off by default.

[carlaKC]

Serious thought needs to be put into this feature to actually withstand serious statistical analysis.

Definitely. From what I understand of the timing delays utilized on the base layer, they're ineffective against a large-scale attacker (ie a chainanalysis type), so we wouldn't want to add something like this to lnd if we're not certain that it will have the desired privacy gain. Would you be willing to spend some time looking into the kind of jitter that would be effective?

The feasibility of timing attacks relies on the possibility to build a reliable model of latencies, and on the adversary’s capability of observing and correlating of suitable interactive multi-hop message exchanges, such as the current update_add_htlc, update_fail_htlc, and update_fulfill_htlc message payloads.

The above is from the paper, which I admit to only skimming, I wonder how it will hold up once AMP is deployed and HTLCs that are split into multiple parts have distinct payment hashes?

[ajpwahqgbi]

Would you be willing to spend some time looking into the kind of jitter that would be effective?

Yes, but I can't commit to any specific time line. I'll look into this more deeply "eventually".

I wonder how it will hold up once AMP is deployed[?]

It's a good question, but I think the real problem is not this specific attack but that HTLC message timing leaks information about the payment path.

In fact the scope of this issue should really go beyond merely adding jitter. Adding noise is only one possible mitigation. It's probably worthwhile to look at the techniques cryptographers use to prevent leakage of secret data through timing and power side-channels. I suspect at least some of those techniques are directly applicable to this problem, too.

[saubyk]

Closing this as not planned. Adding random delay to forwarded payments slows every payment through the node and keeps funds locked for longer, and it has not been shown to give a reliable privacy gain. The protocol discussion has since moved towards adding delay at the receiving node instead (lightning/bolts#1263), and the new attribution data feature lets senders see how long each node held a payment and favour faster nodes. A node operator who still wants forwarding jitter can add it today with an external program using the HtlcInterceptor RPC, which can hold each forwarded payment and release it after a delay of its choosing.