[Lightning-dev] An Alternative Onion-Routing Proposal

[Rusty Russell]

Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>>
>> Not sure where these numbers come from?  The current header overhead is
>> sha256 (32 bytes) + pubkey (33 bytes), or 1300 bytes.  (Don't be
>> confused by the current test implementation which doesn't serialize the
>> pubkey).
>>
>
> Hmm, I pulled those numbers from here:
> http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/000247.html:
> "That's a fixed 3840 bytes; each node decrypts and removed the tail entry,
> then prepends padding." Perhaps there's been a newer iteration I've missed,
> or the 3.8K bytes isn't the true serialized size.

Hi Roasbeef!

Ah, that includes payloads for each node, though, not just the headers.
There's stuff in there for Future Use.

>> If we were to cut to a 16 byte MAC (which seems unwise)
>
> With Poly1035 (which takes 32-byte key and produces a 16-byte tag), forged
> messages are rejected with a probability of 1-(n/(2^102)) for a 16n-byte
> message[1].  Since the MAC is computed over the 656 byte (20 hops, s=16)
> routing-info portion (the onion-wrapped part of the mix header), forged
> tags will be rejected with a probability of 1-(656/(2^102)), which seems
> okay to me.

Ah, I hadn't appreciated that poly1035 was 128 bit tags already!  Let's
argue it in the crypto thread which we'll start.  I'm happy to the
crypto experts debate AES-CTR + HMAC-SHA-256 (which I used) vs
ChaCha20+poly1035.

It's a simple change, code-wise.

>> Or, if we're standarizing on ChaCha20, with a 32-byte key:
>>
>>    33 + (2 * 20 + 2) * 32 = 1377 bytes.
>>
>
> Apologies for the ambiguity, but, the "(..)*16" (s) more accurately refers
> to the size of the HMAC and node ID's. So if using ChaCha for a stream
> cipher, and Poly1035 for MACs rather than AES-CTR + a truncated
> SHA-256-HMAC, the size remains the same. Either AES-CTR or ChaCha20 are
> valid candidates for the required stream-cipher in the Sphinx construction.
>
> As an side, my current implementation uses AES-CTR as a stream cipher, and
> a truncated SHA-256-HMAC for the MAC (s=20). It was written before we
> cozied up to ChaCha20-Poly1035. I'll be porting it over to ChaCha-Poly3015
> once I tick off some more high-priority items from my TODO list (assuming
> we're comfortable with 16-byte node ID's, node ID's are used to map to a
> node's current DH-key (id -> key)).

128 bits definitely seems a bit tight for node ids: I assumed a full
bitcoin EC pubkey in my current implementation.

> HORNET seems a bit over-the-horizon for now
>>
>
> Agreed! Sphinx should be sufficient for now.

Matts was really interested in sending messages over LN, though, so no
doubt he'll be salivating at the idea of extending in this direction :)

> Great!  Let's argue about protobufs and ChaCha20 vs AES before then :)
>>
>
> Perhaps in a new thread :)
>
> Oh, and also, we've come up with a slight variation on the current proposed
> p2p crypto handshake. It builds off of the current method (ephemerals
> first, etc.). I should get around to posting it to the ML sometime
> tomorrow+1 (I'd like to make sure it's sound).

Sure, let's discuss that.  I want to modify the handshake anyway to
include a <len> prefix (like every other message).  This lets us upgrade
the crypto later, by appending a key for a different system.

> 1. https://tools.ietf.org/html/rfc7539 (Section 4)

That's a definite MUST READ for any implementer...

Thanks!
Rusty.
PS.  Are we having fun yet?