11 ms·

Show HN: Timelock.dev – Send a secret into the future using timelock encryption

224 points by aarreedd 3y ago

This is simply a web interface built on top of the timelock encryption system posted by Cloudflare last week. https://blog.cloudflare.com/harnessing-office-chaos https://blog.cloudflare.com/harnessing-office-chaos

andix 3y ago
[flagged]
scosman 3y ago
[flagged]
- deleted 3y ago
  [deleted]
lucb1e 3y ago
The only way that I know to encrypt something into the future is generating an N-bit key and hoping someone will go through the trouble of cracking it when that becomes feasible. That involves lots of assumptions (e.g., how computing power develops and how much that person cares). The website's implementation is this: > A group of [orgs] holds the keys. There are 18 separate organizations running a total of 22 nodes, with a threshold of 12 needed to release a secret.
- buu700 3y ago
  That's an interesting idea. Similarly, you could make a sort of quantum time capsule by encrypting a blob of data with RSA or ECC and publishing the cyphertext alongside the public key. You could even adjust the key size depending on how powerful you want the quantum computer that decrypts it to be.
  - senordevnyc 3y ago
    [dead]
- dheera 3y ago
  The problem with "feasible" is that the time precision is poor. Feasibility is modulated by the value of the secret. If the secret exposes $1 billion in value, people will happily throw $100 million worth of compute at it. I'm not an expert on DeFi but could we do something more time-precise using the Ethereum blockchain and a smart contract?
  - lucb1e 3y ago
    > could we do something more time-precise using the Ethereum blockchain and a smart contract? I think only if you want a transaction to move forward at a certain time, and are confident that a majority of network members will not conspire to alter your smart contract. Hiding information in a smart contract: I don't know of a way that could be done, but I'm not up-to-date on this stuff either (I left that scene after Bitcoin outgrew the tech demo phase and became popular as a "so long as a majority keeps buying and holding, everyone's coins are worth insane amounts!" scheme)
  - Groxx 3y ago
    You might be able to implement this same kind of "have N cooperating message-senders that agree to do X at time Y or M of them can prove violation and penalize [probably everyone]", but you still need information that is not available until time Y. People / systems need to hold onto but not reveal that information until that time. This is basically weaponized (and possibly automated) enforcement of a rule. It's not crypto, it's just "agree to this or you get the lead pipe". Lead pipes are extremely useful and valuable and this is a completely reasonable tradeoff in a huge amount of situations, but it's not a true barrier. To get around the lead pipe requirement, you need some kind of data that exists but is technologically or physically inaccessible until time Y. Ethereum has no primitives like that because nobody has primitives like that. About the closest you get is to say "crack this public key to get the reward" and, yea, that's effectively time-lock encryption (it'll Y years with all the hardware in the world so it's "locked" for at least that long at 99% confidence or something) but nobody really considers it "time locked" unless you are intentionally designing a key to take Y time under Z hardware assumptions (which does exist, but a 1-PC-year key takes seconds with enough hardware).
- charcircuit 3y ago
  It's also tough to find good algorithms where you can't just spend double to half the time until it unlocks.
  - dave1010uk 3y ago
    There's not many. The Rivest, Shamir, and Wagner time lock algorithm is an example of one that can't be parallelized. In theory the NSA and Google can't brute force it much faster than you can on a laptop.
- montecarl 3y ago
  What you just wrote reminds me of the song Secrets From the Future by MC Frontalot. > You can’t hide secrets from the future with math > You can try, but I bet that in the future they laugh > At the half-assed schemes and algorithms amassed > To enforce cryptographs in the past
yogorenapan 3y ago
[flagged]
- pshirshov 3y ago
  Ergh, could you explain how did you come to this conclusion?
  - thewakalix 3y ago
    https://drand.love/docs/timelock-encryption/#%E2%9A%A0%EF%B8%8F-security-assumptions-%E2%9A%A0%EF%B8%8F https://drand.love/docs/timelock-encryption/#%E2%9A%A0%EF%B8...
    - pshirshov 3y ago
      This is not the same at all.
