Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-17 📝 Original message: Hello list, In Lightning ...
📅 Original date posted:2021-12-17
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/cdda3204/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/cdda3204/attachment.html>;