Skip to main content

Encryption and Access Control

info

The Datil-test and Datil-dev testnets are now live and are superseding the Manzano and Cayenne testnet respectively.

The Datil mainnet is now live and superseding the Habanero mainnet, ready to store real world assets.

Check out the migration docs to learn how you can start building on the Datil networks today.

Introduction​

You can use Lit for encryption to store data privately on the open web. The Lit network uses an identity-based encryption scheme, which means that decryption is only permitted to those who satisfy a certain pre-determined identity parameter.

Each Lit node holds a share of a shared BLS key. The signature from this BLS key serves as the decryption key for a particular set of Access Control Conditions and private data. The user will only be able to decrypt the data if they can prove that they satisfy the corresponding conditions.

Lit's encryption scheme is highly efficient, as encryption is entirely a client-side operation. Only one round of network interactivity (between the Lit nodes) is required for decryption in order to request the signature shares and assemble a decryption key.

The identity-based encryption scheme necessitates the construction of an identity parameter, and it is this parameter that the BLS network is producing signature shares over. In order to prevent the same network signature (decryption key) to be used for multiple distinct ciphertexts, we choose this identity parameter to be a combination of the hash of the Access Control Conditions and the hash of the private data itself.

Overview​

Here is a high-level, step-by-step breakdown of the encryption and decryption process with Lit:

Encryption​

  1. Alice starts by creating an Access Control Condition(s) and combines it with her private data to construct the identity parameter.
  2. Alice encrypts the private data and the identity parameter using the public key of the shared Lit BLS key to get a ciphertext.
  3. Alice stores the encryption metadata - the set of Access Control Conditions, hash of the private data etc. - and the ciphertext wherever she wants (for example, IPFS or Ceramic).

Decryption​

  1. Bob fetches the ciphertext and corresponding encryption metadata from the public data store.
  2. Bob presents the encryption metadata to the BLS network and requests for signature shares over the identity parameter.
  3. The Lit nodes check whether the user satisfies the Access Control Conditions before signing the constructed identity parameter.
  4. Bob assembles the signature shares into a decryption key and successfully decrypts the ciphertext.

Features and Examples​

Features​

  • Use state from most EVM chains, Cosmos, and Solana to create your conditions. Check out the full list of supported chains here.
  • Use AND + OR operators (boolean logic) can be used to combine any of the supported conditions listed above.
  • Lit works with any storage provider, which means you can use your preferred storage solution, such as IPFS, Arweave, Ceramic, or even a centralized provider, like AWS.

Examples​

Lit supports the use of both on and off-chain data when creating Access Control Conditions. Some examples include:

Getting Started​

You can get started with encryption following this quick start guide. Below, you'll find some additional resources and example implementations:

  1. Storing Private Data on ComposeDB
  2. Encrypting Onchain Storage Using Lit and Irys
  3. Basic EVM Conditions
  4. Access Control Using Off-Chain Inputs
info

Not finding the answer you're looking for? Share your feedback on these docs by creating an issue in our GitHub Issues and Reports repository or get support by visiting our Support page.