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
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.
>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?
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?
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?
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.
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.
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.
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
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
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.
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.
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.
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)
TacticalCoder|2 years ago
"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...
lucb1e|2 years ago
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
ProllyInfamous|2 years ago
[deleted]
BigParm|2 years ago
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.
bsdetector|2 years ago
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.
throwaway69123|2 years ago
vmfunction|2 years ago
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.
koliber|2 years ago
lumpa|2 years ago
lucb1e|2 years ago
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.
montecarl|2 years ago
> 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
charcircuit|2 years ago
dheera|2 years ago
I'm not an expert on DeFi but could we do something more time-precise using the Ethereum blockchain and a smart contract?
buu700|2 years ago
falsandtru|2 years ago
> 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/
Thread on the cited Cloudflare blog: https://news.ycombinator.com/item?id=39641475
krackers|2 years ago
> 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?
denton-scratch|2 years ago
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|2 years ago
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.
Uptrenda|2 years ago
- 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.
bialpio|2 years ago
aarreedd|2 years ago
Swiffy0|2 years ago
aarreedd|2 years ago
neiman|2 years ago
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.
adastra22|2 years ago
sterlind|2 years ago
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?
tl988008|2 years ago
iskander|2 years ago
https://link.springer.com/article/10.1007/s00145-020-09364-x
ttyprintk|2 years ago
https://news.ycombinator.com/item?id=18437659
aarreedd|2 years ago
Every pageview and API call is an invocation. You get 100,000 calls per day for free.
arch-choot|2 years ago
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
mothepro|2 years ago
Paper: https://docs.google.com/document/d/e/2PACX-1vQe-OF0Lw9lutf6a...
cowthulhu|2 years ago
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.
tutfbhuf|2 years ago
[^1]: https://github.com/drand/tlock
unknown|2 years ago
[deleted]
instantiator|2 years ago
https://instantiator.dev/post/dead-person-switch/
kaangiray26|2 years ago
AgentME|2 years ago
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.
unknown|2 years ago
[deleted]
jslakro|2 years ago
aarreedd|2 years ago
crotchfire|2 years ago
ICANN is a cancer.
Dibby053|2 years ago
aarreedd|2 years ago
ghnws|2 years ago
victorbjorklund|2 years ago
littlecranky67|2 years ago
klabb3|2 years ago
Jamustico|2 years ago
Who knows if this service will go down or something?
Might aswell just do this with one entity m
adastra22|2 years ago
chews|2 years ago
jerrygoyal|2 years ago
makach|2 years ago
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|2 years ago
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.
pjerem|2 years ago
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
lucb1e|2 years ago
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
voxic11|2 years ago
denton-scratch|2 years ago
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.
Dunati|2 years ago
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.
dheera|2 years ago
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.
dave1010uk|2 years ago
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.
ur-whale|2 years ago
The economics of your proposal strike me as a tad weak at the knee.
unknown|2 years ago
[deleted]
unknown|2 years ago
[deleted]
christenchrist|2 years ago
[deleted]
racheljaneville|2 years ago
[deleted]
yogorenapan|2 years ago
[deleted]
adastra22|2 years ago
dumbfounder|2 years ago
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.
DistractionRect|2 years ago
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.
pshirshov|2 years ago
littlestymaar|2 years ago
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)
ur-whale|2 years ago
In that case, the whole warrant theory isn't the last word.
andix|2 years ago
[deleted]
scosman|2 years ago
[deleted]
unknown|2 years ago
[deleted]
mellutussa|2 years ago
[deleted]
unknown|2 years ago
[deleted]