📅 Original date posted:2020-02-24
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> Rusty Russell <rusty at rustcorp.com.au> writes:
>
>> 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 think this has the same problem though, that there's no way Alice can
send Bob an onion to use with an arbitrary message?
> 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 :-)
Good point, and it's trivial. The paper suggests the payload be "final
key" followed by the desired data, providing a simple validation scheme.
We could potentially generalize the HTLC messages like this, but it's
unnecessary at this point.
Thanks,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:59:03
in reply to nevent1q…dpks
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:59:03Event JSON
{
"id": "10a29e3d065fb1e294b291b50184eb8aae25aa4c86e760979296695bbef59563",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315543,
"kind": 1,
"tags": [
[
"e",
"42cfc200e7833f933bf8544e61c12de15ea87116a820ad682a285378ff7c555e",
"",
"root"
],
[
"e",
"abf4521741fc57b285561d2657baaa4c6eaed6d521837699a70ffbb493563bfe",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-02-24\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e Rusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e\n\u003e\u003e I like it! The lack of \"reply\" function eliminates all storage\n\u003e\u003e requirements for the intermediaries. Unfortunately it's not currently\n\u003e\u003e possible to fit the reply onion inside the existing onion, but I know\n\u003e\u003e Christian has a rabbit in his hat for this?\n\u003e\n\u003e I think circular payment really means an onion that is\n\u003e\n\u003e\u003e A -\u003e ... -\u003e B -\u003e ... -\u003e A\n\u003e\n\u003e and not a reply onion inside of a forward onion.\n\u003e\n\u003e The problem with the circular path is that the \"recipient\" cannot add\n\u003e any reply without invalidating the HMACs on the return leg of the\n\u003e onion. The onion is fully predetermined by the sender, any malleability\n\u003e introduced in order to allow the recipient to reply poses a threat to\n\u003e the integrity of the onion routing, e.g., it opens us up to probing by\n\u003e fiddling with parts of the onion until the attacker identifies the\n\u003e location the recipient is supposed to put his reply into.\n\u003e\n\u003e As Rusty mentioned I have a construction of the onion routing packet\n\u003e that allows us to compress it in such a way that it fits inside of the\n\u003e payload itself.\n\nI think this has the same problem though, that there's no way Alice can\nsend Bob an onion to use with an arbitrary message?\n\n\u003e Another advantage is that the end-to-end payload is not covered by the\n\u003e HMACs in the header, meaning that the recipient can construct a reply\n\u003e without having to modify (and invalidate) the routing onion. I guess\n\u003e this is going back to the roots of the Sphinx paper :-)\n\nGood point, and it's trivial. The paper suggests the payload be \"final\nkey\" followed by the desired data, providing a simple validation scheme.\n\nWe could potentially generalize the HTLC messages like this, but it's\nunnecessary at this point.\n\nThanks,\nRusty.",
"sig": "9e823c3bbe2d4caf66a6bcad4c62838ea29a675136ec5fbcac0d56251ce1c23c38f3fef68fd956e1638eb5d1e8926199696debcd65ade476ebc62c8cf769aac1"
}