📅 Original date posted:2018-11-13
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:52:24
in reply to nevent1q…ecxq
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:52:24Event JSON
{
"id": "03f991d9b41e0c6fb3d8161cf4e88ea49f2264e410285ac67c8178d1b6e312d4",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315144,
"kind": 1,
"tags": [
[
"e",
"f4b5ffab7a9c96d8928a76b4653d399422785cf29dac19cdb8e24eff6d895c9a",
"",
"root"
],
[
"e",
"0e4b7d6c9e4d3b1d5458455e1f5c7e9a7b9dbe89932f5ee51cce42aedf7585b0",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-13\n📝 Original message:\nGreat proposal ZmnSCPxj, but I think I need to raise a small issue with\nit. While writing up the proposal for rendez-vous I came across a\nproblem with the mechanism I described during the spec meeting: the\npadding at the rendez-vous point would usually zero-padded and then\nencrypted in one go with the shared secret that was generated from the\nprevious ephemeral key (i.e., the one before the switch). That ephemeral\nkey is not known to the recipient (barring additional rounds of\ncommunication) so the recipient would be unable to compute the correct\nMACs. There are a number of solutions to this, basically setting the\npadding to something that the recipient could know when generating its\nhalf onion.\n\nMy current favorite goes like this:\n\n 1. Rendez-vous RV receives an onion, performs ECDH like normal to get\n the shared secret, decrypts its payload, simultaneously encrypts\n the padding.\n 2. It extracts its per-hop payload and shifts the entire packet over\n (shift its payload out and the newly generated padding in)\n 3. It then notices that it should perform an ephemeral key switch, now\n deviating from the normal protocol (which would just be to generate\n the new ephemeral key, serialize and forward)\n 3.1. It zero-fills the padding that it just added (so we are in a\n state that the recipient knew when generating its partial onion\n 3.2 It performs ECDH with the switched in ephemeral key to get a new\n shared secret that which is then used to unwrap one additional\n layer of encryption, and most importantly encrypt the padding so\n the next hop doesn't see the zero-filled padding.\n 3.3 Only then will it generate the new ephemeral key for the next\n hop, based on the switched in ephemeral key and the newly\n generated shared secret, serialize the packet and forward it.\n\nThis has the advantage of reusing all the existing machinery but\nassembling it a bit differently, by adding a little detour when\ngenerating the next onion. It involves one additional ECDH at the\nrendez-vous, one ChaCha20 encryption and one scalar multiplication to\ngenerate the next ephemeral keys. It does not need more space than the\nsingle ephemeral key in the per-hop payload.\n\nAnd now for the reason that I write this as a reply to your post: with\nthis scheme it is not possible for C to find an ephemeral key that would\nend up identical to the one that D would require to decrypt the onion\ncorrectly. This would not be an issue if D is informed about this split\nand would basically accept whatever it gets, but that kind of defeats\nthe transparency that you were going for with your proposal.\n\nI'm open for other proposals but I currently can't think of a way to\nmake sure that a) the recipient can deterministically generate the same\npadding that RV will generate, and b) hide the fact that RV was indeed a\nrendez-vous point (e.g., by leaving the padding be a well known\nconstant).\n\nSorry for this problem, I had a mental off-by-one at the meeting that I\nhadn't considered, the solution should work, but it makes this kind of\nthings a bit harder.\n\nCheers,\nChristian\n \n\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nwrites:\n\u003e Good morning list,\n\u003e\n\u003e As was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing.\n\u003e\n\u003e 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.\n\u003e\n\u003e For instance, consider this below graph:\n\u003e\n\u003e E\u003c---D---\u003eC\u003c---B\n\u003e ^ /\n\u003e | /\n\u003e |L\n\u003e A\n\u003e\n\u003e In the above, B requests a route from B-\u003eC-\u003eD-\u003eE.\n\u003e\n\u003e However, C cannot send to D, since the channel direction is saturated in favor of D.\n\u003e\n\u003e 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.\n\u003e\n\u003e This can allow re-routing or payment splitting over multiple hops.\n\u003e\n\u003e 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.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "04daa2bd317376344093227caf660b3544935f5872f7e62355613261b9acba5e7fe00e8e6d1b6d89291d7f84b655bc21c41bde4bef0215858d68cccb4c05ccfa"
}