<p dir="ltr">Could you please point me to any notes about requirements/desiderata?</p>
<p dir="ltr">Thanks!</p>
<p dir="ltr">--Zooko</p>
<div class="gmail_quote">On Sep 18, 2015 5:47 PM, "Rusty Russell" <<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all!<br>
<br>
So, we've handwaved that we're going to have onion routing, so<br>
each node can only see the immediate neighbors.<br>
<br>
Here's my first attempt; please fix :)<br>
<br>
The format of a route looks like so:<br>
<br>
required bytes route;<br>
<br>
A node decrypts that using its pubkey (probably some counter mode<br>
scheme, but that's for a different post!), expecting:<br>
<br>
// Sum of this whole thing after decryption.<br>
required sha256_hash sum = 1;<br>
<br>
// Where to next?<br>
oneof next {<br>
// Actually, this is the last one<br>
bool end = 2;<br>
// Next lightning node.<br>
pubkey lightning = 3;<br>
// Other realms go here...<br>
}<br>
<br>
// How much fee you can take (== all, if last node)<br>
required int32 fee = 4;<br>
<br>
// Remainder (route blob for next node).<br>
required bytes route = 5;<br>
<br>
If the sum is wrong, the routing has failed (it's been corrupted or was<br>
malformed to start).<br>
<br>
Nodes create the route backwards, to calculate the size. Then picks a<br>
total size randomly between 1024 and 4096, and pads to that size (at<br>
least 32 bytes of random padding). Then walks backwards to wrap and<br>
encrypt it.<br>
<br>
This offers some protection from guessing the route length.<br>
<br>
Route Probing Attacks<br>
=====================<br>
Now, there's a weakness here: No MAC! A nosy node can't corrupt the<br>
routing past the next hop, but it could replace it entirely (this is<br>
fundamental to the scheme of R values). If it guesses the final<br>
destination right, the HTLC will succeed, otherwise it will fail, so it<br>
can use this to probe.<br>
<br>
One partial defence is to fail to allow two HTLCs with the same R value,<br>
forcing probe serialization. Unfortunately that allows a simple way to<br>
probe back to the source, so we shouldn't do this!<br>
<br>
We may be able to do some probabalistic backoff of duplicate R values,<br>
such that you can't tell if I've received one before? A more<br>
sophisticated probe sequence could get a probability though...<br>
<br>
I can't see a fix for this in general. :(<br>
<br>
Error Messages<br>
==============<br>
Another issue is that we should try not to leak information to passive<br>
observers on the route due to errors, so signing errors and using the<br>
'sum' field as a secret key seems sensible. This means your padding in<br>
the original message needs to be "random" so 'sum' is random.<br>
<br>
Thoughts welcome!<br>
Rusty.<br>
PS. As noted before, nodes can trivially correlate HTLCs by R value, so<br>
onioning the routing only gets you so far...<br>
</blockquote></div>