From corne at bitonic.nl  Thu Dec  6 11:51:30 2018
From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=)
Date: Thu, 6 Dec 2018 12:51:30 +0100
Subject: [Lightning-dev] Reason for having HMACs in Sphinx
In-Reply-To: <t8q3WtGOv2IhdS3RwMXEMBtbM6tsS-i8nawjC1rwu7JjnmuRuPBhqJQnjjAJ9tTLve_Ps7Hr5TSTVNqwkPkxJeZP0PmelwT47uKkUjhyf-8=@protonmail.com>
References: <fd770fa8-4044-6953-1d3c-e9e461c31661@bitonic.nl>
	<87a7lrreme.fsf@gmail.com>
	<2f0a233e-d751-f7d9-3ad5-38cae19559de@bitonic.nl>
	<tKOQS9kVgLdkXw1UQ5aXvyaB6GnoYgL7DFByxcLKW2yquax6eMZlSOY1Sb6lL1teH6Oi8nfL7UYd_OA0TL9jHH-0VmRb7rbYlO3ywZTxvys=@protonmail.com>
	<59ff9858-baf7-c4e7-0c10-245ef4578b43@bitonic.nl>
	<t8q3WtGOv2IhdS3RwMXEMBtbM6tsS-i8nawjC1rwu7JjnmuRuPBhqJQnjjAJ9tTLve_Ps7Hr5TSTVNqwkPkxJeZP0PmelwT47uKkUjhyf-8=@protonmail.com>
Message-ID: <d2c6f609-77bc-3a5f-fdc2-920e9a3f131c@bitonic.nl>


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