4 ms·
This is not Timelock encryption. Timelock encryption relies on the use of time lock puzzles, which frequently revolve around variations of repeatedly squaring a
by cassonmars 4y ago
This is not Timelock encryption. Timelock encryption relies on the use of time lock puzzles, which frequently revolve around variations of repeatedly squaring a value in a particular way which makes it impossible to shortcut without knowing the original setup parameters. Variations include a RSA-style approach (which I've created an open source repo here: https://www.github.com/CassOnMars/Timelock https://www.github.com/CassOnMars/Timelock), or by omitting knowledge of the order of the group (possible with imaginary quadratic cryptography), creating a verifiable delay function, such as the Wesolowski VDF (repo: https://www.github.com/CassOnMars/Wesolowski-VDF https://www.github.com/CassOnMars/Wesolowski-VDF).
- zmgsabst 4y agoYou can also do hashes: You use a GPU to do N parallel chains of M length. You then encrypt the seeds for the chains using the previous chain’s ending value as the key for the seed. The seed of the first chain is your starting point; the ending of the last chain encrypts your key. Anyone seeking to “unlock” that key must do the hashing sequentially — meaning that you can use a cluster to get ratios like 1,000,000:1 between generation and unlocking. For reference, there’s around 500,000 minutes in a year.
- cassonmars 4y agoThat can possibly work, however it has a significantly greater variability in deployment environments compared to traditional time lock puzzles due to it being trivially optimized by hardware (depending on the hash algorithm chosen). It unfortunately does not work at all as a VDF though, as the proof requires the entire chain of hashes and is not succinct enough to be used on commodity hardware.
- xhrpost 4y agoI wonder if there's a way to beam the key out into space with RF at a very distant, but RF-reflective, object. The key hits the object and bounces back and cannot be received until it reaches earth again. I'm not sure such a set-up is physically possible but I think it would be a truly timelocked situation.
- anomalroil 4y agoThat would be a pretty cool way of achieving timelock, sure, but might not be super practical.
- ale42 4y agoExcept if someone can sniff your outgoing RF... given that the power reflected back from the very distant object would have a gigantic attenuation (just the path to the moon has ~250 dB attenuation), you would have to use an enormous RF output power. But at this point, anyone close enough to the transmitter (even if you use highly directional antenna) could basically sniff the key being transmitted.
- anomalroil 4y agoWell, Timelock Encryption is "encrypting somewhat towards the future", and as explained in the talk, in 1996 "Timelock puzzles" were proposed by Rivest, Shamir and Wagner as a "proof of work" based system to achieve it. Sadly that's very sensitive to hardware evolution, and when Rivest tried to create a puzzle meant to last 35 years in 99, it ended up being broken in 2019 after only 20 years. It was even doubly broken: once by a guy running it on his CPU for 3.5 years only, and once in only 2 months by a FPGA/ASIC implementation done by the Cryptophage collab between Ethereum Foundation, Supranational and Protocol Labs... Other names that are also about achieving timelock encryption include "timelapse encryption" and "timed release encryption". Some people do a distinction because for instance the timelock puzzle are mostly about achieving a lower bound on the time it requires to solve them but aren't mapping well to a precise time. VDFs are promising tools to achieve timelock or timed released encryption, for sure.
- michaelt 4y agoIn most cryptographic applications there's a huge performance margin between authorized and unauthorized behaviour. If decrypting without a password is 10 trillion times slower than decrypting with a password, it doesn't matter if an attacker finds a 4x speedup from somewhere. If I'm trying to make a timelock puzzle that will last 50 years, I've got much less performance margin - a timelock guaranteed to last "somewhere between 50 and 200 years" would be very hard to achieve - and yet, not very useful. Meanwhile, if the decrypter has to be run continuously, it relies on being powered and working, and kept up-to-date with the latest improvements in clock speeds, ASICs and cryptography - when the people operating it could go bankrupt, or change their plans, or get hacked, any of which could reset the timer to zero. So for important applications like "these secret government archives must be made public in 50 years, but no earlier" it's useless because any adversary who wants to prevent the release can knobble the decryption process to reset the timer to zero. And for unimportant applications like "Grandpa's old diary, which he doesn't want anyone to read for the next 50 years" it's useless because who's going to fund 50-200 years of cutting edge ASICs for something so mundane? And for short-term applications like "the gambling site will prove the dice were fair after the game is over" there are simpler options available.