📅 Original date posted:2016-09-02
📝 Original message:
I'd like to pick up the conversation about the onion routing protocol
again, since we are close to merging our implementation into the
lightningd node.
As far as I can see we mostly agree on the spec, with some issues that
should be deferred until later/to other specs:
- Key-rotation policies
- Backlog of seen shared secrets
- Payload formatting (what data to include and how it is encoded)
The last pressing issue is the use of the HMAC, specifically what the
per-hop verifiable HMAC should include. Having it cover the entirety
of the packet, including the payloads, has the advantage that
corrupted packets get dropped immediately, which prevents the route
length discovery attacks Rusty described and we make more efficient
use of our funds, i.e., drop a transfer immediately not allocating
HTLCs for a payment that is destined to fail, and quicker retries.
The downside is the rendezvous problem, in which the recipient would
provide part of the onion, hence the sender cannot compute the
HMACs. We can potentially sidestep this with a partially trusted
reflector, have an interactive construction of the packet, or come up
with a new scheme ourselves. Anyway, I'm happy to shelve this aspect
for a future v2 of the onion routing protocol, and include the payload
in the HMAC.
I think for now we should also keep the payload sizes fixed at 20
bytes for per-hop and 1024 byte for end-to-end payload, and we can
discuss how to format those payloads in another spec. Since we seem to
want to add and remove bits and pieces it might be worth to make it
flexible using a generic encoding (JSON, msgpack, ...). This
potentially includes the "forward X units of coin Y" and the "expect X
units" for the endpoint. We can also address the "last-hop corrupts"
problem in the payload with an additional end-to-end secret like you
suggested. Having them in the per-hop payload and HMACing the payloads
secures them against tampering.
Let me know if there is any major thing that is not/insufficiently
addressed. BTW do we have a process in place for upgrading spec drafts
or do we keep things informal?
Regards,
Christian
On Mon, Aug 22, 2016 at 07:47:56PM +0000, Olaoluwa Osuntokun wrote:
> On Sun, Aug 21, 2016 at 1:46 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> > > This may not fully solve the problem, since if one presumes that the
> > > second-to-last hop is malicious, they can re-create a new onion blob
> > > (presuming consistent hashes for each hop, of course).
> >
> > Great catch. Oops...
> >
>
> During the whole payment negotiation process, the sender and receiver can
> additionally agree on a shared secret-ish value (possibly the hash of the
> contract) that should be included in the per-hop payload for the final hop.
>
> If the portion of the per-hop payload doesn't match identically with this
> value, then the payment should be rejected as a prior node has
> unsuccessfully attempted re-create the onion packet.
>
>
> -- Laolu
> _______________________________________________
> 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:46:40
in reply to nevent1q…0lep
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:46:40Event JSON
{
"id": "b3f19c20c87c09846bee709ff504e85106e0e7d904d9f8ddabb51e4d907b388a",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314800,
"kind": 1,
"tags": [
[
"e",
"6e65ece61bd323b60e8549dd5955ce1565ad06118112038c52f2e00d9538477b",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2016-09-02\n📝 Original message:\nI'd like to pick up the conversation about the onion routing protocol\nagain, since we are close to merging our implementation into the\nlightningd node.\n\nAs far as I can see we mostly agree on the spec, with some issues that\nshould be deferred until later/to other specs:\n\n - Key-rotation policies\n - Backlog of seen shared secrets\n - Payload formatting (what data to include and how it is encoded)\n\nThe last pressing issue is the use of the HMAC, specifically what the\nper-hop verifiable HMAC should include. Having it cover the entirety\nof the packet, including the payloads, has the advantage that\ncorrupted packets get dropped immediately, which prevents the route\nlength discovery attacks Rusty described and we make more efficient\nuse of our funds, i.e., drop a transfer immediately not allocating\nHTLCs for a payment that is destined to fail, and quicker retries.\n\nThe downside is the rendezvous problem, in which the recipient would\nprovide part of the onion, hence the sender cannot compute the\nHMACs. We can potentially sidestep this with a partially trusted\nreflector, have an interactive construction of the packet, or come up\nwith a new scheme ourselves. Anyway, I'm happy to shelve this aspect\nfor a future v2 of the onion routing protocol, and include the payload\nin the HMAC.\n\nI think for now we should also keep the payload sizes fixed at 20\nbytes for per-hop and 1024 byte for end-to-end payload, and we can\ndiscuss how to format those payloads in another spec. Since we seem to\nwant to add and remove bits and pieces it might be worth to make it\nflexible using a generic encoding (JSON, msgpack, ...). This\npotentially includes the \"forward X units of coin Y\" and the \"expect X\nunits\" for the endpoint. We can also address the \"last-hop corrupts\"\nproblem in the payload with an additional end-to-end secret like you\nsuggested. Having them in the per-hop payload and HMACing the payloads\nsecures them against tampering.\n\nLet me know if there is any major thing that is not/insufficiently\naddressed. BTW do we have a process in place for upgrading spec drafts\nor do we keep things informal?\n\nRegards,\nChristian\n\nOn Mon, Aug 22, 2016 at 07:47:56PM +0000, Olaoluwa Osuntokun wrote:\n\u003e On Sun, Aug 21, 2016 at 1:46 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e \n\u003e \u003e \u003e This may not fully solve the problem, since if one presumes that the\n\u003e \u003e \u003e second-to-last hop is malicious, they can re-create a new onion blob\n\u003e \u003e \u003e (presuming consistent hashes for each hop, of course).\n\u003e \u003e\n\u003e \u003e Great catch. Oops...\n\u003e \u003e\n\u003e \n\u003e During the whole payment negotiation process, the sender and receiver can\n\u003e additionally agree on a shared secret-ish value (possibly the hash of the\n\u003e contract) that should be included in the per-hop payload for the final hop.\n\u003e \n\u003e If the portion of the per-hop payload doesn't match identically with this\n\u003e value, then the payment should be rejected as a prior node has\n\u003e unsuccessfully attempted re-create the onion packet.\n\u003e \n\u003e \n\u003e -- Laolu\n\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": "290183345b801b4f744b2c5ef0a74f3986f7db01ee211fea9b3c65798c3a6df9740ff909f93024bc0903d08735d531fb184603bc90a22ec24d57e2f0188ea745"
}