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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
