Cryptographic Time-delay Engine
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.gitignore
README.md
conf
futord.py
futors.py
openssl.py

README.md

Futorcap: the cryptographic time-delay engine

Futorcap is a delay-based trusted key escrow system which makes it possible to encrypt data using a key which will not be available until a certain time in the future. The use cases may include sending bitcoins to a person in the future, releasing a large data file which must be made available to a large number of people at exactly the same time, or sending a message to someone which you do not want them to read until a certain date.

In a typical expected use case, a third party will maintain a secure "trusted platform device". In my reference implementation, this is a raspberry pi sealed in a plastic box. This device runs an instance of futord and futors, which generates, signs, and releases public and private keys on a strict schedule. For example, futord could be set up to generate keys at an interval of one hour, and a period of one week. This means that futord would start by generating one week's worth of keypairs, with privkey release timestamps spaced an hour apart, and releasing all the pubkeys. After an hour, it would release the first private key and generate another keypair with the pubkey to be released immediately and the privkey to be released a week in the future. Under normal operation in this configuration, there should always be one week's worth of pubkeys available with unreleased privkeys. This key generation and release process will be repeated every hour until the service is put into end-of-life mode, at which time it will stop generating new keypairs and continue to release the privkeys for existing pubkeys on schedule until both halves of all keypairs are published.

But marcusw, trust sucks!

I agree. However,

The premises of futorcap are:

  1. No purely cryptographic primitive can make it possible to encrypt data until a certain date.
  2. Using principles outlined in Meredith L. Patterson's Science of Insecurity talk, it is possible to create a network-connected service which is provably secure.
  3. Erasure coding and X-of-Y trust systems allow users to distribute trust over a pool of independent operators.

Conclusions:

  1. A non-cryptogrphic primitive is required. This requires trusting a third party.
  2. Using secured hardware, minimal attack surface, and non-turing-complete protocols with carefully implemented validation routines, it is possible to run a service with full confidence that it will not be compromised at a technical level.
  3. By locating futorcap trusted platform devices over a number of spheres of influence, and using an erasure coding system which relies on, for example, 3 of 5 keys from a pool of semi-trusted futorcap devices, it is possible place reasonable trust in the system to behave as expected. This functionality is considered user-side and is not implemented by futorcap.

Setup

Clone git, edit conf, run futord.py. This project uses python 3. The reference openssl keygen requires an openssl binary on your $PATH.

Usage

To encrypt and decrypt data using the keys generated by futord, fetch them either using futors (implementation in progress) or from the pub/ directory using ftp, http, or whatever other file transfer protocol you prefer. Each type of key (openssl, gpg, etc.) has its own subdirectory of pub/ which contains the published keys and a README with instructions for encrypting and decrypting using their corresponding software package.