Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-04 📝 Original message: >> I think we could stop ...
📅 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
📝 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