fiatjaf [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-18 📝 Original message: Good morning, Joost. As a ...
📅 Original date posted:2021-12-18
📝 Original message:
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 <joost.jager at gmail.com> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211218/014f1a00/attachment.html>;
📝 Original message:
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 <joost.jager at gmail.com> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211218/014f1a00/attachment.html>;