📅 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:53:21
in reply to nevent1q…ccaq
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:53:21Event JSON
{
"id": "6c35cfb1da22e9929a8234b61bad5cc3bfc16dd4838d0f2ee19baace2c07d29f",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315201,
"kind": 1,
"tags": [
[
"e",
"2fcb445dd574564835b2068c030ba4e556383d5b915eb5763f6fba62ac8aa302",
"",
"root"
],
[
"e",
"1377b271e3d2133aeb0d5e946e6c1a1d87daa52435196d269668de49c5d0e420",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-12-05\n📝 Original message:\nRusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e\u003e The shared secret doesn't need to be very large: the number of attempts\n\u003e\u003e per second (to guess the shared secret) is limited by network latency,\n\u003e\u003e bandwidth and maybe some artificial rate limiting. If an attacker can do\n\u003e\u003e 100 attempts per second, then a 32-bit shared secret will take (on\n\u003e\u003e average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of\n\u003e\u003e which node is the final node. In the mean time, people will have noticed\n\u003e\u003e the ongoing attack and will have taken countermeasures. Besides, the\n\u003e\u003e transaction lock time will likely have expired in the mean time as well.\n\u003e\n\u003e We could really just use the last 4 bytes of the signature, AFAICT.\n\nA stupid idea came to mind that would allow us to use no more space in\nthe onion at all: store the secret from the invoice in the HMAC\nfield. That would complicate the final hop checking on the recipient to\neither being all 0x00, or some known secret (could also use a partial\nHMAC so we can reduce the number of lookups we need to do). Another\noption is that we could XOR it with some other field as well. The\nrecipient already signaled that it supports this by including a secret\nin the invoice in the first place anyway, so no need for a lockstep\nupgrade either.\n\nJust putting it out there, I'm still unsure if I like it at all, since\nit mixes field purposes, but it is an option if we decide this is a\nserious issue.\n\nCheers,\nChristian",
"sig": "86ec29d1b452ffca00310a0fc2c870edd652f6ef49ffa9c22c601b71e3bb14295f66cf49cebf109151392c15e30fada51799cb2276e8efb3c6d45b4cf7cca3e6"
}