📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:44:25
in reply to nevent1q…8j9a
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:44:25Event JSON
{
"id": "667c6b8bd5e134ac287da8dbd2f8adff2baa882449d49ed0914b32c539b53a75",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314665,
"kind": 1,
"tags": [
[
"e",
"36906e9db439c1be0c33c07064c5914ca50c01ffdfa370a0d6a3e54356187808",
"",
"root"
],
[
"e",
"c62f5988058ebfdc9862a1cf7ade576e3005a3c2616d3b4b482dbf890863f85f",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-09-20\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e On 19 September 2015 9:39:44 am AEST, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\u003eRoute Probing Attacks\n\u003e\u003e=====================\n\u003e\u003eNow, there's a weakness here: No MAC! A nosy node can't corrupt the\n\u003e\u003erouting past the next hop, but it could replace it entirely (this is\n\u003e\u003efundamental to the scheme of R values). If it guesses the final\n\u003e\u003edestination right, the HTLC will succeed, otherwise it will fail, so it\n\u003e\u003ecan use this to probe.\n...\n\u003e\u003eI can't see a fix for this in general. :(\n\u003e\n\u003e 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.\n\nChannel capacity might not be an issue for tiny micropayments, but\nthe reveal of R is a good point: such probing should have a real cost\non success. I'll be sure to implement that properly :)\n\n\u003e 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?\n\nIf someone wants to know whether I'm sending money to you, it would\nwork. Get a cheap hub near you, and one near me, and probe every\npayment which passes through both.\n\nBut I guess it's a fairly boutique surveillance, which doesn't scale.\n\n\u003e 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.\n\nThat's clever. And I think it works. I will need more coffee to figure\nout if we should revise the transaction structure to include this.\n\n\u003e (Please let me know if the formatting of this mail is too hopeless; trying out a new setup)\n\nNo work wrap, but it seemed to work fine.\n\nCheers,\nRusty.",
"sig": "77d6a401bfc2cdba216ab51eef24dca668f6eaab77cf5636666a3a9e4647d21b4bb38d07c8fd0fa50a9e682343cf5ef1c4ea6b27e0d32f754b1ace13c716bdeb"
}