Also a good article by Gwern about the same topic: http://www.gwern.net/Self-decrypting%20files
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.
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.