- littlestymaar 3y ago
  > wonder if a smart contract could be useful in this scenario It could not, at least with the capabilities of EVM or other mainstream smart-contract platform (I don't even thing it would be possible in theory but I may be wrong on this)
- adastra22 3y ago
  No it requires a threshold of 12 out of 18 keys to be acquired by an attacker. Jurisdictional resilience is the standard technique for preventing this kind of attack--e.g. having operators in the USA, Russia, Japan, Israel, Europe, South America, India, Singapore, etc.
- DistractionRect 3y ago
  I'm only vaguely familiar with the concept of smart contracts, but from what I understand I can't see how it'd fair any better at enabling cryptographic timelocks - the core problem is designing encryption which can't be broken before a set period has passed. The naive approach is requiring to make a scheme which assumes it'll take X amount of time to brute force with Y resources. That's obviously flawed because you can't constrain an enemies resources, and if the period is long there's plenty of room for improvement of algorithms/hardware which will shorten the time to brute force the scheme. This only works because we create a scheme which can't reasonably be brute forced by classical means, and a human organization enforces/controls the time period. In order to create something like that proposed in the posted link with smart contracts, the self contained smart contracts would have to employ a cryptographic timelock themselves. Otherwise, the smart contracts will be dependent on external (human) input, so it's just reinventing the same thing.
Jamustico 3y ago
Whats the point of this if it's not decentralized/algorithmic based. Who knows if this service will go down or something? Might aswell just do this with one entity m
- chews 3y ago
  HTLC would do the same in a distributed and trustless fashion and yet it's important to know League of Entropy is a bunch of distributed crypto organizations like Chainsafe or the Ethereum Foundation.
  - adastra22 3y ago
    I assume you mean a verifiable compute function rather than hash time-lock contract, as the latter can't be used for encryption. But that's not really a timelock either: it only sets a lower bound on the amount of compute required. But "compute" here is abstract, and when the conversion from "required hashes" to "time elapsed" can vary by 6-10 orders of magnitude, it stops having any appreciable meaning.
  - wuiheerfoj 3y ago
    EPFL, DEDIS, university of Chile, University College London and cloudflare aren’t crypto organisations
- adastra22 3y ago
  There is no decentralized algorithm for timelock encryption. No such scheme exists. Distributed is the best you're going to get without a radical breakthrough, and that's exactly what TFA is.
  - deleted 3y ago
    [deleted]
  - pjerem 3y ago
    Why ? If you wrap the message into multiple layers of encryption (TOR style) that needs to go into multiple nodes, and if alongside the next encrypted layer you have a date the nodes agrees to wait to pass the message to another node, that would work, no ? Even with some corrupted nodes, the message would still be secret, the only issue would be if the last nodes are corrupted : your message would be distributed too soon. But with enough layers and enough nodes to go through, you could mitigate this risk. The network could even detect corrupted nodes if other nodes received the message too soon.
troymc 3y ago
Here's a way to encrypt something with an actual timelock, which works because physics. More specifically, it works because there is a maximum speed that information can travel through space: the speed of light. Step 1: Generate a large number of named public/private keypairs and put the private keys on a spacecraft. Also give the spacecraft a communication system and a long-lived RTG (an energy source getting its energy from the decay of some radioactive materials). Step 2: Send the spacecraft to land on the surface a distant body in the solar system, such as one of the moons of Neptune. Step 3: To encrypt a message such that it's guaranteed to not be cracked in less than some specified time, encrypt it several times, using the known named public keys. To decrypt the message, you've got to send it out to the distant spacecraft and ask it to decrypt the outer layer of encryption, using the private key corresponding to the outer layer's public key. It does that and you get back a message but it might still have several layers of encryption. Repeat until all those layers are removed. There are tricks to speed things up by sending a spacecraft out towards Neptune, but they don't speed things up too much (because spacecraft travel much slower than light). The amount of speedup possible is left as an exercise for the reader. There's still a lower bound on the required time until full decryption. Inspired by the TOR network.
- dheera 3y ago
  > Generate a large number of named public/private keypairs and put the private keys on a spacecraft I suppose, more practically, you could just put the private key in an envelope and bury it deep in a shipping container with a destination across the ocean. While in transit it's pretty damn hard to get to it.
  - ttyprintk 3y ago
    There are a few geocaching approaches: Sunken chest / mysterious treasure map Beacon of high gamma radiation / undesirable to approach for many half lives USB key in Jimmy Hoffas pocket
    - lucb1e 3y ago
      My inner devil likes the "too dangerous to approach" idea :) About the last idea, I had to look up that name: > James Riddle Hoffa (born February 14, 1913; disappeared July 30, 1975; presumed dead July 30, 1982) was an American labor union leader who served as the president of the International Brotherhood of Teamsters (IBT) from 1957 until 1971. Do I read it correctly if I understand "Jimmy Hoffas pocket" to be one implementation example of "any disappeared person's pocket"? Or is the specific person, their role, or their era relevant?
falsandtru 3y ago
Reading the cited Cloudflare blog, it seems that the main purpose of this technology is public randomness, and timelock is one of its applications. Since timelock is not the essence of this technology, it is not surprising that the usefulness of timelock is unclear. > it’s become a reliable and production-ready core Internet service, relied upon by applications ranging from distributed file storage to online gaming to timestamped proofs to timelock encryption Details: https://drand.love/docs/timelock-encryption/ https://drand.love/docs/timelock-encryption/ Thread on the cited Cloudflare blog: https://news.ycombinator.com/item?id=39641475 https://news.ycombinator.com/item?id=39641475
- krackers 3y ago
  If I'm understanding the Drand protocol correctly, then isn't the following quote from the Cloudflare blog misleading? > Each organization contributes its own unique source of randomness into the joint pool of entropy used to seed the drand network – with Cloudflare using randomness from LavaRand, of course! It leads you to think that the each round's random value comes from "combining" local sources of entropy that each node contributes, but skimming the actual Drand protocol used, isn't it closer to something like using AES-CTR as a PRNG, except instead of AES it's some particular threshold-signature scheme. From another cloudflare post >To instantiate the required threshold signature scheme, drand uses the (t,n)-BLS signature scheme of Boneh, Lynn and Shacham. In particular, we can instantiate this scheme in the elliptic curve setting using Barreto-Naehrig curves. Moreover, the BLS signature scheme outputs sufficiently large signatures that are randomly distributed, giving them enough entropy to be sources of randomness. Specifically the signatures are randomly distributed over 64 bytes. So "real-world randomness" only is mixed in during the very initial distributed key generation phase, and after that everything is purely deterministic right? Or put another way those fancy lava lamps are a non-sequitur since this scheme doesn't seem to rely on their values beyond the initial key generation?
  - londons_explore 3y ago
    I don't believe any such time lock encryption can take on any entropy after the user messages are encrypted - since by definition, any entropy in that randomness is useless for decryption if it wasn't involved in the encryption.
deleted 3y ago
[deleted]
makach 3y ago
..but will it stand the test against time? for robustness, the message should include the decrypt algorithm what about integrity and time travelers? i.e., can decrypt but just messing around with time
Dibby053 3y ago
What does this solve that couldn't be solved by simply disclosing the decryption key oneself at the specified date?
- aarreedd 3y ago
  https://drand.love/docs/timelock-encryption/#use-cases https://drand.love/docs/timelock-encryption/#use-cases
- ghnws 3y ago
  Death, for example
tutfbhuf 3y ago
You can replace one or a few trusted third parties with an entire network of node operators (similar to the blockchain or Tor network) and achieve practical timelock encryption[^1]. As long as there are enough uncompromised nodes, you will be able to obtain your secret in the future. [^1]: https://github.com/drand/tlock https://github.com/drand/tlock
tl988008 3y ago
Actual timelock encryption, encrypted using parallel hashing and decrypted via forcing serial hashing: https://news.ycombinator.com/item?id=7848999 https://news.ycombinator.com/item?id=7848999
mothepro 3y ago
There are solutions which don’t require a third party. These would be guaranteed to survive in case a third party shuts down with a long duration. Paper: https://docs.google.com/document/d/e/2PACX-1vQe-OF0Lw9lutf6aBeSlVs0G09sSGX3XmBRQG7rkbxRvJeKZ22hH-O1zXU4Cvj8YXfi4r2N31GUc7cG/pub https://docs.google.com/document/d/e/2PACX-1vQe-OF0Lw9lutf6a...
- cowthulhu 3y ago
  The solution in that paper does require third parties, except the parties are unknown, the amount of parties is unknown, and the system breaks down if insufficient people are interested in running the chain. I’m really not convinced that solution is better is any way. If your adversary has the resources to coerce the “leave of entropy” in the OP, cracking that blockchain implementation will be trivial.
