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

141–149 of 149 posts

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

#141

Post by troymc »

denton-scratch wrote: post #134
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…

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

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.

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

#143

Post by denton-scratch »

troymc wrote: post #141
denton-scratch wrote: post #134

Earlier quoted context omitted.

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

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

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

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

#144

Post by bialpio »

aarreedd wrote: post #76
bialpio wrote: post #64

This feels like Shamir's secret sharing with a pinky promise that "we won't decrypt things earlier", am I missing something?

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

Gotcha, at first I was expecting something that tried to rely on some kind of physical limitation or a property that the passage of time has.

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

#145

Post by sterlind »

coppsilgold wrote: post #103
olejorgenb wrote: post #96

Earlier quoted context omitted.

But it also take t time to encrypt?

To obtain the encryption key, yes. 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] [1] ht…

the chained hashes approach is an extremely elegant method, thank you for linking it.

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

#146

Post by TacticalCoder »

lucb1e wrote: post #100
adastra22 wrote: post #99

Earlier quoted context omitted.

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)

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.

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

#147

Post by lucb1e »

denton-scratch wrote: post #135
lucb1e wrote: post #28

Earlier quoted context omitted.

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

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

Oh, that is indeed less than I thought!

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

#148

Post by arch-choot »

aarreedd wrote: post #83

FYI - this has used 33% of Cloudflare's daily free tier limit for workers since I posted this 3 hours ago. Every pageview and API call is an invocation. You get 100,000 calls per day for free.

I'm not sure how intensive the "backend" is, but I've found stuff like workers to be economically efficient only for hobby tier projects.

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

Post reply on HN