📅 Original date posted:2016-08-16
📝 Original message:
On Tue, Aug 16, 2016 at 04:54:32AM +0000, Olaoluwa Osuntokun wrote:
> > I was thinking that it'd be stored in the per-hop payload, along with
> > the instructions for the hop, which is why I did not specify it, but
> > I'm happy to add it, should it make things clearer.
> >
> >
> I think the byte specifying the target realm should be protected under a
> MAC, as forwarding to the correct realm may be critical in order for the
> payment to succeed. Therefore, if we retain the MAC for the per-hop payload
> then it can be placed there, otherwise they header may need to extended by
> a byte in order to place the realm information there.
>
> -- Laolu
Good catch! We need to make sure that the integrity of the per-hop
payload is protected at all costs. The per-hop payloads were
introduced to provide intermediate hops with instructions on what to
do, i.e., how many coins to forward, so if we can't guarantee their
integrity it could result in exploits. An attacker could for example
instruct an intermediate hop to forward more, in the hopes of
collecting it further down the line.
A mitigating fact may be that a node will forward at most the amount
it received, minus its fee, limiting this to a fee-shaving attack. But
if we can find a way to fix it, that would be great.
So it would appear we cannot drop the payloads from the MAC after all,
which makes stitching routes difficult in the case of rendezvous. The
interactive protocol I outlined before may still works, but it is
rather ugly as it deviates from the invoice pattern, i.e., the final
recipient gives the necessary information for the transfer in a single
bundle.
Cheers,
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:46:26
in reply to nevent1q…04m8
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:46:26Event JSON
{
"id": "cb9ab5c71a68a03b7550ea1f1629868ce5f135ffa74b411f0a7ea2bcaa9371d9",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314786,
"kind": 1,
"tags": [
[
"e",
"f166a20039cde752a8ba4e6cccc22d4b2719f9a29840f0c295641243ae59d83f",
"",
"root"
],
[
"e",
"aa8dbe695eea957a6f5f5821deb6bb3e6812873339c7a783fa4aef4f5e958685",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2016-08-16\n📝 Original message:\nOn Tue, Aug 16, 2016 at 04:54:32AM +0000, Olaoluwa Osuntokun wrote:\n\u003e \u003e I was thinking that it'd be stored in the per-hop payload, along with\n\u003e \u003e the instructions for the hop, which is why I did not specify it, but\n\u003e \u003e I'm happy to add it, should it make things clearer.\n\u003e \u003e\n\u003e \u003e\n\u003e I think the byte specifying the target realm should be protected under a\n\u003e MAC, as forwarding to the correct realm may be critical in order for the\n\u003e payment to succeed. Therefore, if we retain the MAC for the per-hop payload\n\u003e then it can be placed there, otherwise they header may need to extended by\n\u003e a byte in order to place the realm information there.\n\u003e \n\u003e -- Laolu\n\nGood catch! We need to make sure that the integrity of the per-hop\npayload is protected at all costs. The per-hop payloads were\nintroduced to provide intermediate hops with instructions on what to\ndo, i.e., how many coins to forward, so if we can't guarantee their\nintegrity it could result in exploits. An attacker could for example\ninstruct an intermediate hop to forward more, in the hopes of\ncollecting it further down the line.\n\nA mitigating fact may be that a node will forward at most the amount\nit received, minus its fee, limiting this to a fee-shaving attack. But\nif we can find a way to fix it, that would be great.\n\nSo it would appear we cannot drop the payloads from the MAC after all,\nwhich makes stitching routes difficult in the case of rendezvous. The\ninteractive protocol I outlined before may still works, but it is\nrather ugly as it deviates from the invoice pattern, i.e., the final\nrecipient gives the necessary information for the transfer in a single\nbundle.\n\nCheers,\nChristian",
"sig": "7076064e8d62f35a792d9c786cdfda7d2cc2d7963b604048dd6feb3e7b806a6746b8d208936dd1fff32e031a8c3095f8b204b75b25bdd0e3ae0d7f1c1ee2e991"
}