Live data from Hacker News

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

timelock.dev

111–120 of 149 posts

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

#111

Earlier quoted context omitted.

What about time crystals? https://en.wikipedia.org/wiki/Time_crystal

Time crystals aren't the only thing that has properties that change in an orderly, predictable fashion. Plain old uranium has the same property. The answer to both is the same - put them on a very fast rocket and do a lap around the galaxy and see how well they agree with you on how much time has elapsed.

Is it not rather that time does not elapse everywhere at he same speed, simply put?

Based on this, of course, measuring it becomes difficult.

It's akin to measuring gravity. You can — for a specific point in space and time. (Time is even worse, since it is specific to a given _trajectory_ in space)

But I have no idea what Im talking about.

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

#113
post #47

Earlier quoted context omitted.

Why ? If you wrap the message into multiple layers of encryption (TOR style) that needs to go into multiple nodes, and if alongside the next encrypted layer you have a date the nodes agrees to wait to pass the message to another node, that would work, no ? Even with some corrupted nodes, the message would still be secret, the only issue would be if the last nodes are corrupted : your message would be distributed too…

What stops you from just spinning up X nodes in your own private network if everything is open source? And then tell every node to decrypt instantly.

Because each node generates its own key pair and when encrypting a message you choose a random route and you use the keys of the nodes of your route to encrypt each layer.

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

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

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

#115
post #113

Earlier quoted context omitted.

What stops you from just spinning up X nodes in your own private network if everything is open source? And then tell every node to decrypt instantly.

Because each node generates its own key pair and when encrypting a message you choose a random route and you use the keys of the nodes of your route to encrypt each layer.

So you can only decrypt the message if all the same nodes are still up? If anyone goes down you cant decrypt?

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

#116
post #113

Earlier quoted context omitted.

What stops you from just spinning up X nodes in your own private network if everything is open source? And then tell every node to decrypt instantly.

Because each node generates its own key pair and when encrypting a message you choose a random route and you use the keys of the nodes of your route to encrypt each layer.

What the person you're replying to is talking about is a Sybil attack. You pick random nodes, yes, but what if the list of nodes to pick randomly from is 99.5% the attacker? This is a real world attack that has been used against Tor, for example.

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

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

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.

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

#118

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.

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

#119
post #113

Earlier quoted context omitted.

Because each node generates its own key pair and when encrypting a message you choose a random route and you use the keys of the nodes of your route to encrypt each layer.

What the person you're replying to is talking about is a Sybil attack. You pick random nodes, yes, but what if the list of nodes to pick randomly from is 99.5% the attacker? This is a real world attack that has been used against Tor, for example.

Thank you, I understand !

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

#120

Very cool. Now I just need to find a reason to use it.

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