📅 Original date posted:2019-06-25 📝 Original message: Good morning Nadav, I have had a similar idea (although without any details as to algorithm). However, it seems to me that the data seller is trusted to actually encrypt the data honestly (rather than, say, encrypting bytes from `/dev/random`). On the other hand, this is a good way to obsolete many "data-monetization" permissioned blockchains such as datapace, thus I approve. (and datapace does not solve the "really encrypting `/dev/random`" problem anyway) Regards, ZmnSCPXj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, June 26, 2019 12:54 AM, Nadav Kohen <nadav at suredbits.com> wrote: > Hi all, > > There are many applications that sell some form of data to users (e.g. a blog post, a game, live data, etc.) monetizing with Lightning. This data transfer can (and often should) be made atomic with the payment for that data using the payment pre-image. This basically entails responding to any request for data with an invoice and data that is encrypted with that invoice's payment pre-image; thus ensuring that the user gets the data if and only if they successfully pay that invoice over the lightning network. This scheme is already in use in real applications and will likely be further adopted as more lapps emerge. It would be beneficial to have an industry standard that would allow for the creation of uniform libraries for standard ln-encryption and ln-decryption. > > We propose the use of AES encryption in CFB mode with no padding to plaintext. AES encryption is a widely used standard that has libraries available for most platforms and languages. CFB mode allows the encryption of arbitrary sized plaintexts, allowing us to avoid any logic for padding/unpadding. Note that with AES in CFB mode you need to provide an initialization vector (IV), and this IV must be random for every encrypted plaintext.  > > A data provider should respond to requests for data over a secure channel (e.g. HTTPS) with the requested data encrypted by the payment pre-image using AES in CFB mode. Encrypting with the pre-image ensures that the user only receives the data they pay for and sending over a secure channel ensures no one else who knows the pre-image receives the data. > > When encrypting with the preimage, any pre-image that is 16, 24 or 32 bytes will work.  > > After encrypting the desired data with the payment pre-image, serialize the encrypted data by prepending the IV to the encrypted data, and then convert the sequence of bytes to a base64 string. This final base64-encoded string can be sent over the wire to the user (securly). Since the IV is a fixed-length 16 byte prefix, deserializing the base64 string is simply a matter of converting the base64 string to a sequence of bytes, setting the IV to the first 16 bytes and the ciphertext to the rest.  > > Optimizations: > > Once the payment has been received by the data provider, they may offer the payment preimage directly to the data recipient if there is a communication channel to the user (say over a websocket). The data provider can also simply make the payment pre-image publicly available, e.g. via a public API. This is done to provide for a better user experience by reducing latency as well as reducing the amount of communication a lapp client must have with a lightning node. > > Reference implementations: > > - JavaScript, using the Crypto-JS library: gist.github.com/torkelrogstad/4611d73567cdcbc40d1da144169c9b03 > > - Python, using the Pycrypto library: gist.github.com/torkelrogstad/9f57c9ec2f14322a9c1ce0a863f4ad50 > > - Java/Scala: github.com/torkelrogstad/bitcoin-s/blob/21f69158de361349a3ef1abe6f94f042af144ea9/core/src/main/scala/org/bitcoins/core/crypto/AesCrypt.scala > > > Acknowledgments: > > - Thank you to Alex Bosworth for sharing this idea with us and having a working implementation of this scheme at yalls.org > > - Thank you to Torkel Rogstad for the encryption details and reference implementations > > > Best, > Nadav