# 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
- here is our blog post announcing the new network and timelock encryption (opens new window)
- here is Yolan's talk at Real World Crypto (opens new window) on timelock encryption
- here is the paper on eprint (opens new window)
- here is our post about deprecating
fastnetin favor of the RFC-compliant
quicknet(opens new window)
# ⚠️ Security assumptions ⚠️
While our timelock scheme has been assessed for security issues by renowned security firm Kudelski Security (opens new window), 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.
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.
 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!
- responsible vulnerability disclosure (opens new window)
- transfer of assets/password upon death
- sealed bid auctions
- MEV prevention (opens new window)
- public turn-based games
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 🤓
A client that wishes to encrypt a message
, the "round public key"
- (this can be pre-computed per epoch, it's the same for everyone)
Choose a random
, "the mask"
where is a secure hash function, "the ephemeral secret key"
Output the ciphertext
where: , "the ephemeral public key" , "the mask commitment" , "the one-time pad"
A client that wishes to decrypt a ciphertext
- Test that
if not, reject 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
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.
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!