📅 Original date posted:2015-09-18
📝 Original message:
Hi all!
So, we've handwaved that we're going to have onion routing, so
each node can only see the immediate neighbors.
Here's my first attempt; please fix :)
The format of a route looks like so:
required bytes route;
A node decrypts that using its pubkey (probably some counter mode
scheme, but that's for a different post!), expecting:
// Sum of this whole thing after decryption.
required sha256_hash sum = 1;
// Where to next?
oneof next {
// Actually, this is the last one
bool end = 2;
// Next lightning node.
pubkey lightning = 3;
// Other realms go here...
}
// How much fee you can take (== all, if last node)
required int32 fee = 4;
// Remainder (route blob for next node).
required bytes route = 5;
If the sum is wrong, the routing has failed (it's been corrupted or was
malformed to start).
Nodes create the route backwards, to calculate the size. Then picks a
total size randomly between 1024 and 4096, and pads to that size (at
least 32 bytes of random padding). Then walks backwards to wrap and
encrypt it.
This offers some protection from guessing the route length.
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. :(
Error Messages
==============
Another issue is that we should try not to leak information to passive
observers on the route due to errors, so signing errors and using the
'sum' field as a secret key seems sensible. This means your padding in
the original message needs to be "random" so 'sum' is random.
Thoughts welcome!
Rusty.
PS. As noted before, nodes can trivially correlate HTLCs by R value, so
onioning the routing only gets you so far...
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:44:25
in reply to nevent1q…4t6e
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:44:25Event JSON
{
"id": "fbfb5cbec0119d6b49da3d8a4c960c5e5ded2caed817cba9cf8df07282ab19db",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314665,
"kind": 1,
"tags": [
[
"e",
"36906e9db439c1be0c33c07064c5914ca50c01ffdfa370a0d6a3e54356187808",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2015-09-18\n📝 Original message:\nHi all!\n\n So, we've handwaved that we're going to have onion routing, so\neach node can only see the immediate neighbors.\n\nHere's my first attempt; please fix :)\n\nThe format of a route looks like so:\n\n required bytes route;\n\nA node decrypts that using its pubkey (probably some counter mode\nscheme, but that's for a different post!), expecting:\n\n // Sum of this whole thing after decryption.\n required sha256_hash sum = 1;\n\n // Where to next?\n oneof next {\n // Actually, this is the last one\n bool end = 2;\n // Next lightning node.\n pubkey lightning = 3;\n // Other realms go here...\n }\n \n // How much fee you can take (== all, if last node)\n required int32 fee = 4;\n\n // Remainder (route blob for next node).\n required bytes route = 5;\n\nIf the sum is wrong, the routing has failed (it's been corrupted or was\nmalformed to start).\n\nNodes create the route backwards, to calculate the size. Then picks a\ntotal size randomly between 1024 and 4096, and pads to that size (at\nleast 32 bytes of random padding). Then walks backwards to wrap and\nencrypt it.\n\nThis offers some protection from guessing the route length.\n\nRoute Probing Attacks\n=====================\nNow, there's a weakness here: No MAC! A nosy node can't corrupt the\nrouting past the next hop, but it could replace it entirely (this is\nfundamental to the scheme of R values). If it guesses the final\ndestination right, the HTLC will succeed, otherwise it will fail, so it\ncan use this to probe.\n\nOne partial defence is to fail to allow two HTLCs with the same R value,\nforcing probe serialization. Unfortunately that allows a simple way to\nprobe back to the source, so we shouldn't do this!\n\nWe may be able to do some probabalistic backoff of duplicate R values,\nsuch that you can't tell if I've received one before? A more\nsophisticated probe sequence could get a probability though...\n\nI can't see a fix for this in general. :(\n\nError Messages\n==============\nAnother issue is that we should try not to leak information to passive\nobservers on the route due to errors, so signing errors and using the\n'sum' field as a secret key seems sensible. This means your padding in\nthe original message needs to be \"random\" so 'sum' is random.\n\nThoughts welcome!\nRusty.\nPS. As noted before, nodes can trivially correlate HTLCs by R value, so\n onioning the routing only gets you so far...",
"sig": "e908cbb92cb71e0c45baafc0519584460de5c66c97feb7f3a3010982b0a70890ce136a60319dd5a20460fb85bcc314be39f9b1027264dbae7d24c254f83c3d85"
}