Bitcoin Forum
November 12, 2024, 12:17:59 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Time-release encryption using Bitcoin?  (Read 1598 times)
tlr (OP)
Member
**
Offline Offline

Activity: 86
Merit: 10


View Profile
July 02, 2013, 05:01:38 PM
 #1

Snowden's (and previously Wikileaks') use of encrypted "insurance" files got me thinking: how could we leverage the blockchain to implement time-release encryption? That is, the encryption keys to decrypt a certain file are released after a certain time (either the full key is released publicly, or it can be combined with a private portion of the key)

Bitcoin's "nLockTime" seems like the obvious place to start. Here's a rough sketch of the scheme I've been thinking of:

The main primitive is transactions including some "bounty" that can only be spent after a specified time (nTimeLock), if a piece of data (the key) hashes to a specific hash. The output address can be chose by the person redeeming it. (sorry, I don't know all the correct terminology)

Your encrypted file uses an n-of-m scheme, so it can only be decrypted if at least n of the m keys are known.

You pick m different people to hold the keys ("key holders"), and give each one a transaction in the blockchain they can redeem after the specified time if they include their key in the transaction. As long as n of the people redeem their transactions the file can be decrypted.

If the key holders collude to combine their keys (off chain) beforehand then they would risk the other key holders claiming their bounty.

The problem is if they determine the decrypted information is worth more than the bounty. Perhaps a surety bond scheme could be layer on?

But ideally the key holders wouldn't even be able to find the other key holders without revealing their keys, and they wouldn't know which encrypted data the keys they're holding unlocks (while still allowing someone watching the blockchain to figure it out)

Note this scheme doesn't support revoking the keys. If you could somehow invalidate the transactions then the key holders wouldn't have any incentive to not collude.

I'm sure there are improvements that could be made. I'm interested to hear other ideas.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 568

fractally


View Profile WWW
July 02, 2013, 05:17:30 PM
 #2

Very interesting idea!  Watching this thread.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
phillipsjk
Legendary
*
Offline Offline

Activity: 1008
Merit: 1001

Let the chips fall where they may.


View Profile WWW
July 03, 2013, 05:03:03 PM
 #3

But ideally the key holders wouldn't even be able to find the other key holders without revealing their keys, and they wouldn't know which encrypted data the keys they're holding unlocks (while still allowing someone watching the blockchain to figure it out)

What prevents the keyholders from watching the bock-chain?

The Bitcoin protocol relies on people being able to prove they have a key without actually revealing that key.


James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
tlr (OP)
Member
**
Offline Offline

Activity: 86
Merit: 10


View Profile
July 03, 2013, 07:23:47 PM
 #4

But ideally the key holders wouldn't even be able to find the other key holders without revealing their keys, and they wouldn't know which encrypted data the keys they're holding unlocks (while still allowing someone watching the blockchain to figure it out)

What prevents the keyholders from watching the bock-chain?

The Bitcoin protocol relies on people being able to prove they have a key without actually revealing that key.

Note by "key" I don't mean Bitcoin keys.

I meant the key holders wouldn't be able to find other key holders until they reveal their portion of the key in the blockchain, then anyone who is looking for the key would be able to find it in the blockchain.

I imagine there's some cryptographic solution to that particular problem, I just haven't thought it through completely.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 568

fractally


View Profile WWW
July 04, 2013, 06:25:31 AM
 #5

What are the applications for this and how much value would it have in the market?

It is already possible to require the production of  X  such that SHA256(X) == Y is a check for spending.

So you can can use an Error Correcting Code to create 10 chunks such that any 5 of the 10 chunks can be used to reassemble the entire key.    Then create a transaction that generates outputs spendable when X is provided and after a certain number of blocks have passed.   

Then broadcast  chunks 0 to 10 to a whole host of random people with instructions on how to claim the money.   

Once 5 people claim the money the private key is revealed and the data can be decoded.

No one would reveal X before the transaction could be spent because only the first one to claim it gets it. 


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!