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
Re: [Lightning-dev] Payment sender authentication
On Fri, Dec 17, 2021 at 11:37:12AM +0100, Joost Jager wrote: > Hello list, > > In Lightning we have a great scheme to protect the identity of the sender > of a payment. This is awesome, but there are also use cases where opt-in > sender authentication is desired. 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. 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. -- 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
Good morning, Joost. 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. fiatjaf On Fri, Dec 17, 2021 at 7:37 AM Joost Jager wrote: > Hello list, > > In Lightning we have a great scheme to protect the identity of the sender > of a payment. This is awesome, but there are also use cases where opt-in > sender authentication is desired. > > An example of such a use case is chat over lightning. If you receive a > text message, you generally want to know whom it originates from. For > whatsat [1], I added a custom record containing an ECDSA signature over > `sender | recipient | timestamp | msg`. I believe other chat protocols on > lightning use a similar construction. > > For regular payments however, sender authentication can be useful too. A > donation for example doesn't always need to be anonymous. A donor may want > to reveal themselves. In other cases, sender authentication can add a layer > of protection against payments getting lost. It provides the receiver with > another field that they can use to retrieve lost payment information. > > On the receiver side, sender authentication also creates new > possibilities. A receiver could for example create an invoice that is > locked to a specific source node. > > Also wanted to note that the sender identity doesn't need to be the actual > node identity. It can also be an unrelated key that could for example be > specific to the service that is being paid to. For example, one registers > the public part of a dedicated key pair with an exchange and the exchange > then only accepts deposits authenticated with that key. > > The reason for bringing this up on the list is that I wanted to see what > people think is the best way to do it technically. The whatsat approach > with an ECDSA signature doesn't look ideal to me because of the > non-repudiation property. Also care needs to be taken that whatever data > the sender includes, cannot be reused. > > Another option that I can think of is to derive a shared secret using ECDH > with the sender and receiver node keys and then attach a custom record to > the payment containing the sender node key and an HMAC of the payment hash > using the shared secret as a key. > > I am sure there people better versed in cryptography than me who have an > opinion on this. Thoughts? > > Joost > > [1] https://github.com/joostjager/whatsat > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
