Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-21 📝 Original message: Rusty Russell <rusty at ...

📅 Original date posted:2020-02-21
📝 Original message:
Rusty Russell <rusty at 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