Corné Plooy writes:
>> 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
> * layer 0 (to B): decorrelation_secret = k[b]
> * layer 1 (to B): total_decorrelation_secrets = k = k[a] + k[b]
I would have less trouble understanding that if it were layer 1 (to C)
instead of (to B).
> The total_decorrelation_secrets serves as the payer-generated shared secret
> between
Christian Decker writes:
> Rusty Russell writes:
>>> The shared secret doesn't need to be very large: the number of attempts
>>> per second (to guess the shared secret) is limited by network latency,
>>> bandwidth and maybe some artificial rate limiting. If an attacker can do
>>> 100 attempts
Rusty Russell writes:
>> The shared secret doesn't need to be very large: the number of attempts
>> per second (to guess the shared secret) is limited by network latency,
>> bandwidth and maybe some artificial rate limiting. If an attacker can do
>> 100 attempts per second, then a 32-bit shared
Corné Plooy via Lightning-dev
writes:
> For instance, the attacking intermediate node might guess that the next
> node in the route is the final node; it can test this by completely
> replacing the onion packet it sends to the next node with a self-written
> onion packet that has the next hop as
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
>> 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
Thanks Christian, that makes sense. Unfortunately it's not very clear
from the BOLT, at least not for me.
Now that I think of this type of attack: *in general* the HMAC prevents
this kind of attack, but isn't the attack still possible in certain
specific cases?
For instance, the attacking
Hi Corne,
the HMACs are necessary in order to make sure that a hop cannot modify
the packet before forwarding, and the next node not detecting that
modification.
One potential attack that could facilitate is that an attacker could
learn the path length by messing with different per-hop payloads:
Hey CJP,
I am still not 100% through the SPHINX paper so it would be great if at
least another pair of eyes could lookt at this. However from the original
SPHINX paper I quote:
"Besides extracting the shared key, each mix has to be provided with
authentic and confidential routing information to
10 matches
Mail list logo
