How It Works
timelock.sh is a time-lock encryption oracle. Keys are generated in advance and released on schedule.
The Idea
timelock.sh lets you encrypt some file today that should only be readable after a specific time (like one week from now). You can give this encrypted file to anybody and guarantee that they won't be able to decrypt it until the time you specified when performing the encryption.
The way it works is that for every minute of the next month, timelock.sh publishes a public lock (an X.509 certificate, available immediately). When that minute arrives, timelock.sh then makes the corresponding secret key accessible.
To encrypt to a future minute, you fetch that minute's certificate and
run an openssl cms -encrypt (see docs)
or encrypt the file on this website. The resulting encrypted file embeds
which minute it's bound to, so the recipient doesn't need to know the
unlock time in advance. They (or anyone) can extract it from the file
once the time comes, fetch the released key, and decrypt.
Architecture
Encryption Format
The browser and CLI produce the same thing: a DER-encoded CMS
AuthEnvelopedData file. In OpenSSL terms, it is roughly:
openssl cms -encrypt \
-recip cert.pem \
-keyopt rsa_padding_mode:oaep -keyopt rsa_oaep_md:sha256 \
-aes-256-gcm \
-outform DER- Envelope
- CMS/PKCS#7
AuthEnvelopedData, as described by RFC 5083. - File key
- A fresh AES-256 key is generated for the file, then wrapped to the minute certificate with RSA-OAEP/SHA-256.
- Payload
- The file bytes are encrypted with AES-256-GCM, so tampering should fail during decrypt.
- Unlock minute
- Stored in the recipient certificate name inside the CMS structure. That is what lets the decrypt page know which released key to fetch.
The format is intentionally boring: OpenSSL can decrypt it after the key is public, and timelock.sh does not need its own file container.
Trust Model
- All encryption and decryption happens client-side — in your browser or via OpenSSL. Your files never touch the server.
- Private keys are encrypted at rest with a key-encryption-key (KEK) that only the worker has access to.
- The API server is read-only — it serves keys from the database but cannot release them early. It also enforces a server-side time check as defense-in-depth, refusing to serve private keys before their unlock time even if they exist in the database.
- Only the key worker process, running on a separate firewalled system, can decrypt and publish private keys on schedule.
- Once a key is released, it is permanent and public. It cannot be retracted.
Certificate Format
Each minute gets a self-signed X.509 certificate:
-
CN:
2026-04-15T14:30Z.timelock.sh— encodes the target minute - O: timelock.sh Oracle
- OU: unique key UUID
- Validity: 1-minute window (Not Before = T, Not After = T + 1 min)
- Key: RSA-2048
FAQ
How can I know you won't release keys early?
You can't. This is a trust-based oracle. Use at your own risk, but I will make a best effort to run this securely.
What type of encryption does this use?
It uses 2048 bit RSA encryption and x.509 certificates for the public keys. 4096 bit keys seem overkill due to the short term nature of the encryption.
How did you select these encryption standards?
I chose a standard that was OpenSSL compatible so that devs and agents can programmatically use this tool with zero dependencies.
What if the service goes down?
Encrypted data stays locked. Don't rely on timelock.sh as your only way to access critical data.
Can I encrypt to a past time?
Yes. The key is already released, so you can encrypt and immediately decrypt.
How far ahead can I encrypt?
Up to one month, about 30 days. Requests beyond the key horizon return 404.
Is my file uploaded?
No. Encryption and decryption happen entirely on your device. The server only provides keys.