[Lightning-dev] Onion routing design.

[Anthony Towns]

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.
>
>One partial defence is to fail to allow two HTLCs with the same R
>value,
>forcing probe serialization.  Unfortunately that allows a simple way to
>probe back to the source, so we shouldn't do this!
>
>We may be able to do some probabalistic backoff of duplicate R values,
>such that you can't tell if I've received one before?  A more
>sophisticated probe sequence could get a probability though...
>
>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.

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?

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.

(Please let me know if the formatting of this mail is too hopeless; trying out a new setup)

Cheers,
aj



-- 
Sent from my phone.