[Lightning-dev] Reason for having HMACs in Sphinx
corne at bitonic.nl
Thu Dec 6 11:51:30 UTC 2018
> * 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
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.
More information about the Lightning-dev