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

Phillip Hallam-Baker phill at hallambaker.com
Sun Jan 6 16:22:16 EST 2019


On Sun, Jan 6, 2019 at 12:23 AM Joshua Marpet <Joshua.Marpet at guardedrisk.com>
wrote:

> My mom passed in 2013. I had a nice day, where my wife, daughter, and
> myself, went to an interesting and fun wedding today. I had a random
> thought, that I would have loved to talk to my mom, and tell her about it.
>
> Obviously, not possible, short of a OUIJA board. :)  So I thought about
> writing a letter. So where do I post it?
>
> So I thought of a website, where you can send letters to people, a la
> Postsecret. But it's harder to anonymize electronic  messages.
>
> Soooo, how about a system that automatically encrypts incoming emails? And
> then, some time later, it decrypts, long after anyone who wrote those
> letters is alive? Say 100 years. I'd write a letter to my mom which would
> be auto-decrypted 100 years later and given to the public. A la Post
> secret, and historical interest.
>
> 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?
>
> Weird use case, I apologize. Just a thought.
>

It is actually an example of a very common requirement for timed release of
information or release on specific criteria.

This is in part what the blockchain's smart contracts are a nod towards.
Use cases include:

* Release of a person's will on their death
* Release of a person's bank accounts etc.
* Release of family secrets, national security, etc.

I have a lot of information I would like to keep secret from my family
until after my death and some stuff longer than that. I want them to know
where I buried Aunt Agatha's jewelry but not where I buried Aunt Agatha.

The timed version is going to require some form of notary. But it is easy
enough to provide a robust disclosure protocol and I have anticipated this
requirement in the Mesh tools which allows use of Shamir secret sharing to
provide additional robustness.

[I have not yet implemented this particular service but I might well do so
earlier than I planned as it gives me a podcast.]

So let us imagine that disclosure authority (DA) creates a sequence of
keypairs that are dated as follows:

Hourly - for the next 240 hours.
Daily - for the next 365 days.
Monthly - for the next 120 months.
Annually - for the next 100 years.

The DA releases the corresponding private key at the specified time. So for
the simplest escrow protocol, we simply encrypt under the corresponding
public key.


This is not very robust though and especially so if we want to achieve long
escrow times. For this we need to provide for separation of duties and use
multiple DAs with a quorum.

So let us say we want to escrow the data for ten years. Three DAs and a
quorum of Two should be sufficient. We encrypt the data under a master key,
split the master with Shamir Secret Sharing and encrypt each share under
our selected DAs.

If we want to keep the data for twenty, thirty or more years, we would need
to have more shares.


This protocol is not perfect, it is still possible for a coercion attack to
work. So if I was going to escrow really important information I would want
there to be additional controls provided through use of verifiable
ceremony. But as soon as you go to ceremony you are limited to quarterly
operations.

We can also make use of threshold crypto at the DA level. So the DA might
actually have three hosts that each disclose a share.


The most useful form of DA would be one that will disclose information
UNLESS the party takes some action. So the data is disclosed unless I say
it should be kept private. But that is really difficult to achieve
robustly. The nearest I have is that the DA reads a list of signed notices
saying 'don't release X' and only decrypts the escrowed data that isn't on
the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190106/2b78498c/attachment.html>


More information about the cryptography mailing list