Bitcannery

What 's Bitcannery?

The main idea is to store message in the blockchain, but encrypt it so neither Bob nor anyone else could read it before trigger event and only Bob could after that event. As all the data in blockchain is open to read for anyone, we need to encrypt message at least two times: first to prevent anyone but Bob to read it (use asymmetric crypto), second to prevent Bob from accessing his message before trigger event. To open the message after trigger event, Bitcannery uses a network of keepers agents with access to parts of the decryption key. The key is divided with Shamir's secret sharing method, so we don't need every single key part to be able to decrypt Bob's message. After saving encrypted key partsand twice-encrypted message to blockchain smart contract, Alice performs canary checkins within predefined time interval. After missed Alice's checkin keepers decrypt their key parts and send them to smart contract. Once enough keepers had revealed their key parts, Bob restores decryption key from keepers' shards, and then decrypts message from smart contract twice, receiving the Alice's message.

Note that Bitcannery could be used for both timed-out message delivery and dead-man-switch-like mechanics. The main difference would be trigger event for keepers to reveal their parts of the secret. Some parts of current Bitcannery implementation are dependent on specific blockchain features. For reference implementation we've used Ethereum Smart contracts. 1) Smart contract couldn't call its own methods; 2) There's no timeouts for Ethereum Smart contracts; 3) There's no private data store for Ethereum Smart contracts.

1)+2) yields we need someone to call Smart contract to check whether Alice has missed her canary checkin or not; 3) yields the very impossibility to store only once-encrypted message and reveal it after timeout without any extra devices or actors. That being said, one should note that Bitcannery protocol could be implemented on top of any blockchain with Smart contracts with comparable to Ethereum's properties.

There are finer details:

  1. To get list of keepers to choose from, Alice starts her contract in call for keepers state. Actors interested in being a keeper for Alice contract send proposals with their payment rate and public keys. All Bitcannery contracts are registered in registry-contract, so keepers could find new ones to send proposals to. After enough keeper proposals are gathered, Alice chooses which ones to accept. With keepers list accepted, she saves the message and key parts in smart contract and starts canary checkins.
  2. Due to the fact that Ethereum Smart contracts couldn't initiate actions, we need third party actor to check whether trigger event has come or not. In current design this actors are contract keepers.
  3. It's very likely not all the keepers will stay active at all times. If a keeper misses couple checkin periods in a row, he will no longer receive a keeping fee.
  4. In case number of active keepers drops below reasonable level (for instance, is lower than a threshold for Shamir's secret sharing algorithm), Alice performs rotation procedure: opens new contract and marks existing one as closed and migrated.

Overview

Current web protocols powered by cryptography provide sutisfactory means to pass a secret message from one person (the sender) to another (the recipient) without exposing it to anyone else, such as end-to-end encrypted communications tools like Signal. But to shift the time of passing an encrypted message to the future — we have to trust a third party to do it for us.

Our system attempts to limit the the exposure of a secret to a third party and achieve a secure and trustless delivery of encrypted messages which could not be read by the recipient before a trigger event. To make this happen, system relies on the network of third-party agents — the keepers. Keepers don't have any access to the original message, they merely hold parts of a key required to decrypt the message and are motivated to keep it secret until a trigger event in the future.

The trigger event is continuously postponed by the sender, and only occurs when the sender stops actively checking in. In other words, the encrypted message is published when the sender stops preventing it from publishing.

Such system can be useful for releasing a password to encrypted files to relatives or friends in case of amnesia, for releasing sensitive data about rival party in case of imprisonment or other restraint, for leaving inheritance, for anonymity-preserving key escrow, for locking away data from oneself, for blackmailing, and for many other cases.