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

21–30 of 149 posts

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

#21

Post by Groxx »

dheera wrote: post #12
lucb1e wrote: post #5

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

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

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

#22

Post by charcircuit »

lucb1e wrote: post #5

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

It's also tough to find good algorithms where you can't just spend double to half the time until it unlocks.

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

#23

Post by DistractionRect »

yogorenapan wrote: post #6

[flagged]

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.

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

#24

Post by ur-whale »

troymc wrote: post #17

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

> Send the spacecraft to land on the surface a distant body in the solar system, such as one of the moons of Neptune.

The economics of your proposal strike me as a tad weak at the knee.

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

#26

Post by lucb1e »

Groxx wrote: post #21
dheera wrote: post #12

Earlier quoted context omitted.

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…

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

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

#27

Post by Groxx »

lucb1e wrote: post #26
Groxx wrote: post #21

Earlier quoted context omitted.

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…

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.

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

#28

Post by lucb1e »

troymc wrote: post #17

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

> Inspired by the TOR network.

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 will vary wildly

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

#29

Post by falsandtru »

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

Details: https://drand.love/docs/timelock-encryption/

Thread on the cited Cloudflare blog: https://news.ycombinator.com/item?id=39641475

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

#30

Post by troymc »

ur-whale wrote: post #24
troymc wrote: post #17

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

> Send the spacecraft to land on the surface a distant body in the solar system, such as one of the moons of Neptune. The economics of your proposal strike me as a tad weak at the knee.

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.

Post reply on HN