5 ms·

Geeky version: let's assume you want to "time release" something (e.g. unlock it in approximately 5 years). Encode your assets/keys/passwords and share just a

Geeky version: let's assume you want to "time release" something (e.g. unlock it in approximately 5 years). Encode your assets/keys/passwords and share just a portion of the key. If you extrapolate computing cost/power trends, you can estimate how long until it will be practical to brute-force decrypt the portion of the key you didn't share. Of course, this is an approximate, not precise, timing system.

gruez 9y ago
problem is that a powerful adversary can "beat" your intended recipient by years or even decades. think whatever computing power a desktop has vs NSA, or even a guy with a lot of aws credits to burn.
- RandallBrown 9y ago
  A more likely problem is that nobody will ever even try to crack your key and release your information.
  - voltagex_ 9y ago
    Related, this is the premise of MC Frontalot's "Secrets from the Future": https://www.youtube.com/watch?v=FUPstXCqyus https://www.youtube.com/watch?v=FUPstXCqyus
- AgentME 9y ago
  There are ways of doing this that aren't trivially parallelizable for an attacker: https://www.gwern.net/Self-decrypting-files https://www.gwern.net/Self-decrypting-files. (Of course, the criticism still applies if the adversary is faster at whatever single-threaded operation you build the timelock on.)
shpx 9y ago
You can't estimate the time required because an attacker can crack keys in parallel. "devices can differ dramatically now even in the same computers; to take the example of Bitcoin mining, my laptop’s 2GHz CPU can search for hashes at 4k/sec, or its single outdated GPU can search at 54M/second [...] it would not be very useful to have a time-lock which guarantees the file will be locked between a year and a millennium, depending on how many & what kind of people bother to attack it and whether Moore’s law continues to increase the parallel-processing power available" A better (but still not great) way to do it is to take 100 random numbers, hash them a trillion times (in parallel), then use each hash to successively encrypt the starting seed for the next hash. The last hash in this chain is the private key you encrypt your data with. You release the first seed and each encrypted hash and the encrypted data. To brute force your key someone would have to hash the first seed a trillion times, decrypt the seed of the next hash and hash it a trillion times and so on until they get the key. This can't be parallelized, but you can generate the hashes in parallel. It's still not great because you're probably not using 100 of the best possible ASICs for your chosen hash, whereas an attacker might or might not. https://www.gwern.net/Self-decrypting-files https://www.gwern.net/Self-decrypting-files

gruez 9y ago

problem is that a powerful adversary can "beat" your intended recipient by years or even decades. think whatever computing power a desktop has vs NSA, or even a guy with a lot of aws credits to burn.

RandallBrown 9y ago
A more likely problem is that nobody will ever even try to crack your key and release your information.
- voltagex_ 9y ago
  Related, this is the premise of MC Frontalot's "Secrets from the Future": https://www.youtube.com/watch?v=FUPstXCqyus https://www.youtube.com/watch?v=FUPstXCqyus
AgentME 9y ago
There are ways of doing this that aren't trivially parallelizable for an attacker: https://www.gwern.net/Self-decrypting-files https://www.gwern.net/Self-decrypting-files. (Of course, the criticism still applies if the adversary is faster at whatever single-threaded operation you build the timelock on.)

shpx 9y ago

You can't estimate the time required because an attacker can crack keys in parallel. "devices can differ dramatically now even in the same computers; to take the example of Bitcoin mining, my laptop’s 2GHz CPU can search for hashes at 4k/sec, or its single outdated GPU can search at 54M/second [...] it would not be very useful to have a time-lock which guarantees the file will be locked between a year and a millennium, depending on how many & what kind of people bother to attack it and whether Moore’s law continues to increase the parallel-processing power available" A better (but still not great) way to do it is to take 100 random numbers, hash them a trillion times (in parallel), then use each hash to successively encrypt the starting seed for the next hash. The last hash in this chain is the private key you encrypt your data with. You release the first seed and each encrypted hash and the encrypted data. To brute force your key someone would have to hash the first seed a trillion times, decrypt the seed of the next hash and hash it a trillion times and so on until they get the key. This can't be parallelized, but you can generate the hashes in parallel. It's still not great because you're probably not using 100 of the best possible ASICs for your chosen hash, whereas an attacker might or might not. https://www.gwern.net/Self-decrypting-files https://www.gwern.net/Self-decrypting-files