From chris at suredbits.com Fri Jul 5 00:37:19 2019 From: chris at suredbits.com (Chris Stewart) Date: Thu, 4 Jul 2019 19:37:19 -0500 Subject: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard In-Reply-To: References: <0u_HlmMVZWjK1afW8GB8O1JebkgPhK1fZNq7HShS1Ow6EafwkWWNX4VSjSPEddwnzkY7R9NvnVlxfGHt7JV0YYkhs5ZDJqvd_3ueT1w1ocA=@protonmail.com> <6PgxMyjEYZud19u1UhWKlsIFv5Ot4za74OMjq9WmavgvRrD14PhHcwDNEh8OKFuZHY7DluUhnFxPK09rMJznsD_dINcnjp9c9Z2A5Xr7s4A=@protonmail.com> Message-ID: 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 . 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 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 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: