> * 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 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 total_decorrelation_secrets from k[a] + k[b] to > k[a] + k[z] instead. > The way things are now, the ephemeral key generation and the payment hash/preimage generation are completely unrelated. This is what allows an attacker to use the same payment hash, and use his own ephemeral key pair to create a new onion packet around it. Primarily, path decorrelation replaces the payment hash/preimage part. Maybe I still don't understand something, but if that's the only thing (without changing the ephemeral key / onion shared secret generation), attacking the direct neighbor should still work; in your case, B would still offer ((I + K[A]) + K[B]) to C, with an onion packet B created himself. I'm not familiar enough with the path correlation to understand what happens after step 6, but for C it looks the same, so she should do the same. I do see that, if you couple the "H"TLC payment secret generation to the onion shared secret generation, you can make the attack impossible. Do I understand correctly that this is the idea? After all, C still needs to receive k somehow; my crypto math isn't that good, but my intuitive guess is that i + k is the secret that allows C to claim funds locked in ((I + K[A]) + K[B]) =? (i + (k[a] + k[b])) * G. If k is submitted from A to C through some mechanism that replaces the current ephemeral key system, then I understand what you're at. Assuming this is the case, it's pretty neat. I do wonder how it interacts with rendezvous routing. If the sender and receiver each create the k[..] values for their own part of the route, can the receiver-generated onion packet still use points of the form ((I + K[A]) + K[B]), including K[..] values related to the sender side? I need to dig deeper into this path decorrelation idea. CJP _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev