From leishman3 at gmail.com Thu Jul 4 22:17:41 2019 From: leishman3 at gmail.com (Alexander Leishman) Date: Thu, 4 Jul 2019 15:17:41 -0700 Subject: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard In-Reply-To: <6PgxMyjEYZud19u1UhWKlsIFv5Ot4za74OMjq9WmavgvRrD14PhHcwDNEh8OKFuZHY7DluUhnFxPK09rMJznsD_dINcnjp9c9Z2A5Xr7s4A=@protonmail.com> References: <0u_HlmMVZWjK1afW8GB8O1JebkgPhK1fZNq7HShS1Ow6EafwkWWNX4VSjSPEddwnzkY7R9NvnVlxfGHt7JV0YYkhs5ZDJqvd_3ueT1w1ocA=@protonmail.com> <6PgxMyjEYZud19u1UhWKlsIFv5Ot4za74OMjq9WmavgvRrD14PhHcwDNEh8OKFuZHY7DluUhnFxPK09rMJznsD_dINcnjp9c9Z2A5Xr7s4A=@protonmail.com> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: