Streamr integrates Lit Protocol

An integration to Lit Protocol has been added to the latest Streamr light node (v. 8.x onwards) and Broker node (v. 33.x onwards).

Lit Protocol is a network for decentralized cryptography. It can perform a number of useful functions related to cryptographic keys and related computations using threshold cryptography.

In Streamr, Lit Protocol is now used to enable historical data to be decrypted even after a publisher has gone offline and disappeared from the network. Publishers can store encryption keys to the Lit Network, and subscribers can retrieve them according to access control policies set in the Streamr smart contracts.

In the following, we’ll dive deeper into how the ‘online’ key exchange on Streamr works, what problem arises from it, and how Lit helps solve that problem by enabling ‘offline’ key exchange.

Online key exchange

First, let’s look at how key exchange on Streamr works without Lit enabled:

• A publisher publishes an encrypted message.
• A subscriber sees the encrypted message, and requests a decryption key from the publisher.
• The publisher sees the request, checks that the subscriber has access to the stream according to the Streamr smart contracts, and responds to the subscriber with the key.
• The subscriber receives the key and can then decrypt the message.

This is the normal online key exchange mechanism present in the Streamr Network since a long time, and it works fine as long as the publisher stays online (i.e. ‘live’) in the network in order to answer key requests. This is usually not an issue when dealing with realtime data: Most publishers publish new data continuously, and they naturally stay online for that reason, which also enables them to answer key requests from subscribers.

The problem

While the above key exchange mechanism works well for realtime data, it can become a problem with stored, historical data. Let’s look at an example:

• Again, a publisher publishes an encrypted message, and the data gets stored in encrypted form at a storage node.
• Later a subscriber joins the network, but by this time the publisher has gone offline.
• The subscriber retrieves the historical data from a storage node, but like before, needs the key to decrypt it.
• The subscriber sends a key request to the publisher like before, but the publisher is nowhere to be found, and there is no answer.
• The subscriber is therefore unable to decrypt and access the data.

For a real-world example, imagine what this might mean for thechat.app, a decentralized chat application that uses Streamr. In public chat rooms, everything’s fine because encryption is not needed. In private rooms, everything’s fine as long as the sender of a message is still online when you first see the message. But if the message was sent a while back, chances are that the sender has gone offline, meaning that you won’t be able to perform key exchange and see the content of their message.

Similarly, in a data monetization use case, it can easily happen that historical data purchased years after it was created is no longer accessible because the data publishers are no longer online.

Key storage and retrieval using Lit

Now, to solve the above fundamental issue with stored data, Streamr uses Lit as follows:

• Before publishing any data, the publisher stores the encryption key onto the Lit network. The key is encrypted and stored on Lit in a distributed way where decryption shares from 2/3rds of Lit nodes are required to retrieve the original key.
• As part of storing the key, the publisher also declares an access control policy: “this key may be retrieved by whoever has permission to subscribe to this stream according to the Streamr smart contracts”.
• The publisher then encrypts a message with the key, publishes it, and at some point goes offline.

• The subscriber later joins, fetches the stored encrypted message from storage, and sees that it’s encrypted with a key stored on Lit.
• The subscriber requests the key from a set of Lit nodes. Each contacted Lit node programmatically evaluates the access policy set by the publisher (i.e. checks that the subscriber has permission to access the stream according to the smart contracts), and if successful, gives the subscriber a decryption share.
• As long as the subscriber successfully obtains decryption shares from 2/3rds of Lit nodes, the subscriber is able to recover the key and use it to decrypt the data.

Activating the Lit integration

Given that Lit Protocol is still in beta and working towards decentralization, the integration is not yet activated by default in Streamr. As soon as the Lit network is more mature, the integration will be turned on by default in future versions of Streamr nodes. In the meanwhile, if you wish to use Lit with your Streamr applications, you need to add the following to your node config for both publishers and subscribers.

When using streamr-client a.k.a. Light node:

const streamr = new StreamrClient({
    ...
    encryption: {
        litProtocolEnabled: true
    }
})

Or similarly, when using a Broker node, in the Broker config file:

{
    ...
    "client": {
        "encryption": {
            "litProtocolEnabled": true
    	   }
    }
}

Applicability

As mentioned before, when subscribing to realtime data the publisher is usually online and can answer requests, and public streams don’t have a problem either as the data is not encrypted. However, in the case of encrypted historical data, Lit protocol helps a lot:

We love a good discussion about the technical aspects of the Streamr Network, so in case you have any questions or comments about this integration or anything else Streamr, make sure to join the project Discord and ask away!