Christian Decker <decker.christ...@gmail.com> writes: > Rusty Russell <ru...@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.
Well, I think we're heading to a TLV mechanism for the onion "padding" anyway, so it works well there. The only problem with this scheme is timing: 1. It's only useful once it's compulsory, since an adversary can always just not use it (downgrade attack). 2. Will we be able to upgrade the network to make it compulsory before Schnorr and decorrelation make it irrelevant? I think it's a *maybe*, so I suspect we should Just Do It, since it's simple. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
