Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

timelock.dev

Post reply on HN
Print view View original

91–100 of 149 posts

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

#91

Post by lumpa »

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.

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

#92

Post by lukevalenta »

krackers wrote: post #87
falsandtru wrote: post #29

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 t…

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…

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 :).

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

#93

Post by BigParm »

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.

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

#94

Post by pshirshov »

thewakalix wrote: post #8
pshirshov wrote: post #7

Earlier quoted context omitted.

Ergh, could you explain how did you come to this conclusion?

https://drand.love/docs/timelock-encryption/#%E2%9A%A0%EF%B8...

This is not the same at all.

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

#95

Post by krackers »

lukevalenta wrote: post #92
krackers wrote: post #87

Earlier quoted context omitted.

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…

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.…

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.

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

#96

Post by olejorgenb »

coppsilgold wrote: post #89
sterlind wrote: post #81

Earlier quoted context omitted.

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 c…

But it also take t time to encrypt?

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

#97

Post by lucb1e »

TacticalCoder wrote: post #85

Rivest, Shamir and Wagner, 1996: "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/wik…

> (on one core, it's not parallelizable)

Why is that? From what I see on Wikipedia ("n is a specific 616-digit (or 2048-bit) integer that is the product of two large primes (which are not given)" sounds like a textbook RSA public key), it's an offline brute force challenge, a guessing game, so different computers (or cores) could independently take different slices of the guessing space. I will admit that prime factorization is one of my weak spots and I'll just resort to a few minutes of running pari-gp for that, since I know it uses some algorithm that is much better than brute force (it was orders of magnitude faster than alternatives for a CTF challenge involving a 512-bit RSA key).

Even if the factorization process' time spent is dominated by finding the next prime to try, rather than testing a prime for correctness for example, why couldn't you start anywhere in the 2048-bit space and find the next primes from there? Is there something you can use from the ciphertext that makes you need to start at a certain point and generate (single core) from there onwards? It sounds like the holy grail for key strengthening without memory trade-off options like scrypt and argon2 both struggle with

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

#98

Post by adastra22 »

mothepro wrote: post #73
adastra22 wrote: post #15

Earlier quoted context omitted.

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.

This is not true at all.

If you have a protocol, there's plenty of cryptography conferences and prestigious journals that would accept your manuscript.

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

#99

Post by adastra22 »

lucb1e wrote: post #97
TacticalCoder wrote: post #85

Rivest, Shamir and Wagner, 1996: "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/wik…

> (on one core, it's not parallelizable) Why is that? From what I see on Wikipedia (" n is a specific 616-digit (or 2048-bit) integer that is the product of two large primes (which are not given)" sounds like a textbook RSA public key), it's an offline brute force challenge, a guessing game, so different computers (or cores) could independently take different slices of the guessing space. I will admit that prime fact…

From the actual problem description:

Note that the puzzle can be solved by performing t successive squarings modulo n, beginning with the value 2. That is, set

W(0) = 2

W(i+1) = (W(i) ^ 2) (mod n) for i=1, 2, ...

and compute W(t).

There is no known way to perform this computation more quickly than to perform the t squarings sequentially, unless the factorization of n is known.

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

#100

Post by lucb1e »

adastra22 wrote: post #99
lucb1e wrote: post #97

Earlier quoted context omitted.

> (on one core, it's not parallelizable) Why is that? From what I see on Wikipedia (" n is a specific 616-digit (or 2048-bit) integer that is the product of two large primes (which are not given)" sounds like a textbook RSA public key), it's an offline brute force challenge, a guessing game, so different computers (or cores) could independently take different slices of the guessing space. I will admit that prime fact…

From the actual problem description: Note that the puzzle can be solved by performing t successive squarings modulo n, beginning with the value 2. That is, set W(0) = 2 W(i+1) = (W(i) ^ 2) (mod n) for i=1, 2, ... and compute W(t). There is no known way to perform this computation more quickly than to perform the t squarings sequentially, unless the factorization of n is known.

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)
Post reply on HN