Great proposal ZmnSCPxj, but I think I need to raise a small issue with
it. While writing up the proposal for rendez-vous I came across a
problem with the mechanism I described during the spec meeting: the
padding at the rendez-vous point would usually zero-padded and then
encrypted in one go with the shared secret that was generated from the
previous ephemeral key (i.e., the one before the switch). That ephemeral
key is not known to the recipient (barring additional rounds of
communication) so the recipient would be unable to compute the correct
MACs. There are a number of solutions to this, basically setting the
padding to something that the recipient could know when generating its
half onion.
My current favorite goes like this:
1. Rendez-vous RV receives an onion, performs ECDH like normal to get
the shared secret, decrypts its payload, simultaneously encrypts
the padding.
2. It extracts its per-hop payload and shifts the entire packet over
(shift its payload out and the newly generated padding in)
3. It then notices that it should perform an ephemeral key switch, now
deviating from the normal protocol (which would just be to generate
the new ephemeral key, serialize and forward)
3.1. It zero-fills the padding that it just added (so we are in a
state that the recipient knew when generating its partial onion
3.2 It performs ECDH with the switched in ephemeral key to get a new
shared secret that which is then used to unwrap one additional
layer of encryption, and most importantly encrypt the padding so
the next hop doesn't see the zero-filled padding.
3.3 Only then will it generate the new ephemeral key for the next
hop, based on the switched in ephemeral key and the newly
generated shared secret, serialize the packet and forward it.
This has the advantage of reusing all the existing machinery but
assembling it a bit differently, by adding a little detour when
generating the next onion. It involves one additional ECDH at the
rendez-vous, one ChaCha20 encryption and one scalar multiplication to
generate the next ephemeral keys. It does not need more space than the
single ephemeral key in the per-hop payload.
And now for the reason that I write this as a reply to your post: with
this scheme it is not possible for C to find an ephemeral key that would
end up identical to the one that D would require to decrypt the onion
correctly. This would not be an issue if D is informed about this split
and would basically accept whatever it gets, but that kind of defeats
the transparency that you were going for with your proposal.
I'm open for other proposals but I currently can't think of a way to
make sure that a) the recipient can deterministically generate the same
padding that RV will generate, and b) hide the fact that RV was indeed a
rendez-vous point (e.g., by leaving the padding be a well known
constant).
Sorry for this problem, I had a mental off-by-one at the meeting that I
hadn't considered, the solution should work, but it makes this kind of
things a bit harder.
Cheers,
Christian
ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org>
writes:
> Good morning list,
>
> As was discussed directly in summit, we accept link-lvel payment splitting
> (scid is not binding), and provisionally accept rendez-vous routing.
>
> It strikes me, that even if your node has only a single channel to the next
> node (c-lightning), it is possible, to still perform link-level payment
> splitting/re-routing.
>
> For instance, consider this below graph:
>
> E<---D--->C<---B
> ^ /
> | /
> |L
> A
>
> In the above, B requests a route from B->C->D->E.
>
> However, C cannot send to D, since the channel direction is saturated in
> favor of D.
>
> Alternately, C can route to D via A instead. It holds the (encrypted) route
> from D to E. It can take that sub-route and treat it as a partial
> route-to-payee under rendez-vous routing, as long as node A supports
> rendez-vous routing.
>
> This can allow re-routing or payment splitting over multiple hops.
>
> Even though C does not know the number of remaining hops between D and the
> destination, its alternative is to earn nothing anyway as its only
> alternative is to fail the routing. At least with this, there is a chance it
> can succeed to send the payment to the final destination.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
