[Lightning-dev] Direct Message draft

[ZmnSCPxj]

Good morning Christian, and Rusty,

> > > 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.

At the risk of constructing a novel cryptosystem, I think we can separate the request/response from the onion.
We effectively treat the onion as establishing a *non*-encrypted temporary tunnel, and add an asymmetric encryption between Alice and Bob for the request and response.

The onion is kept as-is (except without information about HTLC amounts and timelocks).
We add a field *uotside* the onion which contains the request/response.
At each hop, we derive a key from the shared secret between the ephemeral keypair and the hop keypair, and use the derived key to generate a symmetric stream cipher to encrypt the separated request/response.

Alice first creates a *separate* ephemeral key just for communication with Bob.
It encrypts the request using this level 2 ephemeral key and adds a MAC tag as well, and treat the encrypted request plus the MAC tag as a binary blob.
Then, for each hop, it derives the symmetric stream cipher using the onion (level 1) ephemeral key with that hop and applies the stream cipher on it.
Then it sends out the completed onion plus this encrypted request/response blob.

Each hop effectively peels a layer of encryption, because it is a symmetric stream cipher.
On reaching Bob, the encrypted request/response message plus MAC tag is revealed to Bob.
Bob learns it is the true destination by some TLV in the onion part, including the (level 2) ephemeral key, then validates the MAC using the Alice and Bob shared secret and if it is valid, decrypts the request part and processes the request.

Bob then generates its reply, and encrypts the reply with the shared secret between its static key and the level 2 ephemeral key, then creates a MAC using the level 2 ephemeral key and its static key.
Then it sends it together with the rest of the onion onward.

Each hop after Bob effectively adds a layer of encryption, because it is a symmetric stream cipher.
On reaching Alice, Alice (who knows the entire route, since it was the one who established the route) can peel every layer between Bob and Alice on the return route.
Then it should get the binary blob that is the (level 2) encryption of the reply plus a MAC, validates the MAC, then decrypts the reply.

We treat the tunnel as unencrypted (i.e. we have a level 2 asymmetric encryption between Alice and Bob) because the request/response is outside the onion.
We still bother to do a multilayer encryption so that, in case of a route like A->I->J->K->L->B, where I and L are controlled by the same surveillor, the request/response is different at each hop and I and L cannot be certain they are on the same route (though of course timing and message size can improve their accuracy --- we can have a fixed size for the request/response to hide message size, but we can do nothing about timing).

My *vague* understanding is that HORNET is effectively a better version of this --- it uses a "full" onion to establish a circuit, then uses simpler symmetric ciphers during circuit operation.
This effectively tears down the circuit as soon as the message passes through.


>
> 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 :-)

Hmmm okay..... is this basically what I just described above?



>
> 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.

"Use the best tool for the job"?

Regards,
ZmnSCPxj