Re: [Lightning-dev] Payment sender authentication
Hi Joost, On Mon, Dec 20, 2021 at 5:02 AM Joost Jager wrote: > Hi fiatjaf and peter, > > On Sat, Dec 18, 2021 at 2:08 PM fiatjaf wrote: > >> As a temporary solution, I suggest taking a look at >> https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that >> you can either provide >> - a lone pubkey (to be used for manually identifying the payer later if >> necessary); >> - a domain-specific pubkey along with a signature of a challenge >> provided by the receiver; or >> - an unauthenticated name or email (for light things like donations for >> which one may not care very much about cryptographic authentication). >> And then you commit these things, whatever they are, inside the BOLT11 >> payment request using the 'h' tag. >> > > Interesting read. I see it uses a signature, but is that a good idea? It > could allow the receiver to prove to a 3rd party that the payment was made. > I guess it depends on the application if that is desired or not. The more > privacy conscious users would probably try to avoid committing to data via > a signature. > Just to clarify: For the lone pubkey method there are no privacy implications I think, since it's just a random pubkey and can be used later only if needed in some custom way. For the signature method the privacy implications are close to none (unless I'm missing something) because the key used to sign is (supposed to be) generated by a method that makes it specific to the DNS domain of the service being paid. Since this assumes an LNURL request that has a domain, the key will be generated with something like `HMAC(domain, seed_key)` (the specifics don't matter) so it will not be possible for anyone to relate that signature to anyone. Only the receiver service will be able to relate it to other payments (or logins) to that same exact service -- which can prove quite handy in many cases. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Payment sender authentication
On Mon, Dec 20, 2021 at 09:01:37AM +0100, Joost Jager wrote: > On Sat, Dec 18, 2021 at 6:56 PM Peter Todd wrote: > > > Lightning already has sender authentication: you simply give someone a > > pre-image hash over an authenticated channel, and the fact that the > > payment was > > made means only they could have realistically made it as they were the only > > person who knew that pre-image hash. > > > > This sounds quite similar to what is described above in lnurl-18. I can see > that that works, but I should have added that I was looking for a solution > that exists completely within the protocol without using an additional > channel. Also, routing nodes learn the preimage hash too, so the sender > isn't the only person. But that is solved by the payment secret that is > also part of the invoice. The key thing is the invoice has to get to the sender somehow in the first place. So I don't think there's any reason to use the lightning protocol itself for additional authentication. > > Going beyond that is dangerous as you're creating the ability to prove to a > > *third* party who made a particular payment. That raises serious problems > > in > > cases like government raids that need to be considered very carefully. > > > This is why I proposed to use diffie-hellman to generate a shared secret. > The receiver could then have made up all the proofs themselves and are > therefore of no value to a third party. The purpose of diffie-hellman is to generate a shared secret in the absense of a secure channel. Once you have a secure channel there's no reason to use it. Simply giving the sender the payment info is sufficient. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Payment sender authentication
Hi fiatjaf and peter, On Sat, Dec 18, 2021 at 2:08 PM fiatjaf wrote: > As a temporary solution, I suggest taking a look at > https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that > you can either provide > - a lone pubkey (to be used for manually identifying the payer later if > necessary); > - a domain-specific pubkey along with a signature of a challenge provided > by the receiver; or > - an unauthenticated name or email (for light things like donations for > which one may not care very much about cryptographic authentication). > And then you commit these things, whatever they are, inside the BOLT11 > payment request using the 'h' tag. > Interesting read. I see it uses a signature, but is that a good idea? It could allow the receiver to prove to a 3rd party that the payment was made. I guess it depends on the application if that is desired or not. The more privacy conscious users would probably try to avoid committing to data via a signature. On Sat, Dec 18, 2021 at 6:56 PM Peter Todd wrote: > Lightning already has sender authentication: you simply give someone a > pre-image hash over an authenticated channel, and the fact that the > payment was > made means only they could have realistically made it as they were the only > person who knew that pre-image hash. > This sounds quite similar to what is described above in lnurl-18. I can see that that works, but I should have added that I was looking for a solution that exists completely within the protocol without using an additional channel. Also, routing nodes learn the preimage hash too, so the sender isn't the only person. But that is solved by the payment secret that is also part of the invoice. > Going beyond that is dangerous as you're creating the ability to prove to a > *third* party who made a particular payment. That raises serious problems > in > cases like government raids that need to be considered very carefully. This is why I proposed to use diffie-hellman to generate a shared secret. The receiver could then have made up all the proofs themselves and are therefore of no value to a third party. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
