Timelock Encryption made possible and easy to use

by anomalroil • 4 years ago

124 65 4 years ago

anomalroil16• 4 years ago

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: https://timevault.drand.love/

dgrin91• 4 years ago

How does this work really? Is this basically just putting someone on chain, presuming that there wont be a 51% attack, and relying on the chains normal block creation schedule? I presume this timelock can be cracked early if I spend enough compute resources on it.

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.

somenewaccount1• 4 years ago

the source code is on github https://github.com/drand/timevault

wslh2• 4 years ago

That is right and it is not explained in the README file. Timelick based on Blockchain is not a security primitive.

eximius2• 4 years ago

Sort of. It uses secret sharing so it's not based on computation power.

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.

h0h0h0h01116• 4 years ago

Is this basically just putting someone on chain, presuming that there wont be a 51% attack

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

anomalroil16• 4 years ago

It works by relying on identity-based encryption to encrypt plaintext that cannot be decrypted until the signature of a specific message is revealed. The League of Entropy is signing its beacons every 30 seconds and so acts as a reference clock to provide the signatures on time.

foobiekr• 4 years ago

In practice everything released at defcon sees its last commit within 24H prior of the presentation. An unfortunate reality.

anomalroil16• 4 years ago

Ahahah, definitively. Where's the challenge otherwise? The PoC was ready since almost 8 months sitting in a branch of drand/kyber, and the Go tlock library since a month or so and it would have been enough if it weren't for the DEF CON presentation that made a web-demo more appealing for people to try it out :P

dannyobrien• 4 years ago

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?

AgentME• 4 years ago

It's not using the future random numbers to decrypt the value. It's making use of the underlying protocol that the League of Entropy is using primarily but not exclusively for calculating fair random numbers.

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.

anomalroil16• 4 years ago

Yeah, it's not exactly how it works, but close. The League's node ran together a distributed key generation that created a secret key for the whole League so that it's sufficient to have only a threshold number of nodes to recreate that secret key. But since it's using threshold cryptography, it doesn't even ever need to recreate the secret, it can simply aggregate "partial signatures" into valid signatures for the group's public key. The timelock scheme itself relies on so-called "identity-based encryption", so that you can encrypt a plaintext towards the signature of a specific message. And you know in advance that the League is going to sign round number X at time Y, so you can encrypt towards the signature of the round number X, and once it's produced, that signature allows to decrypt the ciphertext. Pairing-based cryptography is kinda magic on that front :)

ljlolel• 4 years ago

I saw this talk in person at DEFCON. Great talk

anomalroil16• 4 years ago

Except for the math part when the slides were frozen, I guess :P

ggm• 4 years ago

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.

anomalroil16• 4 years ago

Timelock using trusted third parties was first proposed in 1993 by Tim May, the founder of the crypto-anarchist movement, yeah.

ranger_danger• 4 years ago

Couldn't one just change the date/time on their machine? Please explain how this won't work.

m-p-3• 4 years ago

I believe this depends on some blockchain, and you can't move forward without a consensus from a majority of nodes.

h0h0h0h01116• 4 years ago

It's not consensus per se - each node releases a share of a secret and if any node gains a threshold number of shares, they can use interpolation to generate the signature and thus the randomness. Different nodes could even collect a different set of shares to reach the threshold and they'd still generate the same signature

endorphine• 4 years ago

To clarify: there's no blockchain involved.

h0h0h0h01116• 4 years ago

Round numbers are tied to a date time in a loose sense that each participant should be emitted a share for every time period since the genesis. A single node emitting its shares early or late wouldn't affect the network - only a threshold number of nodes doing so

anonporridge2• 4 years ago

How does this establish that we can trust the oracles telling us what time it is?

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.

anomalroil16• 4 years ago

This is based on a permissioned threshold network, so as long as there are never a threshold number of nodes that are malicious and as long as there is a threshold number of nodes that continue to operate, the network's liveness and security is guaranteed. Using Bitcoin as a cryptographic reference clock has been proposed in the past, but the good way of doing it is relying also on SNARKs and isn't really that practical from what I can tell: https://link.springer.com/content/pdf/10.1007/s10623-018-046...

layer83• 4 years ago

From another comment: “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.” That sounds like decryption would fail when the present time is after the specified time range.

anonporridge2• 4 years ago

