From zooko at leastauthority.com Tue Sep 22 01:27:03 2015 From: zooko at leastauthority.com (Zooko Wilcox-OHearn) Date: Tue, 22 Sep 2015 01:27:03 +0000 Subject: [Lightning-dev] Onion routing design. In-Reply-To: <8737ybi9fj.fsf@rustcorp.com.au> References: <8737ybi9fj.fsf@rustcorp.com.au> Message-ID: Could you please point me to any notes about requirements/desiderata? Thanks! --Zooko On Sep 18, 2015 5:47 PM, "Rusty Russell" 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: