Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-06 📝 Original message: Corné Plooy <corne at ...

📅 Original date posted:2018-12-06
📝 Original message:
Corné Plooy <corne at bitonic.nl> writes:

>> 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.

That is correct, one is generated by the recipient (secret and preimage)
and the other one is generated by the sender (ephemeral key). Mixing the
two seems very unwise, since the sender has very little control over
what the effective ephemeral key that is going to be used for the last
hop. This is the same issue that we have with rendez-vous routing, i.e.,
that if we require the ephemeral key to be something specific at a given
node we'd be breaking the hardness assumption of for the ephemeral key
rotation.

> 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.

I can't quite follow where we would be mixing in the ephemeral key here,
could you elaborate on that?

> 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.

Since we have very little control over what ephemeral key will actually
be presented to the last hop if we have a multi-hop route, we can't
really hide any information in the ephemeral key itself. What we could
do is change the way the last hop generates the shared secret from it,
i.e., have a last hop mode and a forwarding hop mode, and mix in the
payment secret somehow, but I can't think of a good way to do that, and
it seems contorted. Let's just have the sender prove knowledge of the
original invoice by adding a TLV field with a shared secret from the
invoice instead.

Cheers,
Christian