I was curious how this could work and spotted this sentence in the README:<p>> In practice this means that if you trust there are never more than the threshold t malicious nodes on the network you're relying on, you are guaranteed that you timelocked data cannot be decrypted earlier than what you intended.<p>So I guess this just relies on a multi key threshold scheme where t nodes have to combine their keys to decrypt the data. And I assume the blockchain tries to punish participants who refuse to take part in the decryption?<p>If so then this seems very tricky in terms of risk because if you have more than t malicious nodes they can secretely collude outside the chain to decrypt the data before the specified time and you'd never know in contrast to the usual attacks on blockchains which are very obvious. So the chain in that regard does not and can not add to keep the actors honest in that regard.<p>Would love to see the DEF CON presentation but I couldn't find a video for it. Didn't even spot it in the DEF CON timetable.
So, effectively this encrypts a message for a public key whose corresponding private-key owner promises to only decrypt it after the specified time. Except that the owner here is a distributed network, so the promise can only be broken by a majority of the network.<p>The main assumption here is that said network will still be operational, publicly accessible and non-compromised at decryption time.
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: <a href="https://www.github.com/CassOnMars/Timelock" rel="nofollow">https://www.github.com/CassOnMars/Timelock</a>), 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: <a href="https://www.github.com/CassOnMars/Wesolowski-VDF" rel="nofollow">https://www.github.com/CassOnMars/Wesolowski-VDF</a>).
I don't quite understand how this works. I get that the League of Entropy is a verifiable timestamped network source of randomness, but how does this let you set a future time for decrypting something that you encrypt now. How do you depend on a quality of the random source in the future, when by definition that can't be predictable?
How does this establish that we can trust the oracles telling us what time it is?<p>The only way I could see this working very long term and for important data is by using the bitcoin blockchain (often called the timechain) as a clock that literally can't be cheated because the proof of work allows you to independently verify that some amount of real world energy and computational machines were consumed to lock in every block. Otherwise, how do you not end up with a Byzantine generals problem?<p>But maybe I lack imagination.
Encrypting something that cannot be decrypted until a given future date is now possible :D
This was presented on Friday at DEF CON, and there's also a web demo to try it out using the second compatible TS library: <a href="https://timevault.drand.love/" rel="nofollow">https://timevault.drand.love/</a>
A cool application of this could be to release currently closed source code encrypted until some number of years in the future (10 or 20 would be my guess) at which point anyone holding the original encrypted source could view the plaintext. I'd rather vendors just open source in the first place, but this could be a nice way to have a sort of smart contract guaranteeing future access to source code.
I'm reminded of this comment: <a href="https://news.ycombinator.com/item?id=31556968" rel="nofollow">https://news.ycombinator.com/item?id=31556968</a><p>The guy claims to be doing timelock using Galileo timestamps.
Something to do with encrypting using a hash of the round number and pair encryption based off a chosen chain's public key. I'm still processing the pair encryption bits.
timelock has existed since ephemeral key lodgement with an escrow under instruction was first stated as an idea. I imagine it was close to when trusted third parties launched, with timestamping services. take timestamp from TTP #1 and lodge keys with TTP #2 under instructions.
I'm trying to think of use cases as the readme also suggest a threshold timestamp AFTER which things can't be decrypted (I guess for things like log rotation?) and I think that simply deleting (overwriting securely or whatever) would be far less resource intensive?
Why not just send the Decryption key after X time has elapsed? You do not even trust yourself?<p>If you really want to make it vulnerable to 51% attacks you can also split the cypher and send it to a lot of different people to be reassembled in a later date.