[Lightning-dev] Onion routing design.

[Rusty Russell]

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:
>>        // 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;
>
>>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.
> Wouldn't it be better to store the expected balance to be forwarded rather than the fee? That way if someone takes too much, the next node can immediately abort the transaction.

Yes, excellent point.  I flip-flopped on that; so I flipped again.

> Shouldn't the onion blob be re-padded when forwarded? Otherwise it'd
> sometimes drop below 1024 bytes and you'd be able to tell you're near
> the end of the chain.

Yes and this applies for almost any length selection method.

> Just adding random bytes on to the end should
> work I think - they'll just be treated as extra padding and ignored.

My original plan.  But it enables a probing attack where you corrupt the
packet and if it succeeds anyway you know those bytes weren't used.

> Alternatively, maybe you could just append the encrypted bytes that made up your post of the payload from your incoming message: it was encrypted to you so should be effectively random to anyone else and will be garbled further when the next node "decrypts" it. That would save on entropy/crypto ops, and a constant message size would leak minimal info I think.

So rotate the payload?  I don't think that's verifiable by the
recipient, so has the same probing attack issue as above.

Hmm, what if we include a pubkey, and you use that to encrypt 0 padding?
The last hop gets the privkey (and boundary information), and she can
verify the padding.

Off the top of my head, that solves both the length problem, and the
"route replacement" problem.

But I've not had coffee yet, plus jetlag.  Could be missing a flaw or
simplification!

Thanks,
Rusty.