# Timelock Encryption

# What is it?

Timelock encryption is a way of encrypting something now that cannot be decrypted until a future time has been reached. Previous attempts at practical timelock encryption have involved using either a trusted third party to store keys or proof of work (opens new window), requiring users to perform computation until they can decrypt a ciphertext.
Proof of work has proven ineffective in the face of improved hardware and computational science, as well as wasting a lot of energy.
Using a trusted third party does not have the same pitfalls, however the security model relies on having a third party you can trust and hoping that they don't get breached!

Since the launch of our unchained scheme (opens new window), drand has supported a new paradigm for enabling timelock encryption!
Fundamentally, drand is a reference clock: each drand round is mapped to a set time on the clock, and nodes in the network gossip their signature over that round number once the time has been reached. Each node can aggregate those signatures together to form a full randomness beacon, providing an attestation that a threshold number of nodes in the network believe that clock time has been reached.

In our timelock scheme, we have exploited identity-based encryption (opens new window) to allow users to create a ciphertext that uses the random value from a future round as a private key to decrypt it. Given the drand network will not release that randomness until the clock time has been reached (unless somehow a threshold of malicious nodes join the network and work together), this provides us accurate timelock encryption without wasting a large amounts of energy or trusting a single third party!
Additionally, this means that users can decrypt their timelock ciphertext offline, rather than requiring submission to a third party to do it for them.

# I don't have time to read all of this

# ⚠️ Security assumptions ⚠️

While our timelock scheme has been assessed for security issues by renowned security firm Kudelski Security (opens new window)[1], as with any cryptographic scheme, it's important to understand its limitations before you go and bet the farm on it! This is not an exhaustive list, and you ought to also read the drand security model (opens new window), but it's a good place to start.

  • there have never been a threshold of malicious nodes in the drand network

If there were, at any time, a threshold number of malicious nodes in the network, they could cooperatively generate all future random values and use them to decrypt arbitrary future timelock ciphertexts. drand randomness, while unpredictable, is entirely deterministic, even after the resharing of keys. That said, quicknet (our latest network compatible with timelock encryption) was started with 18 different organisations running in total 22 nodes for a threshold of 12, effectively eliminating any trusted third party and diluting trust in independent organisations that have no reason to collude with one another!

  • neither the scheme, nor drand are quantum resistant

The cryptography we employ does not use quantum resistant algorithms. If you timelock encrypt something for 1000 years and a viable quantum computer becomes available, they could decrypt it. Right now there are no widespread quantum resistant schemes for threshold IBE cryptography, but we're keeping an eye out for the future! To that end, consider it relatively safe to timelock encrypt something for 5-20 years depending on how bullish you are on quantum computing.

  • if the League of Entropy shuts down, members will delete their keys

The world is unpredictable (just like drand randomness... heh), and it's possible that the League of Entropy will all hang up their coats at some point in the future. Should that happen, members would have two choices with their private keys: release them to the world or delete them entirely. The former would mean that ciphertexts created for some time after the cessation of the network would be decryptable to everybody. The latter would mean that ciphertexts created for some time after the cessation of the network would be unencryptable forever (/until quantum computers can break them). In the interests of privacy, we felt the latter option was preferable. That said, if you encrypt the private key to your [insert cryptocurrency name] fortune to stop yourself from spending it now and the network stops... you're going to have a bad time.

[1] part of thei report is available in timelocked form here (opens new window), although it was encrypted using the drand testnet, so you will need to use the tlock go library (opens new window) to decrypt it by passing in the testnet details. We will be releasing the full report on our blog soon, as all the issues they identified have been remediated!

# Use cases

We have identified some cool use cases for timelock encryption, but these are certainly not exhaustive - hopefully you can come up with new, innovative use cases we haven't thought of!

If you can think of any more cool use cases, join the action on our slack channel and post them in the #drand-use-cases channel (opens new window) for discussion!

# The math bit 🤓

# Encryption

A client that wishes to encrypt a message only decryptable at the epoch will perform the following:

  1. Compute , the "round public key"

    • (this can be pre-computed per epoch, it's the same for everyone)

  2. Choose a random , "the mask"

  3. Set where is a secure hash function mapping to field elements, "the ephemeral secret key"

  4. Output the ciphertext where:

    , "the ephemeral public key"

    , "the mask commitment"

    , "the one-time pad"

NB. in the target group we use additive notation here, like in the groups and , the convention for pairings would typically use multiplicative notation in the target group, but we find it confusing rather than helpful.

# Decryption

A client that wishes to decrypt a ciphertext takes the associated signature of epoch and performs the following:

  1. Compute
  2. Compute
  3. Set
  4. Test that if not, reject
  5. is the corresponding plaintext

# Libraries available for timelock encryption

Listed below are various libraries and clients for using timelock encryption. Details on how to install and use them are available at the links provided.

tlock is a go CLI and library developed by Ardan Labs (opens new window) and maintained by the drand team for performing timelock encryption and decryption

tlock-js is a javascript library developed and maintained by the drand team for performing timelock encryption and decryption written in Typescript

dee is a rust CLI developed and maintained by Thibault Meunier from Cloudflare. It can perform timelock encryption and decryption, as well as retrieve beacons from any of the drand networks.

timevault is a web app for timelock encrypting and decrypting vulnerability reports for responsible disclosure as well as arbitrary text. It is developed and maintained by the drand team.

  • tlock-fvm

Timelock encryption and decryption will be available on the Filecoin Virtual Machine (opens new window) in the second half of 2023. Stay tuned to our blog for updates!

Last Updated: 12/20/2024, 9:24:51 AM