[Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

[Alexander Leishman]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190704/1713b5d3/attachment.html>