Stepan Snigirev [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-26 📝 Original message: Hi Nadav, Nice proposal. ...
📅 Original date posted:2019-06-26
📝 Original message:
Hi Nadav,
Nice proposal. There are two suggestions that came to my mind:
1. In your proposal the encrypted data doesn't have any authentication. I
would suggest to use authenticated encryption and add HMAC-SHA256 at the
end of the encrypted data (encrypt-then-mac). Then even if insecure
connection is used to pass the encrypted data it cannot be changed by the
attacker.
2. Any node on the route of the payment knows the preimage and can decrypt
the data. It would be nice to tune the protocol in a way that only the
buyer can decrypt the data. For example we could use something like this:
Let's say Bob wants to buy data from Sally.
- Bob generates a random private key `b` and corresponding public key `B`.
Then he tells Sally what data he is interested in and also tells his public
key `B`
- Sally generates a random private key `s` and corresponding public key
`S`. She calculates a secret key `k=ECDH(B, S)`, encrypts the data with it
and sends encrypted (and authenticated) data to Bob.
- Sally generates the invoice with the preimage `S` (i.e. x-coordinate of
this point to make it 32-bytes long)
- When Bob pays this invoice he learns the value of the public key `S` and
can use his private key `b` to derive the encryption key `k=ECDH(B, S)`.
Bob can decrypt the data now.
- No one else learns the key.
Cheers,
Stepan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/e5363cb8/attachment-0001.html>
📝 Original message:
Hi Nadav,
Nice proposal. There are two suggestions that came to my mind:
1. In your proposal the encrypted data doesn't have any authentication. I
would suggest to use authenticated encryption and add HMAC-SHA256 at the
end of the encrypted data (encrypt-then-mac). Then even if insecure
connection is used to pass the encrypted data it cannot be changed by the
attacker.
2. Any node on the route of the payment knows the preimage and can decrypt
the data. It would be nice to tune the protocol in a way that only the
buyer can decrypt the data. For example we could use something like this:
Let's say Bob wants to buy data from Sally.
- Bob generates a random private key `b` and corresponding public key `B`.
Then he tells Sally what data he is interested in and also tells his public
key `B`
- Sally generates a random private key `s` and corresponding public key
`S`. She calculates a secret key `k=ECDH(B, S)`, encrypts the data with it
and sends encrypted (and authenticated) data to Bob.
- Sally generates the invoice with the preimage `S` (i.e. x-coordinate of
this point to make it 32-bytes long)
- When Bob pays this invoice he learns the value of the public key `S` and
can use his private key `b` to derive the encryption key `k=ECDH(B, S)`.
Bob can decrypt the data now.
- No one else learns the key.
Cheers,
Stepan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/e5363cb8/attachment-0001.html>