Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Quis custodiet the custard?

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


               

Timelocked Contract Network

  (+5)
(+5)
  [vote for,
against]

There are problems which involves time locking a secret from being distributed until a certain time later.

One way is to set an encryption that can be broken in a consistant rate of time. However time taken to break it is based on CPU speed, not actual time or date.

This system on the other hand, rely instead on a decryption key being split into multiple parts (so that it becomes a shared key).

A packet is then sent to each timeserver at random, with this structure.

Figure 1 (packet to each timeServers): [ (a) Parts of the shared key and it's hash, (b) trigger date and/or daemon event, (c) bitcoin payment to not release it early]

Figure 2 (packet to each payloadServer): [ (a) hash manifest- list of hash of other keys , (b) bitcoin payment to perform it's duty, (c) encrypted Payload]

After the timeserver receives the packet in fig1, that server will then wait for a trigger event, like a date. When triggered, that timeserver will then announces the hashfile of the shared key it is holding to all payloadServers in the world.

The payloadServer holding the packet in fig2, performs the job of trying to match the hash manifest with all the declared hashes of shared keys. On a full match, the payloadServer will grab all the keys from each listener and then decrypt and execute the payload's data and instructions. The payload will most of the time be a textfile, and the hash of the file that would be sent to a public repository or other payloadServer to display to the public. Alternatively the decrypted file could be a virtual machine daemon executing simple events like sending an email to a person; to complex events, such as ordering an assassination, or controlling a swarm of deathbots over IP.

--------

P.s. Crypto signed commands could perhaps be sent to timeservers to extend release time (with appropriate bitcoin compensation), or cancel releases.

P.s.s Timeservers are more effective if behind an anonymising network like tor or i2p

P.s.s. Timeservers conditional triggers could perhaps even be an algorithm for more complex trigger. Doesn't have to be purely time based.

P.s.s.s Why not have a single server release the key after a certain time? Well what if that server gets bribed to release it early? Having shared keys reduces the risk of betrayal. However if a timeserver gets shutdown early, it may be wise to allow each server two or three parts of the shared keys as redundancy.

P.s.s.s.s Bitcoin is ultimately optional, but helps motivate the server to stay honest, and to keep the servers running.

Idea is inspired by a novel called Daemon by Daniel Suarez

----------

Tl;DR: Network of servers collectively only releasing decryption keys after a trigger event like a date.

mofosyne, Jan 19 2014

Daemon (technothriller series) http://en.wikipedia...othriller_series%29
Daemon and Freedom™ comprise a two-part novel by the author Daniel Suarez about a distributed, persistent computer application, known as The Daemon, that begins to change the real world after the original programmer's death. [mofosyne, Jan 19 2014]

Article on WikiLeaks insurance files https://heavy.com/n...ks-insurance-files/
Mentioned in my anno [notexactly, Jan 05 2020]


Please log in.
If you're not logged in, you can see what this page looks like, but you will not be able to add anything.



Annotation:







       [+]   

       Where are the figures?   

       The payload could itself be another key, to a file that's been previously released publicly in encrypted form—remember when WikiLeaks released that encrypted "insurance file" with plans to release its key in retaliation for attacks on their people by the government (and then lost the key)?   

       // Having shared keys reduces the risk of betrayal. However if a timeserver gets shutdown [sic] early, it may be wise to allow each server two or three parts of the shared keys as redundancy. //   

       There exist encryption schemes where the key is split into n unique parts, but only m parts are needed for decryption, and m < n. That might be more suitable.
notexactly, Jan 03 2020
  

       Is that text the decryption key for Julian Assange's insurance file?
sninctown, Jan 03 2020
  

       A massive attack on AWS and several internet backbone service providers coincided with the capture of Assange. I strongly suspect that was how they prevented the release of the key
Voice, Jan 03 2020
  

       I wonder if some people have a slight fear a copy of that Assange key may surface. I take it the insurance file is common and being worked on as a de-encryption exercise?
wjt, Jan 03 2020
  

       I haven't been paying much attention to WikiLeaks in many years—it turns out they've released several insurance files in that time, and, while a few are intended to protect their key personnel and organization from governmental attacks, most of them are just unredacted versions of the documents they're planning to publish soon in redacted form, to ensure that that publication isn't blocked. [link]
notexactly, Jan 05 2020
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle