[Cryptography] Came up with a weird use case, got questions

Natanael natanael.l at gmail.com
Sun Jan 6 15:52:08 EST 2019


Den sön 6 jan. 2019 06:23 skrev Joshua Marpet <Joshua.Marpet at guardedrisk.com
>:

>
> Any systems out there which will auto-decrypt, not based on a clock (which
> can be spoofed), but instead based on an event, a piece of information, a
> trusted info source? Something like the Long Now foundation's clock?
>

There's a few possible variants, each with different properties that you
may or may not want.

Time-lock cryptography, which is essentially hashcash / proof-of-work,
wherein the work task (for symmetric algorithms) is created in parallel and
then chained such that they only can be solved serially, which means that
assuming a certain maximum CPU speed (!) you can enforce that a minimum
time passes (by enforcing that a minimum number of CPU cycles passes).

However, without incentive nobody will try to solve it.

Dead man's hand schemes. They're typically not based on cryptography,
instead they rely on a mechanism that will outlive you to trigger an event.
You can combine it with cryptography - it would for example work just fine
to combine this with Shamir's Secret Sharing Scheme by setting up multiple
computers that will run non-stop (perhaps a few solar powered Raspberry
Pi:s), placed in different locations, and when the time is up they each
release their share of the secrets.

This is quite fragile, partially because you can't know for sure what
electronics will last 100 years, and because it's just as hard to know what
companies you could outsource the task to which would last 100 years and
uphold the promise.

Lastly, assuming there's some entity that can simply be trusted just to
continously perform some repetitive task for the entire time (such as just
publishing the current time, digitally signed), not tampering with the
clock, then functional encryption / indistinguishable obfuscation could
work. You'd create a cryptographic program that only releases its secret if
given a signed message with that future date.

The issue with this one is that we don't even have any proper prototypes of
cryptographic algorithms that can do this yet, we're still in the
theoretical academic phase and don't know for sure if these algorithms can
be sufficiently secure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190106/4e3e2106/attachment.html>


More information about the cryptography mailing list