Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-06 📝 Original message: > * layer 0 (to B): ...

📅 Original date posted:2018-12-06
📝 Original message:
> * 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