From rusty at rustcorp.com.au Tue Dec 15 23:38:46 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 16 Dec 2015 10:08:46 +1030 Subject: [Lightning-dev] An Alternative Onion-Routing Proposal In-Reply-To: References: <87wpsgh28z.fsf@rustcorp.com.au> Message-ID: <87d1u7xoxl.fsf@rustcorp.com.au> Olaoluwa Osuntokun 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 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?