Zooko Wilcox-OHearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-21 📝 Original message: Could you please point me ...
📅 Original date posted:2015-09-21
📝 Original message:
Could you please point me to any notes about requirements/desiderata?
Thanks!
--Zooko
On Sep 18, 2015 5:47 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
> 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150922/1abdd47c/attachment-0001.html>;
📝 Original message:
Could you please point me to any notes about requirements/desiderata?
Thanks!
--Zooko
On Sep 18, 2015 5:47 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
> 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150922/1abdd47c/attachment-0001.html>;