Also I presume it doesn't work well for small time intervals (less than or equal to drand's block creation times)?
I have a healthy amount of skepticism of this approach.
There is no chain or block creation. Also it's not a public permissionless network, so outside actors can't join for a sybil attack.
>I presume this timelock can be cracked early if I spend enough compute resources on it.
Sure like any cryptography, if you have more computing power than exists in the world
>Also I presume it doesn't work well for small time intervals (less than or equal to drand's block creation times)?
There is a dependence on transmitting shares between nodes in the network to gain a threshold number of share - right now each epoch is 30 seconds, but new networks could be created with down to ~1 second epochs
And I didn't see any, but if there is the capability of onboarding new members in the network, it requires bootstrapping a new chain, I think.
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.
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.
> 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.
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?
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.
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.
Hm ok, it's just that there is a lot of blockchain terminology used throughout drand like "testnet", "mainnet", "chain" and so on. Seems very similar to a blockchain with similar attack scenarious but I guess it's not exactly a blockchain but somewhat similar?
> Currently it relies on the League of Entropy network, run by Cloudflare, Protocol Labs, Ethereum Foundation, Kudelski Security and other organizations, including multiple universities. So the security is relying on the fact that the network's goal is to produce public randomness, and that parties have no reason to collude. For instance the League of Entropy is used for leader election and randomness by Filecoin, so it's already "securing" a lot of things, adding timelocked data on top seems like a nice way to use the network.
I see so there is a closed group of more or less well known entities which hopefully wont be dishonest to a major degree. Closed group being the key here because that prevents whole range of attacks, most importantly sybil attacks. So the trust in the system derives from the trust into the participants.
Without researching it more I would guess that during encryption it might use the public keys of the nodes plus the round number with the threshold scheme and when the round finally arrives, the nodes then publish their private keys for this round?
I think I have a better idea of the system now. Judging by me being not the only one here who didn't understand how things work on a high level maybe the README could be expanded a bit. That would be great.
To me the beautiful thing about trying to get randomness is that as long as you have one random source then you have randomness. I.e. non-random XOR random => random.
So, you use X sources, as long as one of them is truly random then you are golden. Even if most are compromised it shouldn’t matter. Use on device security chip randomness, use user input, use external party providers etc. it all helps! (But be careful to errors when implementing, that’s hard to do!)
Probably requires too much trust in the satellite's builders, but it's a fun idea...
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?
But maybe I lack imagination.
Why do we trust permissioned nodes to not get compromised or the permissioning body to not accidentally or intentionally let in malicious nodes?
Couldn't a few well placed gag orders by a sufficiently powerful government be enough to subvert the whole system in a non evident way?
The problem is that the witness encryption is extremely inefficient with today's knowledge.
So, as long as you can trust a space agency to broadcast the current time to the entire world, you'll be fine.
[1]: https://www.gsc-europa.eu/galileo/services/galileo-open-serv...
One situation that seems relatively common is developers who are working on a commercial product who might want to see it open-sourced down the road. The developers (not the company) could prepare the source code on the company's hardware (i.e. where they normally do development), timelock-encrypt it, and then take it home with them or publish it somewhere. They would then have the assurance—since they actually prepared and encrypted the source code snapshot—of what's inside.
Average Joe Coder might not have the pull to get their company to agree to such a scheme, but I can imagine some very high-profile people might. E.g. if you're a recognized expert in your field (think John Carmack or someone of his stature in whatever niche you want), maybe you put a requirement for timelocked access to the code you write as a must-have in your consulting contracts. Then you would still be able to get work with private companies, but have some assurance that your work would be publishable and benefit the public down the road.
I'm sure you could probably even rig up some Git hook that timelock-encrypts every commit and pushes it to a public repo somewhere (Internet Archive, maybe?) that's expected to be available for a good long while.
I believe (admittedly from skimming and educated guesses) the setup is that the League of Entropy network is a set of computers operated by different people which each have published public keys, and the participants regularly do multi-party computation to create random numbers that provably can not be manipulated by any non-majority subset of the group. Besides calculating verifiably random numbers, the computers will also decrypt content for anyone if you send it content encrypted to their public keys and the encrypted content contains a time range that includes the present. (Maybe their main protocol for random numbers requires this protocol to be implemented?) Then you can do time-lock encryption by encrypting some content, splitting the key using a threshold scheme, then separately encrypt each part of the key to a different participant of the League of Entropy network bundled with a requested time-range for decryption to be allowed. It works as long as enough League of Entropy network participants stay online and enough of them don't defect or get hacked.
The main assumption here is that said network will still be operational, publicly accessible and non-compromised at decryption time.
In any case another assumption is that there are no quantum computers able to break your ciphertext since every primitive used here is broken by quantum computers. So it would be ill-advised to use it to encrypt something that cannot be decrypted until 10, 20 or 50 years, since it might well be broken by then if even if the network survived. But for near-future things, it works well.
The guy claims to be doing timelock using Galileo timestamps.
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.
