[john_b]

This is something I've thought about, and as I see it a lot of the problems common to crypto software are manifest in this space as well. Specifically with regard to security vs useability/ease-of-adoption issues.

This particular implementation transmits sensitive data in the clear and does the encryption server-side, so it's hard to take it seriously except as a remote (and unsecure) notification service.

Aside from that obvious shortcoming, a truly secure and reliable DMS system would need the following properties, possibly more:

1. All data encrypted client side and sent to system only in encrypted form

2. Anonymous

3. Distributed (no single point of failure for DDOS attacks or subpoenas)

4. Any data sent into the DMS system is split into several pieces and only reassembled after the set time without a response has elapsed and the switch is triggered

A peer-to-peer application that transmits data exclusively via TOR would probably be most secure, but it's unclear what the motivation for running an instance of this kind of P2P application would be (since it's all encrypted you aren't downloading anything useful) or how many people would actively participate. Any server-based system would need to have a large number of servers in multiple countries to be robust to technical and legal challenges, and that sounds expensive. At the same time, a reliable and anonymous DMS system is something that I can see people paying a small subscription fee for.

Any way you slice it, it seems like there are a lot of hard problems to solve in this area, but a reliable DMS service would be extremely useful.

[eudox]

Obviously the solution is a DeadManSwitchCoin.

[arielweisberg]

I proposed this in an earlier thread and got some push back on the utility of the concept https://news.ycombinator.com/item?id=6509824

[tlrobinson]

gwern has a great summary of "time-lock encryption" possibilities: http://www.gwern.net/Self-decrypting%20files

[smithzvk]

Hey, that is an interesting idea that I have often thought about before, but have not been able to wrap my head around how this could be done. Are there any links/literature you can point to for techniques that sort of fit this bill?

I almost imagine doing something like this in a physical system is easier than at the cryptographic level, but that probably is to be expected considering my physics background. I mean, using quantum phenomena seems to be an obvious way to do it this albeit completely infeasible at this time.

[tormeh]

I think your sarcasm-meter failed you.

[jarrett]

In any protocol, how would you manage the decryption keys? If the file's owner is dead, s/he can't provide the keys. So that means the keys must be transmitted to some trusted party before the owner's death.

That party could be the dead man's switch service, but do you want to trust them? I wouldn't. (Nothing against the operators of this site. It's just inherently risky to trust a website operator in this type of situation.)

Alternatively, the key can be given in advance to the files' intended recipients via some secure channel. For example, suppose Alice wants Bob to receive the files upon Alice's death. Alice can deliver the decryption key(s) to Bob in person, electronically with PGP, or in some other sufficiently secure manner. But in this scenario, Bob has to know about Alice's deadman's switch in advance.

So I'm wondering: Is there any way to do this a) with encryption, b) without entrusting the keys to the operator of the service, and c) without informing the recipients in advance?

[StavrosK]

Yes, that's what PGP is for. Encrypt whatever you want to the recipient(s)' public keys, done.

[jarrett]

I should have mentioned: I was assuming the recipients weren't necessarily PGP users. Realistically, most people aren't. I'd imagine a dead man's switch would often be used to send documents to law enforcement, lawyers, journalists, etc. How many of those people have PGP public keys? If they don't, then you have to ask them to create one. Besides the difficulty in getting people to adopt PGP, you're also back the problem of disclosing your dead man's switch prior to your death.

[gingerlime]

I wonder if you can split things between several switches. In the most simple scenario, DMS #1 would receive an encrypted file to be sent to Bob in case of Alice's death. DMS #2 would receive a passphrase for the encrypted file, also to be sent to Bob (or they can be sent to Ben, who would have to meet Bob and both of them together get access)

DMS #1 and #2 (Assuming there are several 'providers' in the 'market') would need to collude or both get hacked in order to compromise the secret.

If there are more DMS services, the key can also be split between them. And I believe there are some key-splitting algorithms that even help this process further.

[jarrett]

That's a good idea. I think you're right: An attacker would have to compromise all the DMSs to obtain the plaintext. That's not outside the realm of possibilities. But it is much harder than compromising just one. At that point, the DMSs might not be the weak link in the chain anymore--an attacker might find it easier to attack your own systems. (Which is a good thing.)

[kryptiskt]

> So I'm wondering: Is there any way to do this a) with encryption, b) without entrusting the keys to the operator of the service, and c) without informing the recipients in advance?

Give half the key to the service and half to your friends, then you're only vulnerable to a conspiracy between them. Or do some more elaborate m of n thing.

[jarrett]

What about my third desire:

> c) without informing the recipients in advance

If you're willing to arrange the protocols with your recipients in advance, there are multiple viable approaches. But what if telling them in advance is itself a security risk?

[tlrobinson]

"it's unclear what the motivation for running an instance of this kind of P2P application would be"

Incentivising P2P applications is one of the interesting problems Bitcoin could solve.

People have talked about building P2P storage applications using Bitcoin, which is essentially what this would be, except if you stop paying into the network the files should be transmitted to some 3rd party of your choosing instead of being destroyed.

Perhaps some splitting scheme such as Shamir's Secret Sharing could be layered on top.

[fjcaetano]

An alternative is a personal instance of a DMS for each person. Maybe a Github repo linked to a service provider, like Heroku, where each person manages their own switch.

One may say this is too complicated and the layman wouldn't know how to do this, but laymen wouldn't have the need for this. Anyone who is not satisfied with the given service, must have the power and will to change it to their needs.

[yannk]

I have been toying with the idea for a little while too. Distributed, open and safe where on the top of my list.