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

[Alexander Leishman]

Chris,

Thanks for that explanation. I could see how this makes sense for
lightweight data payloads because it reduces the round trip count, but I
agree with ZmnSCPxj that this could pose a DoS risk for larger data
payloads. This DoS risk is even more magnified for ZKCPs.

I would guess that APIs selling data for lightning payments might take
different approaches:

1. You could purchase an auth token upfront that allows you access for some
amount of time of some number of requests (seems to be the most efficient
for APIs that would be called more than once)
2. You could pay per request (good for when you would want 1 big blob of
data)

So for the case where a customer is calling the API multiple times per day,
wouldn't it make more sense to pay upfront for future requests?

Best,
Alex

Best,
Alex



On Thu, Jul 4, 2019 at 8:36 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Alexander,
>
> > > > 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?
>
> It is possible I simply misunderstand the proper use of MAC, so I shall
> research it in more depth.
>
>
> > 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.
>
> A client can easily DoS the server by requesting and requesting (thus
> convincing the server to encrypt and send data immediately) and never
> paying.
> Whereas the first would require more resources on the client side, as the
> server does not encrypt (or never encrypts at all) until the client has
> shown proof-of-payment.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190705/0b609eb3/attachment.html>