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
Oh yeah? Well, eureka too.

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,


   

Distributed timebased crypto

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

========== Summary: This is distributed network of hidden p2p nodes via "tor hidden server" feature, that provide time based crypto, without allowing any participating agents to obtain or release the private key until the release date.

======= Detailed: First we start with the USER.

The USER sends a request to a 'hidden by tor' node. It will send a container packet with space for a private/public key, and "date to decrypt". (As well as an indicator if its a public or private key, and a hash to help identify a private key)

This packet will bounces around the network, decrementing the days to decrypt descriptor between 80% to 50%. If below 80% it stops.

This is to prevent any one node from knowing if their key will activate on a particular day.

If a particular node with a 'request packet' feel like making a key, it would generates a public/private key.

The public key will be sent back to the USER by backtracking its path. The nodes in its path will know its a public key, and just send it upwards without delay.

The private key however will only go up a level when the packet at a certain level is allow to progress one level back to the public server, before eventually reaching back to it.

When it reach back to the node that the user first requested, it will publish the result via USER preferred action (e.g. P2P filessharing website).

========== Encrypting the document:

To prepare the time locked material. Encrypt the content with the public key (then dispose of it). Instruct the reader/decrypting_program to check for the released key at a particular time, and use the hash to check if the key works (or to find the key in a 'private key' database).

========= To protect against NSA styled mass sniffing of keys to brute match against a target file, the USER and the "originator node" should also use private/public keys, to protect the public and the private keys respectively going up stream.

======== Potential weakness: DDOS

mofosyne, Apr 11 2011

Original idea that I was hoping to improve upon. Do_20not_20decrypt_20until_20_2e_2e_2e
[mofosyne, Apr 11 2011]

[link]





      
[annotate]
  


 

back: main index

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