Published on: 2021-12-20T16:06:41+00:00
In a recent email exchange, Joost Jager, fiatjaf, and Peter Todd discussed the implementation of sender authentication in Lightning. Fiatjaf suggested using the lnurl-rfc repository to add identification information in BOLT11 payment requests, which can include a lone pubkey, domain-specific pubkey with a signature, or an unauthenticated name/email. Joost expressed concerns about privacy implications, but fiatjaf clarified that the signature method does not compromise privacy due to the specific key generation process. In another email exchange between Joost and Peter, Joost proposed a solution for sender authentication within the Lightning protocol without using an additional channel. However, Peter argued that once a secure channel is established, diffie-hellman is unnecessary and sender authentication can be achieved through providing payment information. Peter also warned against creating the ability to prove payment details to third parties, citing potential issues with government raids. Joost mentioned that routing nodes already learn pre-image hash, but this is addressed by the payment secret included in the invoice.The discussion continued with fiatjaf, Peter, and Joost exploring a temporary solution for adding more information to BOLT11 payment requests. The lnurl-rfc repository was identified as a source of a solution, specifically in its 18th file. This involved including a lone pubkey, domain-specific pubkey with a signature, or an unauthenticated name/email within the payment request using the 'h' tag. Privacy concerns were raised regarding the use of signatures, as they could potentially allow receivers to prove payments to third parties. Peter pointed out that Lightning already provides sender authentication through pre-image hash over authenticated channels. Joost clarified his preference for a protocol-based solution without an additional channel and proposed using diffie-hellman to generate a shared secret, rendering proofs useless to third parties.Joost Jager sought opinions on implementing opt-in sender authentication in Lightning. He emphasized the need to protect sender identity while allowing certain use cases. However, Peter Todd highlighted that Lightning already provides sender authentication through pre-image hash over authenticated channels and going beyond this could lead to serious problems. Joost's inquiry was shared on the Lightning-dev mailing list to gather technical insights on implementing opt-in sender authentication with considerations for cryptographic authentication and non-repudiation.Sender authentication is not mandatory in the Lightning network, but there are scenarios where it can be useful. For example, in chat over lightning, knowing the sender of a message is important. To address this, a custom record containing an ECDSA signature over `sender | recipient | timestamp | msg` has been added to whatsat, a chat protocol on Lightning. Sender authentication can also benefit regular payments, particularly for donations where donors may want to reveal themselves. Additionally, sender authentication offers a field for retrieving lost payment information and enhances protection for receivers, enabling invoices locked to specific source nodes. However, the current method using an ECDSA signature has limitations in terms of non-repudiation and data reuse risks. Joost suggested an alternative approach involving deriving a shared secret using ECDH with sender and receiver node keys and attaching a custom record with the sender node key and an HMAC of the payment hash. Joost sought expert opinions on the best technical implementation for sender authentication considering cryptographic aspects.
Updated on: 2023-07-31T23:58:56.841722+00:00