mellutussa 3y ago
[flagged]
- deleted 3y ago
  [deleted]
iskander 3y ago
Related: Verifiable Delay Function https://link.springer.com/article/10.1007/s00145-020-09364-x https://link.springer.com/article/10.1007/s00145-020-09364-x
- ttyprintk 3y ago
  Chia ran a contest for those: https://news.ycombinator.com/item?id=18437659 https://news.ycombinator.com/item?id=18437659
Swiffy0 3y ago
On another note, I think something like this should come with some kind of zero knowledge proof of the future encrypted thing being what it is claimed to be, so that one doesn't have to wait for a long time just for the secret to encrypt into nothing.
- aarreedd 3y ago
  That's a good point. Not sure how to do that right now
  - jasonmorton 3y ago
    You can ZK an XGBoost or neural net with https://github.com/zkonduit/ezkl https://github.com/zkonduit/ezkl
  - lukevalenta 3y ago
    Some folks from Chainsafe looked into it a couple years ago: https://github.com/nulltea/zk-timelock https://github.com/nulltea/zk-timelock. I'd love to see this work move forward.
victorbjorklund 3y ago
Very cool. Now I just need to find a reason to use it.
- littlecranky67 3y ago
  I used the very same mechanics (without the encryption, though) for lockmeout.online - for digital health/digital wellbeing to lock yourself out of your phone or addictive online accounts for a while.
bialpio 3y ago
This feels like Shamir's secret sharing with a pinky promise that "we won't decrypt things earlier", am I missing something?
- aarreedd 3y ago
  Yes, essentially. However, the 'pinky-promisers' are large, well-funded, geographically distributed organizations that have strong incentives, both in terms of reputation and operations, to keep their promise
  - bialpio 3y ago
    Gotcha, at first I was expecting something that tried to rely on some kind of physical limitation or a property that the passage of time has.
deleted 3y ago
[deleted]
neiman 3y ago
At first, I thought they used a cool new variation of something like VDF (Verifiable delay functions) or sequential proof of work to make a time lock. In these two options, you need to make a very long sequence of calculations to decrypt the message. Since the calculations cannot be parallized and since the sequence can be as long as you choose, it creates a time lock on the message. But no, they just use some kind of regular multi-sig/secret sharing.
- sterlind 3y ago
  hrm. I was going to say it's extremely wasteful, but since it's sequential I guess you're only burning one core. There's no computational arms race like with blockchain PoW. How does the math work? The decryption key is some kind of exponentiation you can compute directly with a trapdoor, but without the trapdoor you have to repeatedly multiply instead?
  - coppsilgold 3y ago
    You can just use desktop/laptop CPU accelerated sha256, iterate the round function for as long as you want. No hardware exists that can beat it on latency by any significant margin. Start with some random 256-bit string as the seed. Iterate on it for t time using sha256 CPU instructions - by either repeatedly hashing the seed or increasing the number of rounds to an arbitrary value (and do something about the round constants, such as removing them). After t time you stop and use the result to encrypt a message. You then publish the encrypted message and seed + number of rounds you ended up using. It will take t time before anyone can decrypt it. They will have to redo what you did, having multiple machines will not help in this task.
    - olejorgenb 3y ago
      But it also take t time to encrypt?
      - coppsilgold 3y ago
        To obtain the encryption key, yes. The trapdoor method is successive squaring and relies on quite a few assumptions for its security. The hash method also has the advantage that the sender can utilize multiple machines/cores in creating the encrypted package. By executing the serial hash task in parallel with all available resources and using the results of each chain to encrypt each other in another chain.[1] [1] <https://news.ycombinator.com/item?id=7848999 https://news.ycombinator.com/item?id=7848999>
Uptrenda 3y ago
The problem with time-lock encryption is you need to design a scheme that remains secure for the entire duration you target. As you know: technology changes rapidly so that if your time-lock is far ahead in the future its hard to predict what technological developments might exist to break it. - If you use repeated hashing (or other measures of lengthy computation to derive a key) there's no guarantee that future computers won't be able to run your algorithm much faster than you did. A problem that will probably show up quite early with schemes of this nature. - If you use the threshold approach listed here. Can you guarantee that the machines providing the service are still available when you need decryption? Moreso: that they don't end up being hacked between the encryption and decryption time-frames through some 0-day. - You could use a hardware device to protect the keys. But this would mean that the devices weren't compromised by hardware attacks. We have seen Bitcoin wallets fall to hardware attacks and trusted computing environments like enclaves have numerous attacks that can be used to compromise their contents. What makes time-lock encryption so challenging is you need a scheme that is intentionally weak so that's it's broken after a certain point. In cryptography that level of specificity isn't needed because schemes are designed to be well and truly secure past the life-times of all the subjects who use them. Even greater than the life of planets.
aarreedd 3y ago
FYI - this has used 33% of Cloudflare's daily free tier limit for workers since I posted this 3 hours ago. Every pageview and API call is an invocation. You get 100,000 calls per day for free.
- arch-choot 3y ago
  I'm not sure how intensive the "backend" is, but I've found stuff like workers to be economically efficient only for hobby tier projects. I operate a BitTorrent tracker I wrote for fun, and it receives around ~1500req/s (100mil+ a day) This would be ~US$18/day with CF workers, but costs me €3.8/mo on my VPS
