One gap though is that the opening example is the idea of creating an insurance file that is publicly decryptable at a certain date if a particular real-world condition exists, like the file's author being kidnapped or whatever. But to make that work in practice you need not just time-lock encryption, but resetable time-lock encryption where it's possible to delay the release of the time-lock if that condition has not been met. I can see why the examples don't tackle that since even the basic problem seems unsolved, much less a tunable version of it, but it's a very interesting thought exercise.
It feels like a true time-lock solution should be impossible to unlock before a particular date, but trivial afterwards, rather than assuming the opener started work on it at the moment it was released and has been burning cycles at some maximal rate since then.
I don’t think the universe contains unfakeable timestamps, which seem to be a requirement for that true solution - it feels like it’s not compatible with relativity, so maybe proxies are the best we can do on a fundamental level.
- Can time-lock (encrypt) in negligible time (almost instantaneosly)
- Non-parallelizable sequential algorithm
- Decrypts in constant CPU cycles (meaning CPU with 2x faster clock will decrypt 2x faster)
It can only time-lock numeric data though. It's enough for me, I'm using it to encrypt PINs and root passwords for the Screen Time restriction setups of my various devices (iPhone, Linux PC). It allows me to have unbypassable restrictions while also not having to trust a friend/relative. This concept is known as a commitment device: https://en.wikipedia.org/wiki/Commitment_device