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

[ZmnSCPxj via Lightning-dev]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Chris Stewart]

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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] [RELEASE] c-lightning v0.7.1: The Unfailing Twitter Consensus Algorithm

[Rusty Russell]

This is a recommended upgrade!

https://github.com/ElementsProject/lightning/releases/tag/v0.7.1

We're pleased to announce c-lightning 0.7.1, named by new C-Lightning
Core Team member Lisa Neigut.

Highlights for Users


o Gossip (both serving to others and listchannels) is much faster and
   uses much less memory.
o Infrastructure to fund a channel from an external wallet (probably
   needs a plugin to make it user friendly).
o listpeers now show how many confirms until channel is open.
o Ability to set a minimum channel size to accept.
o Invoices now default to 7 days, rather than 1 hour.
o fundchannel can now specify exactly what utxos to use, if you want
   coin control.
o Various JSON API corner cases and bugs have been removed, more
   information added.
o Lots of new plugin hooks to play with; we expect some more impressive
   plugins soon!

Highlights for the network
--
o We no longer ask every peer for all the gossip which ever happened!
o We respect and enforce option_upfront_shutdown_script (mainly for Eclair)
o We no longer allow tiny 1000 satoshi channels: default minimum is now
   10,000 satoshis.
o Improved compatibility with corner cases for both lnd (esp. older
   versions) and Eclair.

More details can be found in
https://github.com/ElementsProject/lightning/blob/v0.7.1/CHANGELOG.md.

Contributions
-

We've seen a lot more contributions and bug reports coming in: please
keep them coming!

Since 0.7.0 we've had 591 commits from 31 different authors, with a
record 12 first-time contributors!

@trueptolemy
@darosior
@andrewtoth
Joe Netti
Jeff Vandrew Jr
Billy Garrison
@thestick613
Lawrence Nahum
Kristaps Kaupe
Hampus Sjöberg
@dlogemann
Atis Elsts

Cheers,
Rusty, Christian, ZmnSCPxj and Lisa.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [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  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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev