7 ms·

Timelock Encryption made possible and easy to use

124 points by anomalroil 4y ago

ranger_danger 4y ago
Couldn't one just change the date/time on their machine? Please explain how this won't work.
- m-p-3 4y ago
  I believe this depends on some blockchain, and you can't move forward without a consensus from a majority of nodes.
  - h0h0h0h0111 4y 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 4y ago
    To clarify: there's no blockchain involved.
- h0h0h0h0111 4y 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
anomalroil 4y 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/ https://timevault.drand.love/
- dgrin91 4y 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.
  - wslh 4y ago
    That is right and it is not explained in the README file. Timelick based on Blockchain is not a security primitive.
    - h0h0h0h0111 4y ago
      there is no blockchain involved at all
      - wslh 4y ago
        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.
        h0h0h0h0111 4y ago
        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?
  - 4y ago
dannyobrien 4y 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 4y 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.
  - anomalroil 4y 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 4y ago
I saw this talk in person at DEFCON. Great talk
- anomalroil 4y ago
  Except for the math part when the slides were frozen, I guess :P
ggm 4y 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.
- anomalroil 4y ago
  Timelock using trusted third parties was first proposed in 1993 by Tim May, the founder of the crypto-anarchist movement, yeah.
anonporridge 4y 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.
- anomalroil 4y 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-0461-x.pdf https://link.springer.com/content/pdf/10.1007/s10623-018-046...
  - layer8 4y 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.
    - anomalroil 4y ago
      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.
  - 4y ago
eximius 4y 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.
- h0h0h0h0111 4y 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
  - anomalroil 4y ago
    Almost, the randomness is generated using a BLS signature that also makes it verifiable. And that signature is the decryption key.
eis 4y 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.
- sdenton4 4y 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...
  - eis 4y 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.
    - rawling 4y ago
      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.
      - 4y ago
Temporary_31337 4y 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 4y ago
  It's the reverse - it can only be decrypted after a threshold timestamp, not before.
- slaymaker1907 4y 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.
layer8 4y 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.
- anomalroil 4y 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 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.
slaymaker1907 4y 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.
- layer8 4y 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 4y ago
    Maybe using a zero-knowledge proof.
    - tnzk 4y ago
      Some reproducible builds with a confidential VM and use the digest of build artifacts might work.
  - Kadin 4y 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.
cassonmars 4y 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 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 https://www.github.com/CassOnMars/Wesolowski-VDF).
- zmgsabst 4y 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.
  - cassonmars 4y 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 4y 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.
RealityVoid 4y ago
I'm reminded of this comment: https://news.ycombinator.com/item?id=31556968 https://news.ycombinator.com/item?id=31556968 The guy claims to be doing timelock using Galileo timestamps.
drdrek 4y 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.

124 points by anomalroil 4y ago

ranger_danger 4y ago

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

m-p-3 4y ago
I believe this depends on some blockchain, and you can't move forward without a consensus from a majority of nodes.
- h0h0h0h0111 4y 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 4y ago
  To clarify: there's no blockchain involved.
h0h0h0h0111 4y 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

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

dgrin91 4y 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.
- wslh 4y ago
  That is right and it is not explained in the README file. Timelick based on Blockchain is not a security primitive.
  - h0h0h0h0111 4y ago
    there is no blockchain involved at all
    - wslh 4y ago
      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.
      - h0h0h0h0111 4y ago
        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?
- 4y ago

dannyobrien 4y 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 4y 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.
- anomalroil 4y 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 4y ago

I saw this talk in person at DEFCON. Great talk

anomalroil 4y ago
Except for the math part when the slides were frozen, I guess :P

ggm 4y 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.

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

anonporridge 4y 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.

anomalroil 4y 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-0461-x.pdf https://link.springer.com/content/pdf/10.1007/s10623-018-046...
- layer8 4y 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.
  - anomalroil 4y ago
    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.
- 4y ago

eximius 4y 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.

h0h0h0h0111 4y 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
- anomalroil 4y ago
  Almost, the randomness is generated using a BLS signature that also makes it verifiable. And that signature is the decryption key.

eis 4y 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.

sdenton4 4y 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...
- eis 4y 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.
  - rawling 4y ago
    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.
    - 4y ago

Temporary_31337 4y 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 4y ago
It's the reverse - it can only be decrypted after a threshold timestamp, not before.
slaymaker1907 4y 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.

layer8 4y 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.

anomalroil 4y 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 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.

slaymaker1907 4y 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.

layer8 4y 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 4y ago
  Maybe using a zero-knowledge proof.
  - tnzk 4y ago
    Some reproducible builds with a confidential VM and use the digest of build artifacts might work.
- Kadin 4y 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.

cassonmars 4y 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 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 https://www.github.com/CassOnMars/Wesolowski-VDF).

zmgsabst 4y 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.
- cassonmars 4y 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 4y 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.

RealityVoid 4y ago

I'm reminded of this comment: https://news.ycombinator.com/item?id=31556968 https://news.ycombinator.com/item?id=31556968 The guy claims to be doing timelock using Galileo timestamps.

drdrek 4y 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.