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

81–90 of 149 posts

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

#81

Post by sterlind »

neiman wrote: post #72

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

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?

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

#82

Post by wuiheerfoj »

chews wrote: post #14
Jamustico wrote: post #10

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

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.

EPFL, DEDIS, university of Chile, University College London and cloudflare aren’t crypto organisations

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

#85

Post by TacticalCoder »

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

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

#87

Post by krackers »

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 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?

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

#88

Post by bigiain »

Groxx wrote: post #27
lucb1e wrote: post #26

Earlier quoted context omitted.

I don't understand the lead pipe analogy. What's up with getting a metal pipe if you don't "agree to keep this secret"?

It's just one of many tools commonly used in the https://xkcd.com/538/ meme.

See also "Rubber-hose cryptanalysis"

https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

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

#89

Post by coppsilgold »

sterlind wrote: post #81
neiman wrote: post #72

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

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.

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

#90

Post by londons_explore »

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…

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