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
📝 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