From laolu32 at gmail.com Tue Dec 15 05:16:04 2015 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Tue, 15 Dec 2015 05:16:04 +0000 Subject: [Lightning-dev] An Alternative Onion-Routing Proposal In-Reply-To: <87wpsgh28z.fsf@rustcorp.com.au> References: <87wpsgh28z.fsf@rustcorp.com.au> Message-ID: > > 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. > 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. > 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)). HORNET seems a bit over-the-horizon for now > Agreed! Sphinx should be sufficient for now. 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). 1. https://tools.ietf.org/html/rfc7539 (Section 4) -------------- next part -------------- An HTML attachment was scrubbed... URL: