📅 Original date posted:2018-12-04
📝 Original message:
>> I think we could stop this type of attack by including some kind of
>> shared secret in the onion message to the final node:
> I think we get this "for free" if we switch to path decorrelation and points+privkeys instead of hashes+preimages.
>
> Path decorrelation means that each hop is given a random point, to be added to the next SS "HTLC".
> The final node needs to be given the total of the scalars of each hop random point along the route, most likely within the last hop of the onion.
> The final node also cannot differentiate between an incorrect total for this scalar, or an incorrect "invoice hash"/invoice point.
>
> Hence, some intermediate node along the way cannot guess this, and the final node will give the same error, i.e. "invoice point not found".
>
>
That might indeed stop an attacker from testing 2nd-degree, 3rd-degree
etc. neighbors, making the attack much less versatile. However, for his
direct neighbor in the route, the attacker does learn the point to be
used in that hop. Therefore I think the attacker can still test whether
or not the next node is the final hop.
CJP
Corné Plooy [ARCHIVE] /
npub1ly…cdx6n
2023-06-09 12:53:20
in reply to nevent1q…z2rk
Author Public Key
npub1ly5vrg5ylhdkxrkj824jhlnfsy2z8fvlg8wcc0jqc4aezma6majsycdx6nPublished at
2023-06-09 12:53:20Event JSON
{
"id": "c6fef865725ee6034f6d8dc3c9f9ac1e06a94ac47fbaf20365f9c53532b269d0",
"pubkey": "f928c1a284fddb630ed23aab2bfe69811423a59f41dd8c3e40c57b916fbadf65",
"created_at": 1686315200,
"kind": 1,
"tags": [
[
"e",
"2fcb445dd574564835b2068c030ba4e556383d5b915eb5763f6fba62ac8aa302",
"",
"root"
],
[
"e",
"a7030c7243ba58fa126d192e6d844c2bdd29acee8df3070cfe32cc5faf6cb96d",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-12-04\n📝 Original message:\n\u003e\u003e I think we could stop this type of attack by including some kind of\n\u003e\u003e shared secret in the onion message to the final node:\n\u003e I think we get this \"for free\" if we switch to path decorrelation and points+privkeys instead of hashes+preimages.\n\u003e\n\u003e Path decorrelation means that each hop is given a random point, to be added to the next SS \"HTLC\".\n\u003e The final node needs to be given the total of the scalars of each hop random point along the route, most likely within the last hop of the onion.\n\u003e The final node also cannot differentiate between an incorrect total for this scalar, or an incorrect \"invoice hash\"/invoice point.\n\u003e\n\u003e Hence, some intermediate node along the way cannot guess this, and the final node will give the same error, i.e. \"invoice point not found\".\n\u003e\n\u003e\nThat might indeed stop an attacker from testing 2nd-degree, 3rd-degree\netc. neighbors, making the attack much less versatile. However, for his\ndirect neighbor in the route, the attacker does learn the point to be\nused in that hop. Therefore I think the attacker can still test whether\nor not the next node is the final hop.\n\n\nCJP",
"sig": "cf759b896a59b606e436b706639577390aac3c5b949eff0ac9f0788d4ee9f2aefe9f3e2ba9f915137dc1eb5df2bd9bb325cbf26d4124851e8fd98a6b6d185ba8"
}