A Sybil attack seems like the most likely weakness then.

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?

withinboredom• 4 years ago

Some GPS satellites are currently broadcasting the current time with a cryptographic hash to prove that the broadcast time is the actual time[1] and authenticate the satellite as not being tampered with. It's live right now. So, as long as you can use witness encryption to prove that the broadcasted hash and signal is after a certain time, you can have true time locked encryption.

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...

eximius2• 4 years ago

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.

h0h0h0h01116• 4 years ago

Essentially the hash of the round number is the encryption key and the randomness that gets generated at that round number (in the future) is the decryption key

anomalroil16• 4 years ago

Almost, the randomness is generated using a BLS signature that also makes it verifiable. And that signature is the decryption key.

eis4• 4 years ago

I was curious how this could work and spotted this sentence in the README:

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.

anomalroil16• 4 years ago

Yes and no: it's not a blockchain. It's relying on the fact that the drand network is producing distributed, verifiable randomness using a threshold scheme with distributed key generation. So the secret key of the group is never in memory on any device and the only way to obtain a valid signature for a message is by having a threshold number of "partial signatures" being produced by the drand nodes in the network. 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. And yeah, if there are ever a threshold of nodes colluding to produce a signature "too early", that's sadly not detectable.

miketery• 4 years ago

Thanks for sharing these randomness sources, will have to explore them.

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!)

eis4• 4 years ago

Yes and no: it's not a blockchain. It's relying on the fact that the drand network is producing distributed, verifiable randomness using a threshold scheme with distributed key generatio

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.

sdenton4• 4 years ago

One of my old friends had a fun idea for time locked encryption using a satellite, by broadcasts public keys and then the matching private keys after a fixed amount of time.

Probably requires too much trust in the satellite's builders, but it's a fun idea...

eis4• 4 years ago

How does using a satellite broadcasting differ from a server on the internet publishing the keys? Both are single points of truth that you'd have to fully trust.

Temporary_31337• 4 years ago

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?

ashtuchkin• 4 years ago

It's the reverse - it can only be decrypted after a threshold timestamp, not before.

slaymaker19072• 4 years ago

That would be a lot more difficult, if not impossible. My understanding of this thing is that it's sort of like a distributed key generator with part of the protocol being that the key is revealed after a particular point in time. If such a thing existed for the reverse, I suspect it would enable general purpose DRM by combining Timelock Encryption with the threshold timestamp mechanism so that some document would only be decryptable for a particular time period.

layer83• 4 years ago

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.

The main assumption here is that said network will still be operational, publicly accessible and non-compromised at decryption time.

anomalroil16• 4 years ago

Yeah, I guess that's a fair way of describing threshold cryptography and a threshold network. There was actually already once a proposal of creating a "timelapse encryption service", by Rabin in 2006 (https://dash.harvard.edu/handle/1/26506434) they said they were planning on implementing and deploying such a service, but it never made it AFAIK. The main difference here is that it's relying on an existing service providing also something else, namely public randomness, and that this service has been running for 2 years and never had any disruption so far.

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.

slaymaker19072• 4 years ago

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.

layer83• 4 years ago

The problem being that there’s no proof that what was encrypted is actually the source code, before it can be decrypted. So you’d have to take the vendor’s word for it.

ffhhj• 4 years ago

Maybe using a zero-knowledge proof.

Kadin• 4 years ago

Well, sure: but if the company doesn't want to release the source code at a future date, they just... don't do it. That's sort of a separate problem. If you assume the company (or the developers, whatever) actually want to reveal the code, but just don't want to give it away to their competitors today, it seems like it would work.

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.

cassonmars2• 4 years 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), 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).

zmgsabst• 4 years ago

You 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.

cassonmars2• 4 years ago

That 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• 4 years ago

I 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.

anomalroil16• 4 years ago

That would be a pretty cool way of achieving timelock, sure, but might not be super practical.

ale42• 4 years ago

Except 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.

anomalroil16• 4 years ago

Well, 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• 4 years ago

In 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.

RealityVoid• 4 years ago

I'm reminded of this comment: https://news.ycombinator.com/item?id=31556968

The guy claims to be doing timelock using Galileo timestamps.

drdrek• 4 years ago

Why not just send the Decryption key after X time has elapsed? You do not even trust yourself?

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.

Timelock Encryption made possible and easy to use

Related Stories