3 ms·
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 t
by 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