Rusty Russell <ru...@rustcorp.com.au> writes: >> Would it not be better to create a circular path? By this I mean, >> Alice constructs an onion that overall creates a path from herself to >> Bob and back, ensuring different nodes on the forward and return >> directions. The onion hop at Bob reveals that Bob is the chosen >> conversation partner, and Bob forwards its reply via the onion return >> path (that Alice prepared herself to get back to her via another >> path). > > I like it! The lack of "reply" function eliminates all storage > requirements for the intermediaries. Unfortunately it's not currently > possible to fit the reply onion inside the existing onion, but I know > Christian has a rabbit in his hat for this?
I think circular payment really means an onion that is > A -> ... -> B -> ... -> A and not a reply onion inside of a forward onion. The problem with the circular path is that the "recipient" cannot add any reply without invalidating the HMACs on the return leg of the onion. The onion is fully predetermined by the sender, any malleability introduced in order to allow the recipient to reply poses a threat to the integrity of the onion routing, e.g., it opens us up to probing by fiddling with parts of the onion until the attacker identifies the location the recipient is supposed to put his reply into. As Rusty mentioned I have a construction of the onion routing packet that allows us to compress it in such a way that it fits inside of the payload itself. I'll write up a complete proposal over the coming days, but the basic idea is to initialize the unused part of the onion in such a way that it cancels out the layers of encryption and the fully wrapped onion consists of all `0x00` bytes. These can then be removed resulting in a compressed onion, and the sender can simply add the padding 0x00 bytes back to get the original, fully HMACd onion, and then send it like normal (there is an obfuscation step to hide the `0x00` bytes from the next hop, but more on this in the full rendez-vous proposal later). This rendez-vous construction is a bit more involved since we want to fit an onion into another onion of the same size. If we design a completely new messaging system, requiring end-to-end communication, it might be worth re-introducing the end-to-end payload which we removed in the routing onion. It's a simply, variable or fixed length, payload, that is onion-decrypted at each hop and its contents are revealed to the destination (this is how onion routing usually works). Since that payload doesn't have to adhere to the constraints of the routing onions (multiple payloads, one for each hop, and no special larger payload destined for the final recipient) this is both simpler, and would allow us to store a full, unmodified, return-onion in the end-to-end payload. Another advantage is that the end-to-end payload is not covered by the HMACs in the header, meaning that the recipient can construct a reply without having to modify (and invalidate) the routing onion. I guess this is going back to the roots of the Sphinx paper :-) Might be worth a consideration, as it seems to me like it'd be simpler :-) The downside of course is that we'd end up with two different onion constructions for different use-cases. >> After Alice receives the first message from Bob the circular >> "circuit" is established and they can continue to communicate using >> the same circuit: timing attacks are now "impossible" since Alice and >> Bob can be anywhere along the circle, even if two of the nodes in the >> circuit are surveillors cooperating with each other, the timing >> information they get is the distance between the surveillor nodes. >> >> Of course, if a node in the circular path drops the circuit is >> disrupted, so any higher-level protocols on top of that should >> probably be willing to resume the conversation on another circular >> circuit. > > My immediate purpose for this is for "offers" which cause a invoice > request, followed by an invoice reply. This will probably be reused > once for the payment itself. 2 uses is not sufficient to justify > setting up a circuit, AFAICT. I know someone who is itching to implement hornet for these use-cases ;-) Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
