TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

224 点作者 aarreedd大约 1 年前
This is simply a web interface built on top of the timelock encryption system posted by Cloudflare last week. <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;harnessing-office-chaos" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;harnessing-office-chaos</a>

25 条评论

TacticalCoder大约 1 年前
Rivest, Shamir and Wagner, 1996:<p><i>&quot;Time-lock puzzles and timed release Crypto&quot;</i><p><a href="https:&#x2F;&#x2F;people.csail.mit.edu&#x2F;rivest&#x2F;pubs&#x2F;RSW96.pdf" rel="nofollow">https:&#x2F;&#x2F;people.csail.mit.edu&#x2F;rivest&#x2F;pubs&#x2F;RSW96.pdf</a><p>FWIW it took me about 3.3 years of computation (on one core, it&#x27;s not parallelizable), from about 2015&#x2F;2016ish to 2019, to find the solution to Rivest&#x27; LCS35 problem (which he created in 1999, so I found the solution 20 years after he created that LCS35 puzzle):<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;LCS35" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;LCS35</a><p>An article on WIRED for anyone interested (I&#x27;m still rocking the same monitor and same keyboard!):<p><a href="https:&#x2F;&#x2F;www.wired.com&#x2F;story&#x2F;a-programmer-solved-a-20-year-old-forgotten-crypto-puzzle&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.wired.com&#x2F;story&#x2F;a-programmer-solved-a-20-year-ol...</a>
评论 #39664309 未加载
评论 #39664714 未加载
BigParm大约 1 年前
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.<p>Time lock puzzles take variable time depending on hardware. You can’t really set an accurate specific release time.<p>Any change in the universe that a computer can detect is just another spoofable input.<p>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.<p>Intel is building proof of elapsed time into their chips but that’s not trustless.<p>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.
评论 #39666185 未加载
评论 #39664543 未加载
评论 #39668169 未加载
评论 #39665990 未加载
lumpa大约 1 年前
There&#x27;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:<p><pre><code> *if the League of Entropy shuts down, members will delete their keys* The world is unpredictable (just like drand randomness... heh), and it&#x27;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 (&#x2F;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&#x27;re going to have a bad time.</code></pre>
lucb1e大约 1 年前
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).<p>The website&#x27;s implementation is this:<p>&gt; 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.
评论 #39664914 未加载
评论 #39662259 未加载
评论 #39662151 未加载
评论 #39662133 未加载
falsandtru大约 1 年前
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.<p>&gt; 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<p>Details: <a href="https:&#x2F;&#x2F;drand.love&#x2F;docs&#x2F;timelock-encryption&#x2F;" rel="nofollow">https:&#x2F;&#x2F;drand.love&#x2F;docs&#x2F;timelock-encryption&#x2F;</a><p>Thread on the cited Cloudflare blog: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39641475">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39641475</a>
评论 #39663366 未加载
denton-scratch大约 1 年前
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.<p>I don&#x27;t think the &#x27;proxy&#x27; approach is timelock encryption, because it doesn&#x27;t actually rely on the passage of time. Cloudflare is relying on a network of trusted agents that &#x27;tick&#x27; at a predictable rate.<p>I think I wouldn&#x27;t want to rely on this network of trusted agents to preserve a long-lived secret. There&#x27;s no guarantee that the network will still exist when it&#x27;s time to reveal thw secret.<p>Is there a way to do timelock encryption that doesn&#x27;t involve reliance on a third-party, and that really depends on the actual time, rather than on a proxy for time? I cn&#x27;t see it, but I&#x27;m not very clever.
评论 #39667286 未加载
Uptrenda大约 1 年前
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.<p>- If you use repeated hashing (or other measures of lengthy computation to derive a key) there&#x27;s no guarantee that future computers won&#x27;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.<p>- 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&#x27;t end up being hacked between the encryption and decryption time-frames through some 0-day.<p>- You could use a hardware device to protect the keys. But this would mean that the devices weren&#x27;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.<p>What makes time-lock encryption so challenging is you need a scheme that is intentionally weak so that&#x27;s it&#x27;s broken after a certain point. In cryptography that level of specificity isn&#x27;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.
bialpio大约 1 年前
This feels like Shamir&#x27;s secret sharing with a pinky promise that &quot;we won&#x27;t decrypt things earlier&quot;, am I missing something?
评论 #39662897 未加载
Swiffy0大约 1 年前
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&#x27;t have to wait for a long time just for the secret to encrypt into nothing.
评论 #39662616 未加载
neiman大约 1 年前
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.<p>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.<p>But no, they just use some kind of regular multi-sig&#x2F;secret sharing.
评论 #39665670 未加载
评论 #39662953 未加载
tl988008大约 1 年前
Actual timelock encryption, encrypted using parallel hashing and decrypted via forcing serial hashing: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7848999">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7848999</a>
iskander大约 1 年前
Related: Verifiable Delay Function<p><a href="https:&#x2F;&#x2F;link.springer.com&#x2F;article&#x2F;10.1007&#x2F;s00145-020-09364-x" rel="nofollow">https:&#x2F;&#x2F;link.springer.com&#x2F;article&#x2F;10.1007&#x2F;s00145-020-09364-x</a>
评论 #39662656 未加载
aarreedd大约 1 年前
FYI - this has used 33% of Cloudflare&#x27;s daily free tier limit for workers since I posted this 3 hours ago.<p>Every pageview and API call is an invocation. You get 100,000 calls per day for free.
评论 #39684354 未加载
mothepro大约 1 年前
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.<p>Paper: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;e&#x2F;2PACX-1vQe-OF0Lw9lutf6aBeSlVs0G09sSGX3XmBRQG7rkbxRvJeKZ22hH-O1zXU4Cvj8YXfi4r2N31GUc7cG&#x2F;pub" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;e&#x2F;2PACX-1vQe-OF0Lw9lutf6a...</a>
评论 #39664809 未加载
tutfbhuf大约 1 年前
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.<p>[^1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;drand&#x2F;tlock">https:&#x2F;&#x2F;github.com&#x2F;drand&#x2F;tlock</a>
instantiator大约 1 年前
Related - how do you send a message into the future with conditional release? A dissertation on Dead ~~Man~~ Person Switches...<p><a href="https:&#x2F;&#x2F;instantiator.dev&#x2F;post&#x2F;dead-person-switch&#x2F;" rel="nofollow">https:&#x2F;&#x2F;instantiator.dev&#x2F;post&#x2F;dead-person-switch&#x2F;</a>
kaangiray26大约 1 年前
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?
评论 #39665799 未加载
jslakro大约 1 年前
The only problem I have with this kind of tools&#x2F;experiments is that you can begin to use it then in one or two years the domain expires and everything is over
评论 #39667251 未加载
评论 #39666286 未加载
Dibby053大约 1 年前
What does this solve that couldn&#x27;t be solved by simply disclosing the decryption key <i>oneself</i> at the specified date?
评论 #39662471 未加载
评论 #39662513 未加载
victorbjorklund大约 1 年前
Very cool. Now I just need to find a reason to use it.
评论 #39665829 未加载
klabb3大约 1 年前
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.
Jamustico大约 1 年前
Whats the point of this if it&#x27;s not decentralized&#x2F;algorithmic based.<p>Who knows if this service will go down or something?<p>Might aswell just do this with one entity m
评论 #39662164 未加载
评论 #39662158 未加载
jerrygoyal大约 1 年前
i wonder what could be the most interesting use case of this?
makach大约 1 年前
..but will it stand the test against time?<p>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
troymc大约 1 年前
Here&#x27;s a way to encrypt something with an <i>actual</i> 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.<p>Step 1: Generate a large number of named public&#x2F;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).<p>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.<p>Step 3: To encrypt a message such that it&#x27;s guaranteed to not be cracked in less than some specified time, encrypt it several times, using the known named public keys.<p>To decrypt the message, you&#x27;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&#x27;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.<p>There are tricks to speed things up by sending a spacecraft out towards Neptune, but they don&#x27;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&#x27;s still a lower bound on the required time until full decryption.<p>Inspired by the TOR network.
评论 #39662372 未加载
评论 #39662328 未加载
评论 #39662554 未加载
评论 #39667336 未加载
评论 #39666119 未加载
评论 #39662227 未加载
评论 #39662611 未加载
评论 #39662297 未加载
评论 #39664517 未加载
评论 #39662869 未加载