At some point I prototyped a tool that used Ron Rivest's timelock puzzles (repeated squaring modulo the product of two large safe primes takes a long time and isn't parallelizable, but is quick to compute if you can factor the modulus) to encrypt compressed tarballs of zero-day disclosures.
The idea would be that if you found a vulnerability in a product whose vendor was likely to pour more money into gag orders and legal threats than into fixing the vulnerability, you would publish the vulnerability encrypted in such a way that it would take several years of continuous computation to get the decryption key. Legal threats and/or general foot dragging couldn't put the cat back in the bag.
Here is an implementation of the same thing, but tailored toward encrypting Bitcoin private keys. Generalizing shouldn't be too difficult if you're interested: https://github.com/petertodd/timelock
No, the implementation you link to uses parallel-serial hash chains. Using that implementation, the person creating the file has to do as much work as the person reading the file, it's just that the creation can be parallelized. Use the linked to code, if you'd need to dedicate 1.5 months on a 16-core machine to generate a file that takes 2 years to read.
I'm suggesting something based on quadratic residues moduo a Blum integer instead of repeated hashing. This allows a shortcut if you know how to factor the Blum integer. It takes a few minutes on a single core to create a file that would take 2 years to read. Most of the file creation time is spent checking large random numbers for primality.
There are tradeoffs between the two different ways of creating timelock puzzles, but for the time being, I'm willing to assume anyone who can factor an 8192-bit number in under 2 years has better things to do with their cracker than decrypt my 0-day.
I suppose it would be nice to have a hybrid system where you could have stronger guarantees that someone capable of factoring 8102-bit integers would still need (for instance) at least 6 months of computing hash chains after they finished solving the quadratic residue portion of the problem, and someone who couldn't factor 8192-bit integers would spend (for instance) 18 months computing quadratic residues, followed by those 6 months of hash chaining. This would need 11.25 days of compute time on a 16-core machine to set up the hash chains, but at least it's not months of setup time.
I should point out that I would suggest using the solution to the quadratic residue problem as a key for a Blum Blum Shub stream cipher to encrypt the hash chains and the message, so that portion of the system only relies on square roots and quadratic residues modulo a Blum integer. (Using the quadratic residue solution as a key for AES-GCM or ChaCha20-Poly1035 would open you up to weaknesses in those ciphers, and in this case the slowness of Blum Blum Shub isn't a problem.)
Then, for the inner puzzle, I would use hash chains using a hash in the Blake family to generate a ChaCha20-Poly1305 key to encrypt the plaintext. Since Blake's round function is based on ChaCha20, this also reduces the number of different primitives you're relying on.
In the end, the cipher text would be doubly encrypted with Blum Blum Shub and ChaCha20-Poly1305, with keys being the solutions to repeated quadratic residue modulo a Blum integer and repeated hash chains using a hash from the Blake family. This minimizes the number of possible points of failure.
The idea would be that if you found a vulnerability in a product whose vendor was likely to pour more money into gag orders and legal threats than into fixing the vulnerability, you would publish the vulnerability encrypted in such a way that it would take several years of continuous computation to get the decryption key. Legal threats and/or general foot dragging couldn't put the cat back in the bag.
Sometimes I regret not publishing the tool.