
Time-Lock Encryption (2011) - vermilingua
https://www.gwern.net/Self-decrypting-files
======
vbrandl
I only skimmed the post, but referring to the blackbox approach with some
blockchain as trustless clock:

Given the black box was created when block X was the current one and is
defined to release the key some N days later, so ca. (N * 144) blocks later,
if the bitcoin blockchain with a block time of 10 minutes is used.

Wouldn't an attacker be able to create an isolated network using the existing
blockchain up to block X, push the difficulty in this "new" network
artificially down and create the amount of required blocks much faster than
the actual bitcoin network.

Once the chain is calculated up to a specific point, the blackbox program can
be executed in the emulated network and will release the key before the actual
deadline.

Am I missing something or is this conceptually broken?

~~~
progval
This probably assumes you can't trick the program into connecting to the wrong
bootstrap nodes.

~~~
vbrandl
But this means that there is a trusted party involved: the bootstrap nodes.
Those might not exist anymore in the future. If they don't, the key cannot be
released anymore? In my opinion something like this must not depend on the
online status of some nodes.

I think, for the black box to be truly trust-less, it must be a `f: Blockchain
-> Maybe DecryptionKey`. And then you can provide a specifically crafted
blockchain to extract the key...

------
dang
A thread from 2014:
[https://news.ycombinator.com/item?id=8447175](https://news.ycombinator.com/item?id=8447175)

Related from 2014:
[https://news.ycombinator.com/item?id=7847687](https://news.ycombinator.com/item?id=7847687)

A thread from 2013:
[https://news.ycombinator.com/item?id=6508179](https://news.ycombinator.com/item?id=6508179)

------
Lucent
This is going to be a game changer when the first password manager implements
a no third party time-lock as its recovery by trusted contact mechanism. Most
of them just hold onto your password store public key encrypted for that
contact, if they implement a trusted contact recovery at all.

------
blattimwind
Both time and location based encryption frequently appear as plot devices in
fiction, but both are not really the subject of cryptography. At the core both
of these simply require measurement of a physical quantity (position, time
elapsed) to release some bits of information. This is something cryptography
inherently can't do. You either end up changing the problem (unlocks not
before X => unlocks after spending X amount of time computing) or relying on
someone/somethey to proxy the measurement in a trustworthy manner to you (the
blockchain-blackbox approach).

(You can't do "location based encryption" even if you bring your own trusted
computing enviroment plus GNSS receiver, because GNSS emulators exist)

~~~
Terr_
> location based encryption

Well, you can if the encryption key requires information that can only be
collected from that location. The simplest example would be to put the
encryption key on a piece of paper and tuck it under a rock. Now _somebody_
has to reach that location in order to decrypt your message.

Time-based encryption is fundamentally different, since the sender can't
travel into the future to lay unpredictable clues in advance.

~~~
vbrandl
This reminded me of dead drops:
[https://deaddrops.com/](https://deaddrops.com/)

