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):
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
Ah! Thanks. That immediately answers the second thing I was wondering about, since 2k RSA keys are still deemed safe (if barely / not for secrets that need to last a long time into the future)
In addition to what GP answered: note that I didn't crack anything. I just really did all the 79 trillion sequential computation needed to find the solution. That's the really need thing: you can encode the problem in a split second and yet decide how many sequential steps are needed to find the solution.
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.
> there’s no way to measure time directly. It clearly exists, yet all you can measure is change of things besides time.
If it can't be measured then it can't be said to clearly exist.
Imagine a cellular automata where particles have lots of "slots" that could be used for moving or interacting. As the particle speeds up and more slots are used for moving, there are fewer slots for the kind of interaction change that we use to measure time. At the highest speed, with all possible slots used for motion, the particle would experience no change, which is indistinguishable from no time passing.
Does that sound familiar to anything? It's certainly possible that light being a speed limit, time dilation, relativity, and so on are in some way actually describing change rather than time.
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.
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)
It's identical to measuring gravity. In relativity, acceleration and gravity are indistinguishable, and it's acceleration which breaks the paradoxical symmetry that gives the name to the twins paradox.
>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.
Digital cryptography will always being a cat and mouse. DES, RSA, Elliptic curve... With intro of quantum computing, it will just fasten up the pace. Some government has start experimenting with quantum entanglement (https://apnews.com/article/china-google-justice-department-6...)
It is all about your threat model. Even that I'm sure someday some smart guy will also figure out how to figure out how to beat that.
On human scale, is this a real problem? Consensus gives us the ability to measure elapsed time with a high probability. It seems kind of analogous how fundamental particles are probability fields. That means that in theory a baseball could teleport. But because a baseball is big spontaneous teleportation is not a real concern for anyone.
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.
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.
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?
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).
> 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)
You could create a DeFi system not too unlike the one linked in this post: a number of oracles release keys at designated times (use M of N encryption).
The oracles could be financially incentivized to behave properly. E.g. they post a bond, which is confiscated if they don't post a private key on time or if a whistleblower discovers and reports a key early. In return for correct behavior they can earn some fees paid by users of the service.
The financial incentive still flips if the secret's value is sufficiently large, but it would require coordination of many unprincipled oracles.
The problem with whistleblowers is that now the entire system's security is transferred to them. Whistleblowers can also be bribed to blow whistles early or not blow whistles.
Here's an another idea. Bitcoin has a halving, right? Somehow the entire system has agreed to halve at a certain time, and not halve early or halve late? How does this work? Can we utilize this time agreement somehow? Can it be incorporated into an algorithmic whistleblower, whereby (a) N people each know 1/N of the key (b) if anyone demonstrates that they know the answer to a question before halving, whistles are blown by a contract and all N people are punished (c) after halving, all N people receive a reward?
Anyone can halve at any time, so anyone can "cheat" that by halving immediately.
The reason everyone does it at the same time is because doing it [literally right now] will lead to a history that nobody else agrees is valid (halved at the wrong block number), so any coins you mine on your forked chain will be worthless. There's a monetary incentive to play by the rules, but absolutely no technical requirement.
Bitcoin's primary achievement (IMO but it's fairly common) is that it managed to design a technological system that encourages playing by the rules. Cheating always pays worse than playing along, and even trolling only works if you have the majority of all computing power (very expensive), so there's no reason to cheat. But outside the core public key cryptography that handles addresses and proving transactions, and the "proof of work" that basically just limits the speed of everything so there's time for the world to agree on things, there's not really any fundamental crypto involved. Just self-reinforcing social incentives.
(this kind of disagreement is why there's both Bitcoin and Bitcoin Cash. they share a common beginning but branched off some time ago and are now completely separate)
The whistleblowers are not designated parties, they are just any Ethereum user. They would have a financial incentive for whistleblowing, and they could never falsely whistleblow because the smart contract can check whether they actually have the private key early or not.
Not with ethereum or a smart contract, because any ethereum node can simulate any execution of a smart contract.
But it occurred to me that you can sort of do something like this with a proof of work-like algorithm, though the time to solve would still be variable.
Essentially you'd need a network of "miners" and instead of a block, you'd have a node encrypt a message with an encryption key of a set difficulty (decryption key length), based on the target decryption time and the network hash rate (hash rate probably is not the correct term, but I'll use it for conciseness).
The miners would then work to decrypt the data using the knowledge of the key length.
I'm not sure how you would incentivize the miners to work on decrypting it though, and the node which encrypted it would of course have knowledge of the message, so I don't see how this could be used in practice.
In theory if your miners were running something like a tamper-proof secure enclave (I'm not even sure if these truly exist) perhaps there's a way to attest their own hashrate, and then an encrypted message can be proposed by a node to a subset of miners which collectively have the assumed hashrate. The secret-encrypted data can then be re-encrypted for each miner, with their public key.
This ensures other miners not participating in the challenge can't attempt to decrypt the data.
The problem here is incentivization over a long period of attempting to decrypt the data. You'd have to offer a reward large enough to incentivize the miners to cooperatively work to decrypt the message for the longest possible amount of time it could take to decrypt the message.
edit: I think for this to work you'd first need to encrypt the data for each miner which should participate in the challenge, and then encrypt it with the secret key. That way a miner which solves this can publish the decryption key and the still-encrypted payload, which only they can decrypt, and all the other miners can apply the same solution to verify the published solution and solved message with their own private keys.
edit 2: I suspect there's something potentially useful here, but I don't know enough about secure enclaves to really know if it's feasible to implement in a way that prevents gaming, so if someone knows more about such things, feel free to take the idea and run with it.
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.
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
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?
Hi, I'm one of the authors of the Cloudflare blog and maintainer of Cloudflare's drand nodes.
You're correct -- after the initial distributed key generation, the values produced by the drand network are deterministic (this is one of the properties that allows for timelock encryption). The security properties of drand rely on a threshold of nodes remaining uncompromised, but mixing in fresh randomness isn't necessary. (Although you could imagine having some drand chains that incorporate fresh randomness for properties like post-compromise security.)
> 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
If this is misleading it wasn't intentional! We used the word "seed" since the randomness from LavaRand is only mixed in when the network is initialized, but perhaps that could have been phrased better. Or perhaps we should have split it into separate blogs talking about LavaRand and drand since they're only tangentially related :).
Thank you for the reply, that clarifies things! As a crypto-novice perhaps explicitly using the term "initialize" might be better at indicating this is a one-time thing rather than a "continuous" process of injecting entropy.
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.
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.
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.
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.
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
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.
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.
VDF/sequential-PoW stops being interesting once you notice that efficient hardware implementations can beat CPU implementations by 6-10 orders of magnitude, depending on the work function.
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?
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.
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]
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.
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.
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?
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.
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.
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
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.
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.
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.
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.
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.
Because each node generates its own key pair and when encrypting a message you choose a random route and you use the keys of the nodes of your route to encrypt each layer.
What the person you're replying to is talking about is a Sybil attack. You pick random nodes, yes, but what if the list of nodes to pick randomly from is 99.5% the attacker? This is a real world attack that has been used against Tor, for example.
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.
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.
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
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.
The spacecraft should generate the key pairs itself once it landed and send the public keys to earth to be sure no human stole the private keys.
But, while fun, your idea is not that stupid.
If the spacecraft continuously generate key pairs, you could even avoid landing it and "just" throw it in some direction, Voyager style (if you can afford rebuilding some every few decades) or on some orbit in the solar system. You don’t have to pay for the landing tech.
I wouldn’t even be surprised that this could be viable economically. It doesn’t sound that much technologically difficult
My thinking now is that you could send the spacecraft out to Neptune and do a gravity-assist maneuver there, sending the spacecraft into a large orbit around the Sun, with a high perihelion.
I really don't know. I wouldn't be surprised that, on the entire planet, a niche market could exist that would want to pay the premium over say, giving an envelope to a notary.
You could also change the business model to allow NOT decrypting messages by paying the message author (and take a commission) but I guess that would attract more than shady customers :)
Because it has such high delays? Basically revealing the information which the onion service or exit node encrypted for you only after, potentially, a few trips around the globe?
That makes me think this can be achieved without spacecraft, by just having geographically distributed private keys (even just a few kilometers; you just need the light delays to dominate over processing delays).
And I don't think you need more than two keys: if you wrap it in A(B(A(B(message)))), then party B cannot work on the first layer but first needs to send it to A, party A cannot decrypt the second layer but first needs to sent it back to B, etc. One of the parties could be your recipient, so that would also work with an expensive one-off spacecraft.
> land on the surface a distant body in the solar system
landing is a lot more difficult than staying in Neptune's orbit (notice how many moon-bound spacecraft crashed, even only in recent years!); you'll get the same characteristics by just going out to a desired orbit.
Also note that the amount of delay between Earth and <your orbit, such as Neptune's> will vary wildly
One could build a service just around the fact that the fastest theorical time it takes to transmit information around earth is around 130ms. This means that the absolute maximum number of layers that could be used in a day is well below 1 million. Scale that over a few billion layers or more, and reveal a new key every roundtrip, and you would've got yourself a much simpler timelock encryption.
The problem that arise is (and which is solved by the spacecraft to Neptune) is that with any earth based system, someone could secretly move copies of both ends closer together, secretly, and decrypt the lock faster than expected. Putting a spacecraft on a trajectory with no realistic chance of ever coming back makes this possibility impossible (as long as the layers of keys are encrypted only when the spacecraft arrived at its destination. Even if the delay between earth and neptune vary wildly, it is predictable, and any local system could piggyback a larger scale system like this for safety
Neptune is about 30AU from the Sun. The Earth's distance from Neptune will presumably vary somewhere between 28AU and 32AU. Light travels 1AU in about 8 minutes, 28AU in about 224 minutes, 30AU in about 240 minutes, and 32AU in about 256 minutes. Depending on your use-case, that's not a particularly wild variation.
I wrote that the proposed system was inspired by the TOR network, not that it literally uses the TOR network. To send a message across the TOR network, you wrap it in a bunch of layers of encryption, and then each TOR node removes one layer: that's the similar aspect.
Your other critiques are all valid. There's still a lower bound on the total time required for full decryption. I was just trying to show that that is possible.
Not meant as critiques! And I did not assume it was using the Tor network, I understood the word "inspired" as you meant it. Clearly I need to work on my communication :(
Wouldn't landing a spacecraft next to the first one allow you to decrypt messages in essentially one round trip time? So if you had a message on earth timed locked for 100 years you could transmit it your your own spacecraft next to the decrypting spacecraft and it could almost immediately get through all layers of encryption and send you back the decrypted message.
So encryption is a fixed-time operation, requiring a single round-trip to the spacecraft. There is another time-delay at decryption, quantized into round-trip times; the minimum decryption delay is one round-trip. For a moon of Neptune, a round-trip is about 9 hours(?).
If I want my secret exposed in 20 years, I will need to wrap it in 18,000 layers of encryption, and then start the decryption process immediately.
The duration of one decryption step depends on the distance to the spaceship; it would be difficult (but not impossible?) to rely on a spaceship whose distance is always changing. It needs to be somewhere faraway, and also to be somewhere that's always going to be roughly the same distance away. A moon of Neptune is a reasonable candidate.
The distance between Earth and Neptune oscillates with a period of about one year because Neptune moves around the sun much slower than the Earth does. The Earth-Neptune distance oscillates between about 29 AU and 31 AU.
I checked your calculations and I get similar numbers. I don't think that tens of thousands of layers of encryption is a problem: a modern computer can store that many private keys with no problems. In fact, it should probably store three copies of each one, or do something to account for random bit flips.
> because Neptune moves around the sun much slower than the Earth does
I think of the "1AU either way" thing as being simply that sometimes the Earth is on the other side of the Sun from Neptune, so the Earth<->Neptune distance is 1AU greater; and sometimes it's on the same side, so 1AU closer.
I didn't mean to suggest that 18,000 layers was silly; for encryption it would take seconds or less. And for decryption, having multiple layers is vital, because that's what creates the delay.
It's awkward that you have to start decrypting immediately. The ideal would be a self-contained object like a USB key, that does just one thing: after n ticks, it exposes its secret. In principle, it could be based on a mechanical clock, but it's hard to envisage a tamper-proof mechanical clock.
Frist, should probably put the ship on a solar escape trajectory, so that physically intercepting it would be more difficult with time, and likely require a technological leap to accomplish. It would also be nice to have the ship on a trajectory as far away from the plane of the ecliptic as you can, to minimize occlusion and time variation based on the earth's orbit.
Next, instead of pre-seeding the ship with keys, you have it generate them (using its RTG for both power and a source of entropy) and send them back to earth at a fixed rate, possibly with the size of the keys increasing over time.
On earth, when you want to encrypt a payload to be decrypted at a future date, you calculate how many round trips it would require, then encrypt the data with that many keys from the stream, interleaved with keys generated locally. As the time will unlikely be an exact round trip time (which is ever-increasing), each end can delay the decrypt and re-transmission for some proportion of the remaining time.
> 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.
The shipping container will reach its destination in a few weeks. You could stretch it to months by repeatedly re-shipping it, like the cop-van stolen by the longshoremen in The Wire. But if someone else wants the secret, the longer it spends in a shipping container, the more likely it is to be discovered.
If you want your secret to last for decades, a shipping container is too vulnerable.
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?
You’re correct: the fame of discovering Jimmy Hoffas burial is high in pop culture. Maybe as high as Hacker News finding a usb key timelock where only a vague area is given.
Yes, Jimmy Hoffa is a "famous" disappeared person case here in America.
There are only a few "famous mysteries" that became such widespread memes in American culture.
The ones I can think of are:
1. What happened to Jimmy Hoffa (who killed him?). "The Irishman" on Netflix is a Scorsese adaptation of a "nonfiction" book that documents an old Mafia hitman claiming to have killed Hoffa. (The book is nonfiction, the guy's claims are somewhat contested.)
2. What happened to Amelia Earhart? (Early female aviator who disappeared attempting to fly around the world).
3. What happened to and who was DB Cooper? (A man hijacked an airplane, traded some hostages for a duffle bag of cash at an airport when such a thing was possible, told the pilots to fly to Canada and then jumped out of the plane with a parachute and the duffle bag somewhere over the pacific northwest).
Thank you, I regret picking such a reference. Amazing to entertain that the guy who killed Hoffa could have lived long enough to write about it. As if reality suddenly became gentler, and all differences could be hugged out.
First find Jimmy (embedded in concrete?). Then notice that there's no time element; Jimmy's USB key will be found when Jimmy's found, which might be tomorrow or it might be never. Then learn that he disappeared long before USB keys were invented.
This is a really cool idea using fundamental properties of physics but I don't think it works.
If the spacecraft is trusted by the person with the secret, it's much simpler to instruct the spacecraft to only disclose the secret after a set date. You don't seem to gain anything from the carded complexity.
If the spacecraft isn't trusted, there's nothing it stopping it disclosing all the key pairs at once.
I think the best bet at the moment is something like Rivest-Shamir-Wagner time lock puzzles, which requires a fixed number of sequential computations to perform.
The up-front capital expenditure might be high, yes, but it might be possible to recoup that by charging fees for the service once it's working. The Chunnel had a high capex too.
In any case, I just wanted to show that working timelock encryption system is theoretically possible. Some people claimed it wasn't.
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.
Smart contracts operate completely transparently. There is no private data other than the private keys used to sign transactions. Unless you just encrypt the data, then you need a key to access it, and the nodes don’t have that key.
I know a guy that worked on this same problem leveraging TEEs (trusted execution environments). This enables 3rd parties to run the software and join the network and take part without having access to the data. Unless they find a flaw in the TEE that can be exploited.
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.
> 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)
"Time-lock puzzles and timed release Crypto"
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
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-ol...