Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-20 📝 Original message: Anthony Towns <aj at ...
📅 Original date posted:2015-09-20
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>Route Probing Attacks
>>=====================
>>Now, there's a weakness here: No MAC! A nosy node can't corrupt the
>>routing past the next hop, but it could replace it entirely (this is
>>fundamental to the scheme of R values). If it guesses the final
>>destination right, the HTLC will succeed, otherwise it will fail, so it
>>can use this to probe.
...
>>I can't see a fix for this in general. :(
>
> I don't think parallel probes work well - if any of your probes succeed, your neighbour knows R and can claim all of your probes. Parallelization is also limited by channel capacity, assuming the payee knows how much to expect.
Channel capacity might not be an issue for tiny micropayments, but
the reveal of R is a good point: such probing should have a real cost
on success. I'll be sure to implement that properly :)
> I'm not sure probing is really plausible given mass deployment, is it? You have to guess the eventual recipient but given randomised routing you have every person or business using lightning as a potential candidate with possibly equal probability?
If someone wants to know whether I'm sending money to you, it would
work. Get a cheap hub near you, and one near me, and probe every
payment which passes through both.
But I guess it's a fairly boutique surveillance, which doesn't scale.
> For a general solution, I think you could completely rule out probing by having two R values, one known only by the recipient, and one by the sender (call it S say). Then make the htlcs payable on presentation of both R and S and include S encrypted to the final recipient in the onion payload. Munging the payload then makes the htlc irredeemable so misrouting it gives no information.
That's clever. And I think it works. I will need more coffee to figure
out if we should revise the transaction structure to include this.
> (Please let me know if the formatting of this mail is too hopeless; trying out a new setup)
No work wrap, but it seemed to work fine.
Cheers,
Rusty.
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>Route Probing Attacks
>>=====================
>>Now, there's a weakness here: No MAC! A nosy node can't corrupt the
>>routing past the next hop, but it could replace it entirely (this is
>>fundamental to the scheme of R values). If it guesses the final
>>destination right, the HTLC will succeed, otherwise it will fail, so it
>>can use this to probe.
...
>>I can't see a fix for this in general. :(
>
> I don't think parallel probes work well - if any of your probes succeed, your neighbour knows R and can claim all of your probes. Parallelization is also limited by channel capacity, assuming the payee knows how much to expect.
Channel capacity might not be an issue for tiny micropayments, but
the reveal of R is a good point: such probing should have a real cost
on success. I'll be sure to implement that properly :)
> I'm not sure probing is really plausible given mass deployment, is it? You have to guess the eventual recipient but given randomised routing you have every person or business using lightning as a potential candidate with possibly equal probability?
If someone wants to know whether I'm sending money to you, it would
work. Get a cheap hub near you, and one near me, and probe every
payment which passes through both.
But I guess it's a fairly boutique surveillance, which doesn't scale.
> For a general solution, I think you could completely rule out probing by having two R values, one known only by the recipient, and one by the sender (call it S say). Then make the htlcs payable on presentation of both R and S and include S encrypted to the final recipient in the onion payload. Munging the payload then makes the htlc irredeemable so misrouting it gives no information.
That's clever. And I think it works. I will need more coffee to figure
out if we should revise the transaction structure to include this.
> (Please let me know if the formatting of this mail is too hopeless; trying out a new setup)
No work wrap, but it seemed to work fine.
Cheers,
Rusty.