Published on: 2018-12-06T15:24:20+00:00
In a conversation between Corné Plooy and Christian Decker, the issue of using the same payment hash and ephemeral key generation in the Lightning Network is discussed. They agree that mixing the two is unwise as it gives the sender little control over the effective ephemeral key used for the last hop. Path decorrelation is proposed as a solution to replace the payment hash/preimage part, coupled with the "H"TLC payment secret generation to avoid attacks. However, the use of rendezvous routing complicates matters. Instead, they suggest proving knowledge of the original invoice by adding a TLV field with a shared secret.The context introduces the concept of layer 0 and layer 1 in generating shared secrets between payer and payee. The payment hash and ephemeral key generation are unrelated, allowing an attacker to create a new onion packet around the same payment hash using their own ephemeral key pair. Path decorrelation and points+privkeys are suggested as alternatives to prevent such attacks. However, this method does not stop an attacker from testing whether the next node is the final hop.Rusty Russell suggests that the shared secret doesn't need to be large and proposes using the last four bytes of the signature. Christian Decker suggests storing the secret from the invoice in the HMAC field, which could complicate final hop checking but does not require a lockstep upgrade. The timing of this scheme is a concern, and it will only be useful once it becomes compulsory. Despite the uncertainty, Russell suggests implementing it since it is a simple solution.Corné Plooy shares concerns about an attack that can guess the final node in a payment route. To prevent this attack, he suggests including a shared secret in the onion message to the final node. The payee generates the shared secret and passes it to the payer as part of the invoice. The payer includes the shared secret in the per-hop data to the payee. This solution is an incremental improvement and does not require a large shared secret. The number of attempts per second to guess the shared secret is limited by network latency, bandwidth, and rate limiting.ZmnSCPxj suggests using path decorrelation and points+privkeys instead of hashes+preimages to prevent attacks on onion messages. This method involves giving each hop a random point to be added to the next SS "HTLC". The final node needs to be given the total of the scalars of each hop random point along the route. However, this method does not prevent an attacker from learning the point used in the direct neighbor hop.The conversation between CJP and ZmnSCPxj discusses including a shared secret in onion messages to prevent attacks. ZmnSCPxj suggests switching to path decorrelation and using points+privkeys instead of hashes+preimages. This method ensures that intermediate nodes cannot guess the shared secret, and the final node will give the same error message for incorrect scalar totals and "invoice hash"/invoice point errors.In summary, the discussions revolve around preventing attacks on the Lightning Network by including a shared secret in onion messages or switching to path decorrelation. The shared secret can be generated by the payee and passed to the payer as part of the invoice. Path decorrelation involves giving each hop a random point to be added to the next SS "HTLC", preventing intermediate nodes from guessing the shared secret. These solutions aim to enhance the security of the Lightning Network and protect against potential attackers.
Updated on: 2023-07-31T21:01:05.365505+00:00