📅 Original date posted:2019-07-04
📝 Original message:
Hey Alex,
I think the benefit here is in reducing the client-server interaction for
REST apis while still ensuring payment to the merchant.
Let's assume that we don't have this scheme, and want to provide a
monetized REST API. The workflow looks like this, which is similar to what
our behavior is now at Suredbits with websockets
<https://suredbits.com/ws-playground/>;.
1. Client sends request to server for invoice
2. Server returns invoice
3. Client pays invoice
4. Server sends data back, or client makes request _again_ to a server and
then server returns data
With Nadav's scheme this is simplified to
1. Client sends request to server
2. Serves returns invoice, and encrypted payload
3. Client pays invoice
4. Client decrypts data according to Nadav's scheme
This saves a round trip between the server and client. It also gives
atomicity to the transaction, although as you stated before there is no
guarantees about integrity of the encrypted data. This is generally a hard
problem to solve in the technical sense, but I think the reputational harm
of the server sending bad data will be enough to prevent this, who wants to
do business with some one that isn't providing the advertised service? This
is a interaction that is could be repeated thousands of times on a daily
basis.
-Chris
On Thu, Jul 4, 2019 at 5:18 PM Alexander Leishman <leishman3 at gmail.com>
wrote:
> Nadav,
>
> This is an interesting proposal, but because this still requires the
> customer to trust the merchant, I am concerned that it adds complexity
> without any meaningful guarantee to the customer. Perhaps it makes sense to
> at least include some extension field here that allows the merchant to
> include a ZKP for ZKCP-compatible data transfers? However, there are a number
> of limitations <http://stevengoldfeder.com/papers/ZKCSP.pdf>; to consider
> with those.
>
> My two cents, is that the proposed standard would only be useful for the
> edge case where a customer wants to pre-download the data before paying,
> but still trusts the merchant. What's the main use you see for that? My gut
> tells me there's a higher-level abstraction here to be standardized that
> would handle more mainstream use-cases.
>
> ZmnSCPxj,
>
> > Putting MAC inside the encryption would help ensure that we can detect
> data replacement over insecure channel, and use of shared secret ensures
> only intended recipient can decrypt.
>
> Generally you want to MAC the ciphertext + IV, otherwise you lose
> ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
>
> -Alex
>
>
> On Wed, Jun 26, 2019 at 4:55 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Nadav et al.,
>>
>> > > 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:
>> >
>> > Is this not covered by sending over the pre-image encrypted data over a
>> secure channel such as HTTPS? If anyone along the route who learns the
>> pre-image does intercept the message with the encrypted data, that data
>> will already be encrypted for the intended recipient right?
>>
>> True, but the added protection allows sending the option of sending data
>> over a non-secure channel.
>> In particular, a secure channel like HTTPS would impose an
>> encryption/decryption overhead, and then you will *also* encrypt/decrypt at
>> the application layer i.e. you are encrypting twice.
>> If you have the choice of using an insecure channel, you could take that
>> and only have the encrypt/decrypt overhead only for the preimage-encrypted
>> data.
>>
>> i.e. with this, you have the option of sending over both secure and
>> insecure channels.
>> It does not hinder use of secure channel, but enables use of insecure
>> channel.
>> Putting MAC inside the encryption would help ensure that we can detect
>> data replacement over insecure channel, and use of shared secret ensures
>> only intended recipient can decrypt.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/20190704/f54ee691/attachment-0001.html>;
Chris Stewart [ARCHIVE] /
npub1u0…dnn03
2023-06-09 12:55:23
in reply to nevent1q…c5yx
Author Public Key
npub1u03cz099kt69z9awg232rjvlt34azukpzkkvy5uqv64dj9j5fqtshdnn03Published at
2023-06-09 12:55:23Event JSON
{
"id": "d63f1861db5ebc900a494fb5500b728bd249c0386d028deb8e63a26b3bea64c0",
"pubkey": "e3e3813ca5b2f45117ae42a2a1c99f5c6bd172c115acc2538066aad916544817",
"created_at": 1686315323,
"kind": 1,
"tags": [
[
"e",
"0aa1d4f0bb44069d397812365349dcb5b221b8adf367921d153427e592da9028",
"",
"root"
],
[
"e",
"3c6b0cb038429de4d7247cab51de5af3d53ee0d6140bb4a7357c5ecbd92663db",
"",
"reply"
],
[
"p",
"1af361caff60ad33901afe7b3c1823449af9239be002d54e242d4632baae6813"
]
],
"content": "📅 Original date posted:2019-07-04\n📝 Original message:\nHey Alex,\n\nI think the benefit here is in reducing the client-server interaction for\nREST apis while still ensuring payment to the merchant.\n\nLet's assume that we don't have this scheme, and want to provide a\nmonetized REST API. The workflow looks like this, which is similar to what\nour behavior is now at Suredbits with websockets\n\u003chttps://suredbits.com/ws-playground/\u003e.\n\n1. Client sends request to server for invoice\n2. Server returns invoice\n3. Client pays invoice\n4. Server sends data back, or client makes request _again_ to a server and\nthen server returns data\n\nWith Nadav's scheme this is simplified to\n\n1. Client sends request to server\n2. Serves returns invoice, and encrypted payload\n3. Client pays invoice\n4. Client decrypts data according to Nadav's scheme\n\nThis saves a round trip between the server and client. It also gives\natomicity to the transaction, although as you stated before there is no\nguarantees about integrity of the encrypted data. This is generally a hard\nproblem to solve in the technical sense, but I think the reputational harm\nof the server sending bad data will be enough to prevent this, who wants to\ndo business with some one that isn't providing the advertised service? This\nis a interaction that is could be repeated thousands of times on a daily\nbasis.\n\n-Chris\n\nOn Thu, Jul 4, 2019 at 5:18 PM Alexander Leishman \u003cleishman3 at gmail.com\u003e\nwrote:\n\n\u003e Nadav,\n\u003e\n\u003e This is an interesting proposal, but because this still requires the\n\u003e customer to trust the merchant, I am concerned that it adds complexity\n\u003e without any meaningful guarantee to the customer. Perhaps it makes sense to\n\u003e at least include some extension field here that allows the merchant to\n\u003e include a ZKP for ZKCP-compatible data transfers? However, there are a number\n\u003e of limitations \u003chttp://stevengoldfeder.com/papers/ZKCSP.pdf\u003e to consider\n\u003e with those.\n\u003e\n\u003e My two cents, is that the proposed standard would only be useful for the\n\u003e edge case where a customer wants to pre-download the data before paying,\n\u003e but still trusts the merchant. What's the main use you see for that? My gut\n\u003e tells me there's a higher-level abstraction here to be standardized that\n\u003e would handle more mainstream use-cases.\n\u003e\n\u003e ZmnSCPxj,\n\u003e\n\u003e \u003e Putting MAC inside the encryption would help ensure that we can detect\n\u003e data replacement over insecure channel, and use of shared secret ensures\n\u003e only intended recipient can decrypt.\n\u003e\n\u003e Generally you want to MAC the ciphertext + IV, otherwise you lose\n\u003e ciphertext integrity guarantees. Why do you want to MAC, then encrypt?\n\u003e\n\u003e -Alex\n\u003e\n\u003e\n\u003e On Wed, Jun 26, 2019 at 4:55 PM ZmnSCPxj via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Good morning Nadav et al.,\n\u003e\u003e\n\u003e\u003e \u003e \u003e Any node on the route of the payment knows the preimage and can\n\u003e\u003e decrypt the data. It would be nice to tune the protocol in a way that only\n\u003e\u003e the buyer can decrypt the data. For example we could use something like\n\u003e\u003e this:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Is this not covered by sending over the pre-image encrypted data over a\n\u003e\u003e secure channel such as HTTPS? If anyone along the route who learns the\n\u003e\u003e pre-image does intercept the message with the encrypted data, that data\n\u003e\u003e will already be encrypted for the intended recipient right?\n\u003e\u003e\n\u003e\u003e True, but the added protection allows sending the option of sending data\n\u003e\u003e over a non-secure channel.\n\u003e\u003e In particular, a secure channel like HTTPS would impose an\n\u003e\u003e encryption/decryption overhead, and then you will *also* encrypt/decrypt at\n\u003e\u003e the application layer i.e. you are encrypting twice.\n\u003e\u003e If you have the choice of using an insecure channel, you could take that\n\u003e\u003e and only have the encrypt/decrypt overhead only for the preimage-encrypted\n\u003e\u003e data.\n\u003e\u003e\n\u003e\u003e i.e. with this, you have the option of sending over both secure and\n\u003e\u003e insecure channels.\n\u003e\u003e It does not hinder use of secure channel, but enables use of insecure\n\u003e\u003e channel.\n\u003e\u003e Putting MAC inside the encryption would help ensure that we can detect\n\u003e\u003e data replacement over insecure channel, and use of shared secret ensures\n\u003e\u003e only intended recipient can decrypt.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190704/f54ee691/attachment-0001.html\u003e",
"sig": "7ec1f84afa0ae2e2e9bdc67b74c3fd4349b9bcb3737eb321a18285c58ceb1ab3eba3ce44a8e11a946f87e6b1f426f3bf328d7dfc6b821dbf7792da1ff3c7e68a"
}