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
