Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-05 📝 Original message: Rusty Russell <rusty at ...
📅 Original date posted:2018-12-05
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> 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 secret will take (on
>> average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of
>> which node is the final node. In the mean time, people will have noticed
>> the ongoing attack and will have taken countermeasures. Besides, the
>> transaction lock time will likely have expired in the mean time as well.
>
> We could really just use the last 4 bytes of the signature, AFAICT.
A stupid idea came to mind that would allow us to use no more space in
the onion at all: store the secret from the invoice in the HMAC
field. That would complicate the final hop checking on the recipient to
either being all 0x00, or some known secret (could also use a partial
HMAC so we can reduce the number of lookups we need to do). Another
option is that we could XOR it with some other field as well. The
recipient already signaled that it supports this by including a secret
in the invoice in the first place anyway, so no need for a lockstep
upgrade either.
Just putting it out there, I'm still unsure if I like it at all, since
it mixes field purposes, but it is an option if we decide this is a
serious issue.
Cheers,
Christian
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> 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 secret will take (on
>> average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of
>> which node is the final node. In the mean time, people will have noticed
>> the ongoing attack and will have taken countermeasures. Besides, the
>> transaction lock time will likely have expired in the mean time as well.
>
> We could really just use the last 4 bytes of the signature, AFAICT.
A stupid idea came to mind that would allow us to use no more space in
the onion at all: store the secret from the invoice in the HMAC
field. That would complicate the final hop checking on the recipient to
either being all 0x00, or some known secret (could also use a partial
HMAC so we can reduce the number of lookups we need to do). Another
option is that we could XOR it with some other field as well. The
recipient already signaled that it supports this by including a secret
in the invoice in the first place anyway, so no need for a lockstep
upgrade either.
Just putting it out there, I'm still unsure if I like it at all, since
it mixes field purposes, but it is an option if we decide this is a
serious issue.
Cheers,
Christian