From rusty at rustcorp.com.au Sun Sep 20 20:48:37 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 21 Sep 2015 06:18:37 +0930 Subject: [Lightning-dev] Onion routing design. In-Reply-To: <8EBFB3FC-300A-4911-B44B-5362B17A5FAD@erisian.com.au> References: <8737ybi9fj.fsf@rustcorp.com.au> <8EBFB3FC-300A-4911-B44B-5362B17A5FAD@erisian.com.au> Message-ID: <87twqohl5m.fsf@rustcorp.com.au> Anthony Towns writes: > On 19 September 2015 9:39:44 am AEST, Rusty Russell 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.