klabb3 3y ago
You can also send secret messages to future crypto analysts: just encrypt your message with a random key and throw it away. Guaranteed to be delayed until the chosen primitives are broken.
TacticalCoder 3y ago
Rivest, Shamir and Wagner, 1996: "Time-lock puzzles and timed release Crypto" https://people.csail.mit.edu/rivest/pubs/RSW96.pdf https://people.csail.mit.edu/rivest/pubs/RSW96.pdf FWIW it took me about 3.3 years of computation (on one core, it's not parallelizable), from about 2015/2016ish to 2019, to find the solution to Rivest' LCS35 problem (which he created in 1999, so I found the solution 20 years after he created that LCS35 puzzle): https://en.wikipedia.org/wiki/LCS35 https://en.wikipedia.org/wiki/LCS35 An article on WIRED for anyone interested (I'm still rocking the same monitor and same keyboard!): https://www.wired.com/story/a-programmer-solved-a-20-year-old-forgotten-crypto-puzzle/ https://www.wired.com/story/a-programmer-solved-a-20-year-ol...
- lucb1e 3y ago
  > (on one core, it's not parallelizable) Why is that? From what I see on Wikipedia ("n is a specific 616-digit (or 2048-bit) integer that is the product of two large primes (which are not given)" sounds like a textbook RSA public key), it's an offline brute force challenge, a guessing game, so different computers (or cores) could independently take different slices of the guessing space. I will admit that prime factorization is one of my weak spots and I'll just resort to a few minutes of running pari-gp for that, since I know it uses some algorithm that is much better than brute force (it was orders of magnitude faster than alternatives for a CTF challenge involving a 512-bit RSA key). Even if the factorization process' time spent is dominated by finding the next prime to try, rather than testing a prime for correctness for example, why couldn't you start anywhere in the 2048-bit space and find the next primes from there? Is there something you can use from the ciphertext that makes you need to start at a certain point and generate (single core) from there onwards? It sounds like the holy grail for key strengthening without memory trade-off options like scrypt and argon2 both struggle with
  - adastra22 3y ago
    From the actual problem description: Note that the puzzle can be solved by performing t successive squarings modulo n, beginning with the value 2. That is, set W(0) = 2 W(i+1) = (W(i) ^ 2) (mod n) for i=1, 2, ... and compute W(t). There is no known way to perform this computation more quickly than to perform the t squarings sequentially, unless the factorization of n is known.
instantiator 3y ago
Related - how do you send a message into the future with conditional release? A dissertation on Dead ~~Man~~ Person Switches... https://instantiator.dev/post/dead-person-switch/ https://instantiator.dev/post/dead-person-switch/
lumpa 3y ago
There's an interesting bit about being unable to recover the timelocked secret if the parties that keep the network going disband before the release date: *if the League of Entropy shuts down, members will delete their keys* The world is unpredictable (just like drand randomness... heh), and it's possible that the League of Entropy will all hang up their coats at some point in the future. Should that happen, members would have two choices with their private keys: release them to the world or delete them entirely. The former would mean that ciphertexts created for some time after the cessation of the network would be decryptable to everybody. The latter would mean that ciphertexts created for some time after the cessation of the network would be unencryptable forever (/until quantum computers can break them). In the interests of privacy, we felt the latter option was preferable. That said, if you encrypt the private key to your [insert cryptocurrency name] fortune to stop yourself from spending it now and the network stops... you're going to have a bad time.
BigParm 3y ago
It’s an interesting property of the universe that there’s no way to measure time directly. It clearly exists, yet all you can measure is change of things besides time. Time lock puzzles take variable time depending on hardware. You can’t really set an accurate specific release time. Any change in the universe that a computer can detect is just another spoofable input. Blockchain tries to solve essentially the same problem but the best it can reliably do is establish a chronology. That’s not a specific time. And it has fundamental vulnerabilities, however unlikely you think they are to be exploited in established systems. Intel is building proof of elapsed time into their chips but that’s not trustless. Timelock puzzles and blockchain are imo hacky solutions to one of the most important outstanding problems in cryptography: securely and trustlessly agreeing on elapsed time.
- throwaway69123 3y ago
  What about time crystals? https://en.wikipedia.org/wiki/Time_crystal https://en.wikipedia.org/wiki/Time_crystal
  - idiotsecant 3y ago
    Time crystals aren't the only thing that has properties that change in an orderly, predictable fashion. Plain old uranium has the same property. The answer to both is the same - put them on a very fast rocket and do a lap around the galaxy and see how well they agree with you on how much time has elapsed.
    - illiac786 3y ago
      Is it not rather that time does not elapse everywhere at he same speed, simply put? Based on this, of course, measuring it becomes difficult. It's akin to measuring gravity. You can — for a specific point in space and time. (Time is even worse, since it is specific to a given _trajectory_ in space) But I have no idea what Im talking about.
      - ben_w 3y ago
jerrygoyal 3y ago
i wonder what could be the most interesting use case of this?
kaangiray26 3y ago
If being crackable during the time period is a concern, why not just use OTP (one-time pad, not his evil twin) and create XORed multiple keys to be shared with peers, and then use all of the distributed keys to reveal the message after some time had passed?
- AgentME 3y ago
  Some people do timelock encryption by using weak cryptography that's expected to be broken in a planned amount of time, but this project isn't doing that. It uses modern cryptography to encrypt some data to a set of public keys so that 18 of 22 nodes have to cooperate to decrypt it. Anything encrypted with modern cryptography isn't expected to be crackable in under millions of years. Their design has the benefit over yours that people don't need to send data to peers in order to timelock some data. The timelock only needs to be sent to the peers for decryption.
  - kaangiray26 3y ago
    Your last sentence seems just the same to me. I believe that saying something can't be cracked in under millions of years is analogous to saying that no advancements will be made in those years.
jslakro 3y ago
The only problem I have with this kind of tools/experiments is that you can begin to use it then in one or two years the domain expires and everything is over
- crotchfire 3y ago
  I have that problem with the whole internet these days. ICANN is a cancer.
- aarreedd 3y ago
  You can run the decryption locally. The code is on git. The bigger concern is that the League of Entropy will disband and delete their keys permanently.
denton-scratch 3y ago
So Cloudflare suggests there are two ways of doing timelock encryption: you can rely on some proxy for the passage of time, such as repeated hashing; or you can rely on one or more trusted agents. I don't think the 'proxy' approach is timelock encryption, because it doesn't actually rely on the passage of time. Cloudflare is relying on a network of trusted agents that 'tick' at a predictable rate. I think I wouldn't want to rely on this network of trusted agents to preserve a long-lived secret. There's no guarantee that the network will still exist when it's time to reveal thw secret. Is there a way to do timelock encryption that doesn't involve reliance on a third-party, and that really depends on the actual time, rather than on a proxy for time? I cn't see it, but I'm not very clever.
- kaangiray26 3y ago
  It's funny just thinking about it. Because if you are not depending on a third-party, then you are depending on yourself only. Which means that once you encrypt something hoping that you won't be able to decrypt for some amount of time, you accept that changing of the time has something to do with the decryption of your encrypted message. Since you can certainly know how much of time should be pass, you can't keep secrets from yourself right? So, in a sense, in my opinion, if you want to encrypt a message and send it to someone and make it timelocked without a third-party, you might as well just keep the message secret until the desired amount of time has passed and just give it to him.
  - denton-scratch 3y ago
    Well, the use-case I have in mind is that I want to convey a message to (say) my granddaughter, on or after her 21st birthday. I'll be long-gone. There's no point in encrypting a secret to protect it from my own eyes; I already know the secret.
racheljaneville 3y ago
[dead]
christenchrist 3y ago
[dead]

224 points by aarreedd 3y ago

andix 3y ago

[flagged]

scosman 3y ago

[flagged]

deleted 3y ago
[deleted]

lucb1e 3y ago

The only way that I know to encrypt something into the future is generating an N-bit key and hoping someone will go through the trouble of cracking it when that becomes feasible. That involves lots of assumptions (e.g., how computing power develops and how much that person cares). The website's implementation is this: > A group of [orgs] holds the keys. There are 18 separate organizations running a total of 22 nodes, with a threshold of 12 needed to release a secret.

buu700 3y ago
That's an interesting idea. Similarly, you could make a sort of quantum time capsule by encrypting a blob of data with RSA or ECC and publishing the cyphertext alongside the public key. You could even adjust the key size depending on how powerful you want the quantum computer that decrypts it to be.
- senordevnyc 3y ago
  [dead]
dheera 3y ago
The problem with "feasible" is that the time precision is poor. Feasibility is modulated by the value of the secret. If the secret exposes $1 billion in value, people will happily throw $100 million worth of compute at it. I'm not an expert on DeFi but could we do something more time-precise using the Ethereum blockchain and a smart contract?
- lucb1e 3y ago
  > could we do something more time-precise using the Ethereum blockchain and a smart contract? I think only if you want a transaction to move forward at a certain time, and are confident that a majority of network members will not conspire to alter your smart contract. Hiding information in a smart contract: I don't know of a way that could be done, but I'm not up-to-date on this stuff either (I left that scene after Bitcoin outgrew the tech demo phase and became popular as a "so long as a majority keeps buying and holding, everyone's coins are worth insane amounts!" scheme)
- Groxx 3y ago
  You might be able to implement this same kind of "have N cooperating message-senders that agree to do X at time Y or M of them can prove violation and penalize [probably everyone]", but you still need information that is not available until time Y. People / systems need to hold onto but not reveal that information until that time. This is basically weaponized (and possibly automated) enforcement of a rule. It's not crypto, it's just "agree to this or you get the lead pipe". Lead pipes are extremely useful and valuable and this is a completely reasonable tradeoff in a huge amount of situations, but it's not a true barrier. To get around the lead pipe requirement, you need some kind of data that exists but is technologically or physically inaccessible until time Y. Ethereum has no primitives like that because nobody has primitives like that. About the closest you get is to say "crack this public key to get the reward" and, yea, that's effectively time-lock encryption (it'll Y years with all the hardware in the world so it's "locked" for at least that long at 99% confidence or something) but nobody really considers it "time locked" unless you are intentionally designing a key to take Y time under Z hardware assumptions (which does exist, but a 1-PC-year key takes seconds with enough hardware).
charcircuit 3y ago
It's also tough to find good algorithms where you can't just spend double to half the time until it unlocks.
- dave1010uk 3y ago
  There's not many. The Rivest, Shamir, and Wagner time lock algorithm is an example of one that can't be parallelized. In theory the NSA and Google can't brute force it much faster than you can on a laptop.
montecarl 3y ago
What you just wrote reminds me of the song Secrets From the Future by MC Frontalot. > You can’t hide secrets from the future with math > You can try, but I bet that in the future they laugh > At the half-assed schemes and algorithms amassed > To enforce cryptographs in the past

yogorenapan 3y ago

[flagged]

pshirshov 3y ago
Ergh, could you explain how did you come to this conclusion?
- thewakalix 3y ago
  https://drand.love/docs/timelock-encryption/#%E2%9A%A0%EF%B8%8F-security-assumptions-%E2%9A%A0%EF%B8%8F https://drand.love/docs/timelock-encryption/#%E2%9A%A0%EF%B8...
  - pshirshov 3y ago
    This is not the same at all.
littlestymaar 3y ago
> wonder if a smart contract could be useful in this scenario It could not, at least with the capabilities of EVM or other mainstream smart-contract platform (I don't even thing it would be possible in theory but I may be wrong on this)
adastra22 3y ago
No it requires a threshold of 12 out of 18 keys to be acquired by an attacker. Jurisdictional resilience is the standard technique for preventing this kind of attack--e.g. having operators in the USA, Russia, Japan, Israel, Europe, South America, India, Singapore, etc.
DistractionRect 3y ago
I'm only vaguely familiar with the concept of smart contracts, but from what I understand I can't see how it'd fair any better at enabling cryptographic timelocks - the core problem is designing encryption which can't be broken before a set period has passed. The naive approach is requiring to make a scheme which assumes it'll take X amount of time to brute force with Y resources. That's obviously flawed because you can't constrain an enemies resources, and if the period is long there's plenty of room for improvement of algorithms/hardware which will shorten the time to brute force the scheme. This only works because we create a scheme which can't reasonably be brute forced by classical means, and a human organization enforces/controls the time period. In order to create something like that proposed in the posted link with smart contracts, the self contained smart contracts would have to employ a cryptographic timelock themselves. Otherwise, the smart contracts will be dependent on external (human) input, so it's just reinventing the same thing.

Jamustico 3y ago

Whats the point of this if it's not decentralized/algorithmic based. Who knows if this service will go down or something? Might aswell just do this with one entity m

chews 3y ago
HTLC would do the same in a distributed and trustless fashion and yet it's important to know League of Entropy is a bunch of distributed crypto organizations like Chainsafe or the Ethereum Foundation.
- adastra22 3y ago
  I assume you mean a verifiable compute function rather than hash time-lock contract, as the latter can't be used for encryption. But that's not really a timelock either: it only sets a lower bound on the amount of compute required. But "compute" here is abstract, and when the conversion from "required hashes" to "time elapsed" can vary by 6-10 orders of magnitude, it stops having any appreciable meaning.
- wuiheerfoj 3y ago
  EPFL, DEDIS, university of Chile, University College London and cloudflare aren’t crypto organisations
adastra22 3y ago
There is no decentralized algorithm for timelock encryption. No such scheme exists. Distributed is the best you're going to get without a radical breakthrough, and that's exactly what TFA is.
- deleted 3y ago
  [deleted]
- pjerem 3y ago
  Why ? If you wrap the message into multiple layers of encryption (TOR style) that needs to go into multiple nodes, and if alongside the next encrypted layer you have a date the nodes agrees to wait to pass the message to another node, that would work, no ? Even with some corrupted nodes, the message would still be secret, the only issue would be if the last nodes are corrupted : your message would be distributed too soon. But with enough layers and enough nodes to go through, you could mitigate this risk. The network could even detect corrupted nodes if other nodes received the message too soon.

troymc 3y ago

Here's a way to encrypt something with an actual timelock, which works because physics. More specifically, it works because there is a maximum speed that information can travel through space: the speed of light. Step 1: Generate a large number of named public/private keypairs and put the private keys on a spacecraft. Also give the spacecraft a communication system and a long-lived RTG (an energy source getting its energy from the decay of some radioactive materials). Step 2: Send the spacecraft to land on the surface a distant body in the solar system, such as one of the moons of Neptune. Step 3: To encrypt a message such that it's guaranteed to not be cracked in less than some specified time, encrypt it several times, using the known named public keys. To decrypt the message, you've got to send it out to the distant spacecraft and ask it to decrypt the outer layer of encryption, using the private key corresponding to the outer layer's public key. It does that and you get back a message but it might still have several layers of encryption. Repeat until all those layers are removed. There are tricks to speed things up by sending a spacecraft out towards Neptune, but they don't speed things up too much (because spacecraft travel much slower than light). The amount of speedup possible is left as an exercise for the reader. There's still a lower bound on the required time until full decryption. Inspired by the TOR network.

dheera 3y ago
> Generate a large number of named public/private keypairs and put the private keys on a spacecraft I suppose, more practically, you could just put the private key in an envelope and bury it deep in a shipping container with a destination across the ocean. While in transit it's pretty damn hard to get to it.
- ttyprintk 3y ago
  There are a few geocaching approaches: Sunken chest / mysterious treasure map Beacon of high gamma radiation / undesirable to approach for many half lives USB key in Jimmy Hoffas pocket
  - lucb1e 3y ago
    My inner devil likes the "too dangerous to approach" idea :) About the last idea, I had to look up that name: > James Riddle Hoffa (born February 14, 1913; disappeared July 30, 1975; presumed dead July 30, 1982) was an American labor union leader who served as the president of the International Brotherhood of Teamsters (IBT) from 1957 until 1971. Do I read it correctly if I understand "Jimmy Hoffas pocket" to be one implementation example of "any disappeared person's pocket"? Or is the specific person, their role, or their era relevant?

falsandtru 3y ago

Reading the cited Cloudflare blog, it seems that the main purpose of this technology is public randomness, and timelock is one of its applications. Since timelock is not the essence of this technology, it is not surprising that the usefulness of timelock is unclear. > it’s become a reliable and production-ready core Internet service, relied upon by applications ranging from distributed file storage to online gaming to timestamped proofs to timelock encryption Details: https://drand.love/docs/timelock-encryption/ https://drand.love/docs/timelock-encryption/ Thread on the cited Cloudflare blog: https://news.ycombinator.com/item?id=39641475 https://news.ycombinator.com/item?id=39641475

krackers 3y ago
If I'm understanding the Drand protocol correctly, then isn't the following quote from the Cloudflare blog misleading? > Each organization contributes its own unique source of randomness into the joint pool of entropy used to seed the drand network – with Cloudflare using randomness from LavaRand, of course! It leads you to think that the each round's random value comes from "combining" local sources of entropy that each node contributes, but skimming the actual Drand protocol used, isn't it closer to something like using AES-CTR as a PRNG, except instead of AES it's some particular threshold-signature scheme. From another cloudflare post >To instantiate the required threshold signature scheme, drand uses the (t,n)-BLS signature scheme of Boneh, Lynn and Shacham. In particular, we can instantiate this scheme in the elliptic curve setting using Barreto-Naehrig curves. Moreover, the BLS signature scheme outputs sufficiently large signatures that are randomly distributed, giving them enough entropy to be sources of randomness. Specifically the signatures are randomly distributed over 64 bytes. So "real-world randomness" only is mixed in during the very initial distributed key generation phase, and after that everything is purely deterministic right? Or put another way those fancy lava lamps are a non-sequitur since this scheme doesn't seem to rely on their values beyond the initial key generation?
- londons_explore 3y ago
  I don't believe any such time lock encryption can take on any entropy after the user messages are encrypted - since by definition, any entropy in that randomness is useless for decryption if it wasn't involved in the encryption.

deleted 3y ago

[deleted]

makach 3y ago

..but will it stand the test against time? for robustness, the message should include the decrypt algorithm what about integrity and time travelers? i.e., can decrypt but just messing around with time

Dibby053 3y ago

What does this solve that couldn't be solved by simply disclosing the decryption key oneself at the specified date?

aarreedd 3y ago
https://drand.love/docs/timelock-encryption/#use-cases https://drand.love/docs/timelock-encryption/#use-cases
ghnws 3y ago
Death, for example

tutfbhuf 3y ago

You can replace one or a few trusted third parties with an entire network of node operators (similar to the blockchain or Tor network) and achieve practical timelock encryption[^1]. As long as there are enough uncompromised nodes, you will be able to obtain your secret in the future. [^1]: https://github.com/drand/tlock https://github.com/drand/tlock

tl988008 3y ago

Actual timelock encryption, encrypted using parallel hashing and decrypted via forcing serial hashing: https://news.ycombinator.com/item?id=7848999 https://news.ycombinator.com/item?id=7848999

mothepro 3y ago

There are solutions which don’t require a third party. These would be guaranteed to survive in case a third party shuts down with a long duration. Paper: https://docs.google.com/document/d/e/2PACX-1vQe-OF0Lw9lutf6aBeSlVs0G09sSGX3XmBRQG7rkbxRvJeKZ22hH-O1zXU4Cvj8YXfi4r2N31GUc7cG/pub https://docs.google.com/document/d/e/2PACX-1vQe-OF0Lw9lutf6a...

cowthulhu 3y ago
The solution in that paper does require third parties, except the parties are unknown, the amount of parties is unknown, and the system breaks down if insufficient people are interested in running the chain. I’m really not convinced that solution is better is any way. If your adversary has the resources to coerce the “leave of entropy” in the OP, cracking that blockchain implementation will be trivial.

mellutussa 3y ago

[flagged]

deleted 3y ago
[deleted]

iskander 3y ago

Related: Verifiable Delay Function https://link.springer.com/article/10.1007/s00145-020-09364-x https://link.springer.com/article/10.1007/s00145-020-09364-x

ttyprintk 3y ago
Chia ran a contest for those: https://news.ycombinator.com/item?id=18437659 https://news.ycombinator.com/item?id=18437659

Swiffy0 3y ago

On another note, I think something like this should come with some kind of zero knowledge proof of the future encrypted thing being what it is claimed to be, so that one doesn't have to wait for a long time just for the secret to encrypt into nothing.

aarreedd 3y ago
That's a good point. Not sure how to do that right now
- jasonmorton 3y ago
  You can ZK an XGBoost or neural net with https://github.com/zkonduit/ezkl https://github.com/zkonduit/ezkl
- lukevalenta 3y ago
  Some folks from Chainsafe looked into it a couple years ago: https://github.com/nulltea/zk-timelock https://github.com/nulltea/zk-timelock. I'd love to see this work move forward.

victorbjorklund 3y ago

Very cool. Now I just need to find a reason to use it.

littlecranky67 3y ago
I used the very same mechanics (without the encryption, though) for lockmeout.online - for digital health/digital wellbeing to lock yourself out of your phone or addictive online accounts for a while.

bialpio 3y ago

This feels like Shamir's secret sharing with a pinky promise that "we won't decrypt things earlier", am I missing something?

aarreedd 3y ago
Yes, essentially. However, the 'pinky-promisers' are large, well-funded, geographically distributed organizations that have strong incentives, both in terms of reputation and operations, to keep their promise
- bialpio 3y ago
  Gotcha, at first I was expecting something that tried to rely on some kind of physical limitation or a property that the passage of time has.

deleted 3y ago

[deleted]

neiman 3y ago

At first, I thought they used a cool new variation of something like VDF (Verifiable delay functions) or sequential proof of work to make a time lock. In these two options, you need to make a very long sequence of calculations to decrypt the message. Since the calculations cannot be parallized and since the sequence can be as long as you choose, it creates a time lock on the message. But no, they just use some kind of regular multi-sig/secret sharing.

sterlind 3y ago
hrm. I was going to say it's extremely wasteful, but since it's sequential I guess you're only burning one core. There's no computational arms race like with blockchain PoW. How does the math work? The decryption key is some kind of exponentiation you can compute directly with a trapdoor, but without the trapdoor you have to repeatedly multiply instead?
- coppsilgold 3y ago
  You can just use desktop/laptop CPU accelerated sha256, iterate the round function for as long as you want. No hardware exists that can beat it on latency by any significant margin. Start with some random 256-bit string as the seed. Iterate on it for t time using sha256 CPU instructions - by either repeatedly hashing the seed or increasing the number of rounds to an arbitrary value (and do something about the round constants, such as removing them). After t time you stop and use the result to encrypt a message. You then publish the encrypted message and seed + number of rounds you ended up using. It will take t time before anyone can decrypt it. They will have to redo what you did, having multiple machines will not help in this task.
  - olejorgenb 3y ago
    But it also take t time to encrypt?
    - coppsilgold 3y ago
      To obtain the encryption key, yes. The trapdoor method is successive squaring and relies on quite a few assumptions for its security. The hash method also has the advantage that the sender can utilize multiple machines/cores in creating the encrypted package. By executing the serial hash task in parallel with all available resources and using the results of each chain to encrypt each other in another chain.[1] [1] <https://news.ycombinator.com/item?id=7848999 https://news.ycombinator.com/item?id=7848999>

Uptrenda 3y ago

The problem with time-lock encryption is you need to design a scheme that remains secure for the entire duration you target. As you know: technology changes rapidly so that if your time-lock is far ahead in the future its hard to predict what technological developments might exist to break it. - If you use repeated hashing (or other measures of lengthy computation to derive a key) there's no guarantee that future computers won't be able to run your algorithm much faster than you did. A problem that will probably show up quite early with schemes of this nature. - If you use the threshold approach listed here. Can you guarantee that the machines providing the service are still available when you need decryption? Moreso: that they don't end up being hacked between the encryption and decryption time-frames through some 0-day. - You could use a hardware device to protect the keys. But this would mean that the devices weren't compromised by hardware attacks. We have seen Bitcoin wallets fall to hardware attacks and trusted computing environments like enclaves have numerous attacks that can be used to compromise their contents. What makes time-lock encryption so challenging is you need a scheme that is intentionally weak so that's it's broken after a certain point. In cryptography that level of specificity isn't needed because schemes are designed to be well and truly secure past the life-times of all the subjects who use them. Even greater than the life of planets.

aarreedd 3y ago

FYI - this has used 33% of Cloudflare's daily free tier limit for workers since I posted this 3 hours ago. Every pageview and API call is an invocation. You get 100,000 calls per day for free.

arch-choot 3y ago
I'm not sure how intensive the "backend" is, but I've found stuff like workers to be economically efficient only for hobby tier projects. I operate a BitTorrent tracker I wrote for fun, and it receives around ~1500req/s (100mil+ a day) This would be ~US$18/day with CF workers, but costs me €3.8/mo on my VPS

klabb3 3y ago

You can also send secret messages to future crypto analysts: just encrypt your message with a random key and throw it away. Guaranteed to be delayed until the chosen primitives are broken.

TacticalCoder 3y ago

Rivest, Shamir and Wagner, 1996: "Time-lock puzzles and timed release Crypto" https://people.csail.mit.edu/rivest/pubs/RSW96.pdf https://people.csail.mit.edu/rivest/pubs/RSW96.pdf FWIW it took me about 3.3 years of computation (on one core, it's not parallelizable), from about 2015/2016ish to 2019, to find the solution to Rivest' LCS35 problem (which he created in 1999, so I found the solution 20 years after he created that LCS35 puzzle): https://en.wikipedia.org/wiki/LCS35 https://en.wikipedia.org/wiki/LCS35 An article on WIRED for anyone interested (I'm still rocking the same monitor and same keyboard!): https://www.wired.com/story/a-programmer-solved-a-20-year-old-forgotten-crypto-puzzle/ https://www.wired.com/story/a-programmer-solved-a-20-year-ol...

lucb1e 3y ago
> (on one core, it's not parallelizable) Why is that? From what I see on Wikipedia ("n is a specific 616-digit (or 2048-bit) integer that is the product of two large primes (which are not given)" sounds like a textbook RSA public key), it's an offline brute force challenge, a guessing game, so different computers (or cores) could independently take different slices of the guessing space. I will admit that prime factorization is one of my weak spots and I'll just resort to a few minutes of running pari-gp for that, since I know it uses some algorithm that is much better than brute force (it was orders of magnitude faster than alternatives for a CTF challenge involving a 512-bit RSA key). Even if the factorization process' time spent is dominated by finding the next prime to try, rather than testing a prime for correctness for example, why couldn't you start anywhere in the 2048-bit space and find the next primes from there? Is there something you can use from the ciphertext that makes you need to start at a certain point and generate (single core) from there onwards? It sounds like the holy grail for key strengthening without memory trade-off options like scrypt and argon2 both struggle with
- adastra22 3y ago
  From the actual problem description: Note that the puzzle can be solved by performing t successive squarings modulo n, beginning with the value 2. That is, set W(0) = 2 W(i+1) = (W(i) ^ 2) (mod n) for i=1, 2, ... and compute W(t). There is no known way to perform this computation more quickly than to perform the t squarings sequentially, unless the factorization of n is known.

instantiator 3y ago

Related - how do you send a message into the future with conditional release? A dissertation on Dead ~~Man~~ Person Switches... https://instantiator.dev/post/dead-person-switch/ https://instantiator.dev/post/dead-person-switch/

lumpa 3y ago

There's an interesting bit about being unable to recover the timelocked secret if the parties that keep the network going disband before the release date: *if the League of Entropy shuts down, members will delete their keys* The world is unpredictable (just like drand randomness... heh), and it's possible that the League of Entropy will all hang up their coats at some point in the future. Should that happen, members would have two choices with their private keys: release them to the world or delete them entirely. The former would mean that ciphertexts created for some time after the cessation of the network would be decryptable to everybody. The latter would mean that ciphertexts created for some time after the cessation of the network would be unencryptable forever (/until quantum computers can break them). In the interests of privacy, we felt the latter option was preferable. That said, if you encrypt the private key to your [insert cryptocurrency name] fortune to stop yourself from spending it now and the network stops... you're going to have a bad time.

BigParm 3y ago

It’s an interesting property of the universe that there’s no way to measure time directly. It clearly exists, yet all you can measure is change of things besides time. Time lock puzzles take variable time depending on hardware. You can’t really set an accurate specific release time. Any change in the universe that a computer can detect is just another spoofable input. Blockchain tries to solve essentially the same problem but the best it can reliably do is establish a chronology. That’s not a specific time. And it has fundamental vulnerabilities, however unlikely you think they are to be exploited in established systems. Intel is building proof of elapsed time into their chips but that’s not trustless. Timelock puzzles and blockchain are imo hacky solutions to one of the most important outstanding problems in cryptography: securely and trustlessly agreeing on elapsed time.

throwaway69123 3y ago
What about time crystals? https://en.wikipedia.org/wiki/Time_crystal https://en.wikipedia.org/wiki/Time_crystal
- idiotsecant 3y ago
  Time crystals aren't the only thing that has properties that change in an orderly, predictable fashion. Plain old uranium has the same property. The answer to both is the same - put them on a very fast rocket and do a lap around the galaxy and see how well they agree with you on how much time has elapsed.
  - illiac786 3y ago
    Is it not rather that time does not elapse everywhere at he same speed, simply put? Based on this, of course, measuring it becomes difficult. It's akin to measuring gravity. You can — for a specific point in space and time. (Time is even worse, since it is specific to a given _trajectory_ in space) But I have no idea what Im talking about.
    - ben_w 3y ago

jerrygoyal 3y ago

i wonder what could be the most interesting use case of this?

kaangiray26 3y ago

If being crackable during the time period is a concern, why not just use OTP (one-time pad, not his evil twin) and create XORed multiple keys to be shared with peers, and then use all of the distributed keys to reveal the message after some time had passed?

AgentME 3y ago
Some people do timelock encryption by using weak cryptography that's expected to be broken in a planned amount of time, but this project isn't doing that. It uses modern cryptography to encrypt some data to a set of public keys so that 18 of 22 nodes have to cooperate to decrypt it. Anything encrypted with modern cryptography isn't expected to be crackable in under millions of years. Their design has the benefit over yours that people don't need to send data to peers in order to timelock some data. The timelock only needs to be sent to the peers for decryption.
- kaangiray26 3y ago
  Your last sentence seems just the same to me. I believe that saying something can't be cracked in under millions of years is analogous to saying that no advancements will be made in those years.

jslakro 3y ago

The only problem I have with this kind of tools/experiments is that you can begin to use it then in one or two years the domain expires and everything is over

crotchfire 3y ago
I have that problem with the whole internet these days. ICANN is a cancer.
aarreedd 3y ago
You can run the decryption locally. The code is on git. The bigger concern is that the League of Entropy will disband and delete their keys permanently.

denton-scratch 3y ago

So Cloudflare suggests there are two ways of doing timelock encryption: you can rely on some proxy for the passage of time, such as repeated hashing; or you can rely on one or more trusted agents. I don't think the 'proxy' approach is timelock encryption, because it doesn't actually rely on the passage of time. Cloudflare is relying on a network of trusted agents that 'tick' at a predictable rate. I think I wouldn't want to rely on this network of trusted agents to preserve a long-lived secret. There's no guarantee that the network will still exist when it's time to reveal thw secret. Is there a way to do timelock encryption that doesn't involve reliance on a third-party, and that really depends on the actual time, rather than on a proxy for time? I cn't see it, but I'm not very clever.

kaangiray26 3y ago
It's funny just thinking about it. Because if you are not depending on a third-party, then you are depending on yourself only. Which means that once you encrypt something hoping that you won't be able to decrypt for some amount of time, you accept that changing of the time has something to do with the decryption of your encrypted message. Since you can certainly know how much of time should be pass, you can't keep secrets from yourself right? So, in a sense, in my opinion, if you want to encrypt a message and send it to someone and make it timelocked without a third-party, you might as well just keep the message secret until the desired amount of time has passed and just give it to him.
- denton-scratch 3y ago
  Well, the use-case I have in mind is that I want to convey a message to (say) my granddaughter, on or after her 21st birthday. I'll be long-gone. There's no point in encrypting a secret to protect it from my own eyes; I already know the secret.

racheljaneville 3y ago

[dead]

christenchrist 3y ago

[dead]