From laolu32 at gmail.com Fri Dec 18 22:16:22 2015 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Fri, 18 Dec 2015 22:16:22 +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 afraid I don't understand how this backwards-compatibility works, > so if it is important that I understand it please point me to docs or > explain it more. > So we don't have any docs out (yet). But the general ideas arises from considering the following scenario: an edge wallet wishes to send funds over lightning to 49hwYWYV26Qgym2n1GnpgxBffhKf at roasbeef.computer. Assuming we're not use HORNET for payment related messages, the wallet attempts to connect directly to roasbeef.computer but is unable to. As a fallback, the wallet simply decodes the ID from base58, appends the checksum, adds a version byte, and then sends the coins to the resulting address. Essentially, the idea is to have an easy mechanism for a graceful fallback to regular on-chain Bitcoin transactions. But, it's really just a half-baked idea at this point. Do you mind explaining why you think this is safe? I don't understand > how it could be safe, in the case that the attacker knows a private > key that maps to the same 128-bit nodeid as a user's private key does. > Sure. Also, I'm referring to colliding public-key hashes. So for a moment let's view the network as essentially having two namespaces: global vs local. It's not a requirement that the local namespace be of lower cardinality than the global namespace. However, in the case of 16-byte local (mix-net) ID, and 32-byte global ID (LN) it is, therefore collisions are more frequent. In practice, I think this is safe because in the case a global node ID conflicts with the local mix-net ID, it doesn't undermine the propagation of an HTLC, since only one node will be able to successfully check the MAC, and unwrap the mix-header for the next hop. Here's an illustration: Say Alice wishes to send funds to Dave, and her channel sub-graph looks like this: Estelle / Alice -- Bob \ Carol - Dave Alice collects the necessary public keys for the route: Bob -> Carol -> Dave. She then generates the Sphinx mix-header for the route. As a step in the process she generates 16-byte local node ID's for the "next-hop" part of each node's mix-header. She then sends the mix-header to Bob, the first hop. However, unbeknownst to Alice, the 16-byte ID of Estelle's public-key collides with Carol's ID. Bob get's the mix-header, and processes it as normal: checks the MAC, re-blinds group element, and finally peels off layer from nested mix-header. Bob then realizes there's a collision in the local namespace. So he first tries to send the mix-header to Estelle first. Estelle rejects the mix-header because she's unable to check the MAC since her derived shared secret isn't the one Alice computed for this hop. Bob gets this error message, so he instead forwards it to Carol, who accepts, resulting in everything continuing as normal. To Estelle it just looks like Bob computed the mix-header incorrectly, or simply forwarded to the wrong node. I think that's okay (there may be something I'm overlooking)? > > 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. > > I don't understand why the use of entire public keys instead of > possibly-truncated hashes of public keys would force a decision about > which cipher and MAC to use. > Sphinx requires that the mix-net node ID's be the same size as the MAC within the mix-header. So if node ID's in the mix-net were 32-bytes, then we couldn't use poly3015 to generate tags since its tag size is 16-bytes. -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: