6 ms·

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 rega

by john_b 13y ago

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 13y ago
Obviously the solution is a DeadManSwitchCoin.
- arielweisberg 13y ago
  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 https://news.ycombinator.com/item?id=6509824
  - tlrobinson 13y ago
    gwern has a great summary of "time-lock encryption" possibilities: http://www.gwern.net/Self-decrypting%20files http://www.gwern.net/Self-decrypting%20files
  - tormeh 13y ago
    I think your sarcasm-meter failed you.
  - smithzvk 13y ago
    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.
yannk 13y ago
I have been toying with the idea for a little while too. Distributed, open and safe where on the top of my list.
jarrett 13y ago
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?
- gingerlime 13y ago
  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 13y ago
    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.)
- StavrosK 13y ago
  Yes, that's what PGP is for. Encrypt whatever you want to the recipient(s)' public keys, done.
fjcaetano 13y ago
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.
tlrobinson 13y ago
"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.

by john_b 13y ago

eudox 13y ago

Obviously the solution is a DeadManSwitchCoin.

arielweisberg 13y ago
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 https://news.ycombinator.com/item?id=6509824
- tlrobinson 13y ago
  gwern has a great summary of "time-lock encryption" possibilities: http://www.gwern.net/Self-decrypting%20files http://www.gwern.net/Self-decrypting%20files
- tormeh 13y ago
  I think your sarcasm-meter failed you.
- smithzvk 13y ago
  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.

yannk 13y ago

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

jarrett 13y ago

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?

gingerlime 13y ago
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 13y ago
  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.)
StavrosK 13y ago
Yes, that's what PGP is for. Encrypt whatever you want to the recipient(s)' public keys, done.

fjcaetano 13y ago

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.

tlrobinson 13y ago

"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.