Timelock Encryption made possible and easy to use(github.com)
github.com
Timelock Encryption made possible and easy to use
https://github.com/drand/tlock
65 comments
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.
> 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.
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.
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!)
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!)
> 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.
Only if the sources choose their numbers independently of each other. If the non-random is a function of the random source (e.g. the identity), then the result isn't random, it's a constant 0.
Only if the sources choose their numbers independently of each other. If the non-random is a function of the random source (e.g. the identity), then the result isn't random, it's a constant 0.
Also, be careful of a "last player attack" when XORing randomness: if your last source could spy on the state of your buffer, or on all other randomness sources, it can trivially craft a string that would XOR to a specific value once XORed with the other sources.
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...
Probably requires too much trust in the satellite's builders, but it's a fun idea...
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.
I would guess that a satellite can literally just have a TX radio on this module, so as long as you trust it to have been built and launched securely it can't be tampered with by anyone without space capability?
Whereas a server on the internet could be compromised over the internet.
Whereas a server on the internet could be compromised over the internet.
You could have a server that only sends to the network as well. Just block everything apart from outgoing UDP packets. For the price of development and launch of such a satelite you'd probably be able to afford to make a custom hardware box with hardware random number generator that can physcally only send. In both cases you'd have to fully trust someone to have set up the system correctly. Both wouldn't be something I'd want to rely on.
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.
The main assumption here is that said network will still be operational, publicly accessible and non-compromised at decryption time.
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.
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.
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).
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.
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.
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.
That would be a pretty cool way of achieving timelock, sure, but might not be super practical.
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.
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.
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.
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.
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.
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?
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.
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.
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 :)
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.
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.
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...
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.
Yeah, that's not exactly how it works. The drand nodes are publishing random beacons that are signed, that's the only thing the networks does. Publishing public verifiable randomness. But pairing-based cryptography allows us to do identity-based encryption and that's like magic, but basically we can rely on a message as a public key, and on a signature as a secret key, and that's how tlock works.
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?
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?
It could, and that's why a solid threshold network should have nodes in different locations, jurisdictions, cloud providers, etc. and have a threshold that's high enough to avoid that risk.
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...
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...
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/
In practice everything released at defcon sees its last commit within 24H prior of the presentation. An unfortunate reality.
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
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.
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.
>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
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
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.
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.
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.
Onboarding new members on a drand network is fairly easy: there only needs to be a threshold of nodes doing a resharing ceremony and all nodes get new shares and new nodes can be onboarded like that. It's not handled by tlock or timevault, it's on the League of Entropy side and is how drand works. More details are in https://drand.love/docs/cryptography/
the source code is on github https://github.com/drand/timevault
That is right and it is not explained in the README file. Timelick based on Blockchain is not a security primitive.
there is no blockchain involved at all
I used the term blockchain with liberty, it is based on a consensus mechanism so you need to assume the consensus is right which is different of timelock encryption usage in classic ways. The README was edited after the HN posts.
It's not really a consensus mechanism either really - the randomness in some sense is deterministic, it just requires participation. I'm unsure which 'classic ways' you're referring to - in principle it's not that different to having a notary, except the notary is a distributed network rather than a single entity.
> The README was edited after the HN posts.
You can see from that the tlock git history the README.md hasn't been updated in 13 days and the tlock-js one hasn't been updated in 4 days - both before the HN post. Are you talking about another README?
> The README was edited after the HN posts.
You can see from that the tlock git history the README.md hasn't been updated in 13 days and the tlock-js one hasn't been updated in 4 days - both before the HN post. Are you talking about another README?
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.
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.
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.
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 saw this talk in person at DEFCON. Great talk
Except for the math part when the slides were frozen, I guess :P
I'm reminded of this comment: https://news.ycombinator.com/item?id=31556968
The guy claims to be doing timelock using Galileo timestamps.
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.
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
Almost, the randomness is generated using a BLS signature that also makes it verifiable. And that signature is the decryption key.
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.
Timelock using trusted third parties was first proposed in 1993 by Tim May, the founder of the crypto-anarchist movement, yeah.
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?
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.
It's the reverse - it can only be decrypted after a threshold timestamp, not before.
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.
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.
Couldn't one just change the date/time on their machine? Please explain how this won't work.
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
I believe this depends on some blockchain, and you can't move forward without a consensus from a majority of nodes.
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
To clarify: there's no blockchain involved.
> 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.