ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-04 📝 Original message: Good morning CJP, > > > I ...
📅 Original date posted:2018-12-04
📝 Original message:
Good morning CJP,
> > > 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.
I believe not?
For example if the route is A -> B -> C:
1. C creates an invoice secret i, and the invoice point I = i * G, and gives I to node A.
2. A creates two secrets k[a] and k[b], and total sum k = k[a] + k[b].
3. A creates points K[A] = k[a] * G and K[B] = k[b] * G.
4. A creates an onion as below:
* layer 0 (to B): decorrelation_secret = k[b]
* layer 1 (to B): total_decorrelation_secrets = k = k[a] + k[b]
5. A offers the HTLC to B, for the secret to the point (I + K[A]).
6. B offers the HTLC to C, for the secret to the point ((I + K[A]) + K[B]).
The total_decorrelation_secrets serves as the payer-generated shared secret between payer and payee.
B cannot learn this, and thus cannot fake its own secret.
Even if it instead offers ((I + K[A]) + k[z] * G) for a new secret k[z], it cannot know how to change total_decorrelation_secrets from k[a] + k[b] to k[a] + k[z] instead.
Regards,
ZmnSCPxj
Published at
2023-06-09 12:53:20Event JSON
{
"id": "6adfcd325f6101e86166d922df9c4276ee93ca332c86f9e8c060019d96c11fa5",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315200,
"kind": 1,
"tags": [
[
"e",
"2fcb445dd574564835b2068c030ba4e556383d5b915eb5763f6fba62ac8aa302",
"",
"root"
],
[
"e",
"c6fef865725ee6034f6d8dc3c9f9ac1e06a94ac47fbaf20365f9c53532b269d0",
"",
"reply"
],
[
"p",
"f928c1a284fddb630ed23aab2bfe69811423a59f41dd8c3e40c57b916fbadf65"
]
],
"content": "📅 Original date posted:2018-12-04\n📝 Original message:\nGood morning CJP,\n\n\n\u003e \u003e \u003e I think we could stop this type of attack by including some kind of\n\u003e \u003e \u003e shared secret in the onion message to the final node:\n\u003e \u003e \u003e I think we get this \"for free\" if we switch to path decorrelation and points+privkeys instead of hashes+preimages.\n\u003e \u003e\n\u003e \u003e Path decorrelation means that each hop is given a random point, to be added to the next SS \"HTLC\".\n\u003e \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 \u003e The final node also cannot differentiate between an incorrect total for this scalar, or an incorrect \"invoice hash\"/invoice point.\n\u003e \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 That might indeed stop an attacker from testing 2nd-degree, 3rd-degree\n\u003e etc. neighbors, making the attack much less versatile. However, for his\n\u003e direct neighbor in the route, the attacker does learn the point to be\n\u003e used in that hop. Therefore I think the attacker can still test whether\n\u003e or not the next node is the final hop.\n\nI believe not?\n\nFor example if the route is A -\u003e B -\u003e C:\n\n1. C creates an invoice secret i, and the invoice point I = i * G, and gives I to node A.\n2. A creates two secrets k[a] and k[b], and total sum k = k[a] + k[b].\n3. A creates points K[A] = k[a] * G and K[B] = k[b] * G.\n4. A creates an onion as below:\n * layer 0 (to B): decorrelation_secret = k[b]\n * layer 1 (to B): total_decorrelation_secrets = k = k[a] + k[b]\n5. A offers the HTLC to B, for the secret to the point (I + K[A]).\n6. B offers the HTLC to C, for the secret to the point ((I + K[A]) + K[B]).\n\nThe total_decorrelation_secrets serves as the payer-generated shared secret between payer and payee.\nB cannot learn this, and thus cannot fake its own secret.\nEven if it instead offers ((I + K[A]) + k[z] * G) for a new secret k[z], it cannot know how to change total_decorrelation_secrets from k[a] + k[b] to k[a] + k[z] instead.\n\nRegards,\nZmnSCPxj",
"sig": "c3273885a1c1fd160c2c2207eda7bcf1dbacee7a69849b26c442caec2d8d26c01f30cc8f9bafb5c667205bdf333ffad47da43ba99b42a69a0badd514dd344730"
}