From laolu32 at gmail.com Thu Dec 17 18:08:24 2015 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Thu, 17 Dec 2015 18:08:24 +0000 Subject: [Lightning-dev] An Alternative Onion-Routing Proposal In-Reply-To: References: <87wpsgh28z.fsf@rustcorp.com.au> <87d1u7xoxl.fsf@rustcorp.com.au> Message-ID: > > > > > > I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I > used) vs ChaCha20+poly1035. > > I'd prefer ChaCha20+poly1305. > Welcome aboard the Cha Cha Train! [1] > > > 128 bits definitely seems a bit tight for node ids: I assumed a full > > bitcoin EC pubkey in my current implementation. > > I have a pretty good sense of how risky short node ids are, but I > don't have a good idea of how costly long node ids are in this > context. I also don't know how many node ids are likely to exist in > the long-run, successful scenario. 10?? 10??? Not more than 10??! > > I'd suggest 192-bit nodeids, based on such musings as: > > * > http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html > > * http://www.keylength.com/en/compare/ > > I feel confident that 192-bit nodeids are safe enough. Whether they > are, practically speaking, more efficient than 256-bit nodeids I'll > leave up to you to answer. > > Currently, in our code, node ID's take two forms: either the hash160 (Bitcoin style) of a node's current pub-key or the raw serialized pub-key itself. This is done such that "nodeID at host" locators explicitly provide a level of backwards (p2pkh) compatibility for end wallets that are unable to establish a connection in a timely manner. Within the Sphinx mix-header, I think we should be safely able to truncate this (the hash160) to 16-bytes. In the case of a collision, the onion-route propagation across the incorrect node will simply fail, as it won't be able to properly derive the shared secret. Otherwise, we'd be forced to ditch chacha20+poly3015 for AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node ID's in the routing info. > > 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 :) > > I can't blame him! Utilizing HORNET's rendezvous protocol will allow for a high level of privacy for both sender *and* receiver. > > > 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. > > > > Sure. If we end up going with cha cha, I'd like us to adopt the practice of encrypting the packet lengths with a separate key (and a new instance of chacha20) similar to openssh's chacha20-poly3015 specification[2]. With this construction, packet-length+packet-payload remain confidential. > > PS. Are we having fun yet? > > Definitely! On my Winter Break atm, so getting a chance to catch up on all the fun I missed out on during this past quarter :) 1. https://www.youtube.com/watch?v=xGQ5OOyuaxs 2. https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00 -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: