9 ms·

A censorship resistant deadman's switch

184 points by heelhook 8y ago

ofcourseianal 8y ago
Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.
- snissn 8y ago
  Water resistant vs water proof
- w-m 8y ago
  And a landing page that omits this fact (but contains download and instructions for a command line tool). If you're thinking "wait, I can't put a self-publishing secret on the Ethereum blockchain, how does this even work?", the landing page leaves you hanging.
  - rojoroboto 8y ago
    This is true. I'm working with a friend who is a copy writer to help make the landing page clearer and more helpful.
- decentralised 8y ago
  Even if the web front end is taken down, the contract is still on-chain so it can be accessed via a web3 browser, a client or even in etherscan in the "read contract" tab.
  - rtkwe 8y ago
    That just lets you see the contract. The decryption keys by necessity can't be located on the Etherium chain at all and have to be held by a trusted 3rd party/system that watches the contract and releases the keys when the checkin doesn't happen. If the attacker is able to locate and disable that system then the killcord is essentially diffused the owner would have to manually publish or have setup backups.
    - rojoroboto 8y ago
      Right. The decryption keys aren't on the blockchain until they are "published". If all publishers are compromised or shut off before that happens, the killcord project has been terminated.
      - rtkwe 8y ago
        Yeah, though finding them should be fairly hard because all they will look like from a network traffic perspective should be a normal-ish etherium non mining node and no direct communication between owner and publisher should exist after initial setup. Anyone planning on using this for serious matters should make sure that their trusted publishers are hosted anonymously (as far as is possible) or so spread out jurisdictionally to make attacking them all impractical.
- rojoroboto 8y ago
  This is a valid concern and why I'd encourage running multiple instance (geographically distributed) of the publisher.
deleted 8y ago
[deleted]
danShumway 8y ago
This is interesting, but runs contrary to my understanding of how Etherium works. I'm clearly missing something, any chance you (or anyone else) could elaborate more? My understanding was that the decentralization of Etherium would mean that everyone watching the contract would need a copy of the decryption key. If that's the case, what prevents someone from publishing keys early? Or is it that the key isn't stored in Etherium, and Etherium is only being used as the consent to publish? If the key is being stored somewhere else and just waiting for the contract to validate, how do we prevent a censor from just attacking that system? If the key is being stored somewhere else and just waiting for the contract to validate, why not also store the contract on the same machine and do checkins directly into that? Would that be significantly less secure/reliable?
- wyas 8y ago
  Quick browse seems to be like so: 1. Client generates necessary files (including keys and payloads). 2. Encrypted payload is placed on IPFS. 3. Keys are placed on a trusted published (potentially single point of failure). 4. A smart contract running on the EVM continuously checks for pings from clients. If client doesn't check in over some pre-defined policy, then trusted published will be aware and publish keys to the smart contract, visible to everyone.
  - danShumway 8y ago
    Is that... good? I mean, I understand that security isn't black and white, and really you're just trying to make it harder for someone to attack you, not impossible. But how much do you gain by decentralizing just the trigger? Since the trigger logic fundamentally relies on you doing something, it seems like that logic could be local to machine, your machine could query any number of public websites/platforms/IPs and it would still be pretty difficult for anyone to censor you. It also seems like a party that wanted to force you to publish early would not be hampered in any significant way by Etherium. In either scenario, all they have to do is incapacitate you or block the IPs that your machine is looking at. I still feel like I'm missing something. Would anyone be willing to break down a (fictional or real) scenario where adding Etherium to this equation blocks an attack?
robert-wallis 8y ago
What if the miners deny check-in transactions to force the killcord to execute?
- rtkwe 8y ago
  The whole idea is kind of predicated on whoever you're worried about attacking you not wanting the information to get out more than they care about getting to the person holding the dead man's switch. If they are more concerned with getting to that person than with whatever information the person has threatened to publish no level of security on the switch matters it just becomes part of the cost of getting to the owner.
- VectorLock 8y ago
  You're boned. Then most systems including Ethereum are based on the assumption that the miners aren't majority controlled by an adversary. That may or may not be a sound assumption.
arisAlexis 8y ago
if someone puts a gun and steals your private key he can continue checking in after he kills you right?
- matte_black 8y ago
  No, if you have ordered keys and only you know the order, there is no way to do it unless you give the order, and even then there’s no way to confirm the order is correct without trying it. The way around this is to threaten not to kill the target, but rather kill their whole family or those they care about viciously and painfully, and be ready to do it, if the order is wrong and there is an automated leak.
  - azernik 8y ago
    Well sure, just like you could give them the wrong private key. I always find these arguments against coercion attacks unconvincing. "Well, they can force you to give them information A, but for some reason not force you to give them information B." No, they'll put you in jail and force you to give them all the information needed to send check-ins, period.
- rojoroboto 8y ago
  Yes. In the current form, If someone gets the project owner config file they could continue to check-in indefinitely. I've been toying with the idea of optionally encrypted the owner config with a passphrase to mitigate this. It would even be possible to have a secondary "duress password" that pretends to decrypt the config, but publishes instead.
  - arisAlexis 8y ago
    but it should give the attacker confirmation that all is ok and somehow the attacker can't know that it was published?
deleted 8y ago
[deleted]
tshannon 8y ago
So a lot of these comments seem to be criticisms of potential vulnerabilities (which is par for hacker news really). I'm curious if there are better alternatives out there that aren't vulnerable to the same issues, like a single point of failure or attack?
- carussell 8y ago
  You could do secret splitting: http://www.moserware.com/2011/11/life-death-and-splitting-secrets.html http://www.moserware.com/2011/11/life-death-and-splitting-se... It's vulnerable in that whichever threshold N that you choose allows for N participants to conspire to publish ahead of time, or M - N to conspire not to publish after the fact.
  - alanh 8y ago
    interesting. i hadn't seen this although I implemented something effectively the same, except that all keys (which could be any number ≥ 2) be combined to reveal the secret (or any information about it).
gnode 8y ago
Given that the trusted party is required for this to work, is there any point at all in having it depend on the Etherium blockchain, other than perhaps a weak form of anonymity network?
- shadowfiend 8y ago
  The trusted party can be factored into a decentralized network as well. This is what our team is working on with the Keep network (we've considered dead man switches as potential applications for a while).
- rojoroboto 8y ago
  The purpose of killcord + ethereum for public disclosures is that leaning on ethereum as an API backend ties itself to the fact that taking down the entire ethereum network is difficult and running your own backend resiliently is hard. That being said, I'm working on the concept of "providers" so that storage, payload, and backend can be plugable and you'll be able to use whatever backend you are comfortable with.
fareesh 8y ago
Does this take into account network congestion and such?
- microcolonel 8y ago
  If you can manage not to tell anyone what address the thing is running on.
- rojoroboto 8y ago
  This is left up to the killcord project owner to set the publisher threshold. If the project owner is concerned about congestion the owner should increase the time allotted to the threshold.
XR0CSWV3h3kZWg 8y ago
There is a lot of hate for the trusted party set up of this, which seems reasonable. It seems like you could create a dead man's switch using arbitrary participants. You distribute a secret to every participant and then to attempt to activate the dead man's switch they raise k to the power s mod p and pass it to the next participant. As long as you act as a participant each time and raise the passed value to some invalid s then the answer that is arrived at won't be the final secret. As long as you participate every round the wrong answer will be arrived at, but as soon as you don't participate the right answer will be arrived at. Any singular party refusing to cooperate would destroy the deadman's switch so malicious activation would be tough. Designing it so it can tolerate failures would be the hard part. EDIT: I am wrong, this isn't that great. It's really hard to hide information that can be recovered without a secret being revealed.
- eridius 8y ago
  What's the stop the other parties from simply running a round without you in order to find out what the secret is?
- danShumway 8y ago
  So, sort of like a secret generating linked list, where one node (you) are a bad actor? What prevents the participant right before you from simply circumventing you or secretly passing to the next participant directly? It also seems that once someone receives the correct answer for their step in the chain, they no longer need anyone beneath them? (A) -> (B) -> (C) -> (you) -> (D) Once C has participated in this one time, why do they need A or B?
  - XR0CSWV3h3kZWg 8y ago
    Good point. You'd likely want to also encode something that opaque to who exactly has participated, only really show whether this is the last step and a way for individuals to tell if they have already added their secret. The really bad part would be that if the poisoner happens to be the last step then the final step would produce the secret before handing it to be poisoned.
bowmessage 8y ago
Why is everyone suddenly spelling Ethereum with an '-ium'?
TekMol 8y ago
Better and simpler solution: Create a Bitcoin address and send one Satoshi to yourself every month. When the transactions stop, people know you are dead. This way you need no trusted third party, no special software, no special contract.
- sterlind 8y ago
  You're describing a different problem. Killcord solves the Insurance Policy problem: Suppose you're a whistleblower, who exfiltrated gigabytes of unredacted data from the NSA. So far you've leaked only redacted excerpts, but the NSA might kill you to stop your leaking. However, the NSA really doesn't want the whole archive leaked, or it would blow their agents' covers. So, you put the whole archive up on the net, encrypted, and set up Killcord to decrypt unless you keep checking in. This keeps you alive, since the NSA knows it'll leak if you're dead.
  - rojoroboto 8y ago
    yep. this falls in line with my design thinking on this.
- rojoroboto 8y ago
  This addresses the checkin aspect of killcord but it doesn't address the payload address broadcasting and decrytion key publication aspect of killcord. I am in the early stages of building a "providers" abstraction for killcord so that backend, publisher, etc are plugable. Using this bitcoin pattern for check-ins could be really cool.
rojoroboto 8y ago
Hey Gang. Author of killcord here. I'm honored and humbled this was submitted to HN and I'll be reading through the comments to answer questions and respond to feedback. I started this project after a thought experiment in using newer decentralized tech for internet activism.
- sterlind 8y ago
  Neat project! I thought up a trustless scheme for this a while back, but it's beyond my means to implement: You can encrypt an entire circuit with homomorphic encryption, which users can run without decrypting its internal state. Construct a device like so: Inputs: 1. Ethereum block 2. Previous run-state (encrypted) or zeros. Outputs: 1. Next run-state (encrypted) 2. Decryption key (if triggered) or zeros (if not.) Internal state: 0. Hash difficulty range 1. Hash of previous block seen 2. Pubkey to scan for 3. Counter of # blocks seen without a tx signed by pubkey. If you feed the device more than 1 week of blocks without a tx from pubkey, the accumulator hits zero and it spits out the secret. An attacker would have to mine 1 week of blocks at hash power IS.0 in order to trick the device into spilling its guts. If you die, and don't send txs for a week, anyone with the device can play a week of blocks into it and the secret will pop out. Unfortunately, homomorphic encryption is still too slow for this to be quite feasible. Food for thought though! And you can build this today with SGX, if you trust that.
  - rojoroboto 8y ago
    neat. Yeah, I picked symmetric encryption for the payload due to its relative simplicity, speed, and resiliency.
everdev 8y ago
Have any legal systems weighed in on a dead man's switch? I get the premise, where typically it's illegal to take an action that releases confidential or censored information. But, to governments, especially ones that want to keep information secret or censored, I'm not sure that negating that sequence and failing to stop the release of information (that you willingly put in a dead man's switch) will get you out of trouble. Unless you're dead of course. But, I've seen this process promoted for living people to release information and I'm not sure it's any better than just posting the content anonymously, but with the added risk of accidentally releasing the information.
dogma1138 8y ago
Anyone who would think of using it you need to consider at least 2 threat models. 1) The key castodian can decrypt your Information either willingly or through coercion. If you use the same key to sign and encrypt the message or if you do not sign it then they may also be able to impersonate you. 2) A third party who would gain from the information being disclosed can force its release through a denial attack. Never use a deadman switch as a bargaining or as an insurance policy if you do not intend the information to be released to the public and if you are not comfortable with the information being released the moment the switch is set up rather than when it would be activated. The only manner in which this or any simmilar setup does not expose you to additional risk is if you only use it to ensure the release of said information in a timely manner and there is no adversarial motive to release it sooner. @the creators you might want to look at the possibility of implementing https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing over a blockchain.
s17n 8y ago
As far as I can tell, Ethereum isn't actually doing anything interesting here - it's just being used to transmit pings to the server, which could just as easily be done with, for example, tcp/ip.
deleted 8y ago
[deleted]

184 points by heelhook 8y ago

ofcourseianal 8y ago

Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.

snissn 8y ago
Water resistant vs water proof
w-m 8y ago
And a landing page that omits this fact (but contains download and instructions for a command line tool). If you're thinking "wait, I can't put a self-publishing secret on the Ethereum blockchain, how does this even work?", the landing page leaves you hanging.
- rojoroboto 8y ago
  This is true. I'm working with a friend who is a copy writer to help make the landing page clearer and more helpful.
decentralised 8y ago
Even if the web front end is taken down, the contract is still on-chain so it can be accessed via a web3 browser, a client or even in etherscan in the "read contract" tab.
- rtkwe 8y ago
  That just lets you see the contract. The decryption keys by necessity can't be located on the Etherium chain at all and have to be held by a trusted 3rd party/system that watches the contract and releases the keys when the checkin doesn't happen. If the attacker is able to locate and disable that system then the killcord is essentially diffused the owner would have to manually publish or have setup backups.
  - rojoroboto 8y ago
    Right. The decryption keys aren't on the blockchain until they are "published". If all publishers are compromised or shut off before that happens, the killcord project has been terminated.
    - rtkwe 8y ago
      Yeah, though finding them should be fairly hard because all they will look like from a network traffic perspective should be a normal-ish etherium non mining node and no direct communication between owner and publisher should exist after initial setup. Anyone planning on using this for serious matters should make sure that their trusted publishers are hosted anonymously (as far as is possible) or so spread out jurisdictionally to make attacking them all impractical.
rojoroboto 8y ago
This is a valid concern and why I'd encourage running multiple instance (geographically distributed) of the publisher.

deleted 8y ago

[deleted]

danShumway 8y ago

This is interesting, but runs contrary to my understanding of how Etherium works. I'm clearly missing something, any chance you (or anyone else) could elaborate more? My understanding was that the decentralization of Etherium would mean that everyone watching the contract would need a copy of the decryption key. If that's the case, what prevents someone from publishing keys early? Or is it that the key isn't stored in Etherium, and Etherium is only being used as the consent to publish? If the key is being stored somewhere else and just waiting for the contract to validate, how do we prevent a censor from just attacking that system? If the key is being stored somewhere else and just waiting for the contract to validate, why not also store the contract on the same machine and do checkins directly into that? Would that be significantly less secure/reliable?

wyas 8y ago
Quick browse seems to be like so: 1. Client generates necessary files (including keys and payloads). 2. Encrypted payload is placed on IPFS. 3. Keys are placed on a trusted published (potentially single point of failure). 4. A smart contract running on the EVM continuously checks for pings from clients. If client doesn't check in over some pre-defined policy, then trusted published will be aware and publish keys to the smart contract, visible to everyone.
- danShumway 8y ago
  Is that... good? I mean, I understand that security isn't black and white, and really you're just trying to make it harder for someone to attack you, not impossible. But how much do you gain by decentralizing just the trigger? Since the trigger logic fundamentally relies on you doing something, it seems like that logic could be local to machine, your machine could query any number of public websites/platforms/IPs and it would still be pretty difficult for anyone to censor you. It also seems like a party that wanted to force you to publish early would not be hampered in any significant way by Etherium. In either scenario, all they have to do is incapacitate you or block the IPs that your machine is looking at. I still feel like I'm missing something. Would anyone be willing to break down a (fictional or real) scenario where adding Etherium to this equation blocks an attack?

robert-wallis 8y ago

What if the miners deny check-in transactions to force the killcord to execute?

rtkwe 8y ago
The whole idea is kind of predicated on whoever you're worried about attacking you not wanting the information to get out more than they care about getting to the person holding the dead man's switch. If they are more concerned with getting to that person than with whatever information the person has threatened to publish no level of security on the switch matters it just becomes part of the cost of getting to the owner.
VectorLock 8y ago
You're boned. Then most systems including Ethereum are based on the assumption that the miners aren't majority controlled by an adversary. That may or may not be a sound assumption.

arisAlexis 8y ago

if someone puts a gun and steals your private key he can continue checking in after he kills you right?

matte_black 8y ago
No, if you have ordered keys and only you know the order, there is no way to do it unless you give the order, and even then there’s no way to confirm the order is correct without trying it. The way around this is to threaten not to kill the target, but rather kill their whole family or those they care about viciously and painfully, and be ready to do it, if the order is wrong and there is an automated leak.
- azernik 8y ago
  Well sure, just like you could give them the wrong private key. I always find these arguments against coercion attacks unconvincing. "Well, they can force you to give them information A, but for some reason not force you to give them information B." No, they'll put you in jail and force you to give them all the information needed to send check-ins, period.
rojoroboto 8y ago
Yes. In the current form, If someone gets the project owner config file they could continue to check-in indefinitely. I've been toying with the idea of optionally encrypted the owner config with a passphrase to mitigate this. It would even be possible to have a secondary "duress password" that pretends to decrypt the config, but publishes instead.
- arisAlexis 8y ago
  but it should give the attacker confirmation that all is ok and somehow the attacker can't know that it was published?

deleted 8y ago

[deleted]

tshannon 8y ago

So a lot of these comments seem to be criticisms of potential vulnerabilities (which is par for hacker news really). I'm curious if there are better alternatives out there that aren't vulnerable to the same issues, like a single point of failure or attack?

carussell 8y ago
You could do secret splitting: http://www.moserware.com/2011/11/life-death-and-splitting-secrets.html http://www.moserware.com/2011/11/life-death-and-splitting-se... It's vulnerable in that whichever threshold N that you choose allows for N participants to conspire to publish ahead of time, or M - N to conspire not to publish after the fact.
- alanh 8y ago
  interesting. i hadn't seen this although I implemented something effectively the same, except that all keys (which could be any number ≥ 2) be combined to reveal the secret (or any information about it).

gnode 8y ago

Given that the trusted party is required for this to work, is there any point at all in having it depend on the Etherium blockchain, other than perhaps a weak form of anonymity network?

shadowfiend 8y ago
The trusted party can be factored into a decentralized network as well. This is what our team is working on with the Keep network (we've considered dead man switches as potential applications for a while).
rojoroboto 8y ago
The purpose of killcord + ethereum for public disclosures is that leaning on ethereum as an API backend ties itself to the fact that taking down the entire ethereum network is difficult and running your own backend resiliently is hard. That being said, I'm working on the concept of "providers" so that storage, payload, and backend can be plugable and you'll be able to use whatever backend you are comfortable with.

fareesh 8y ago

Does this take into account network congestion and such?

microcolonel 8y ago
If you can manage not to tell anyone what address the thing is running on.
rojoroboto 8y ago
This is left up to the killcord project owner to set the publisher threshold. If the project owner is concerned about congestion the owner should increase the time allotted to the threshold.

XR0CSWV3h3kZWg 8y ago

There is a lot of hate for the trusted party set up of this, which seems reasonable. It seems like you could create a dead man's switch using arbitrary participants. You distribute a secret to every participant and then to attempt to activate the dead man's switch they raise k to the power s mod p and pass it to the next participant. As long as you act as a participant each time and raise the passed value to some invalid s then the answer that is arrived at won't be the final secret. As long as you participate every round the wrong answer will be arrived at, but as soon as you don't participate the right answer will be arrived at. Any singular party refusing to cooperate would destroy the deadman's switch so malicious activation would be tough. Designing it so it can tolerate failures would be the hard part. EDIT: I am wrong, this isn't that great. It's really hard to hide information that can be recovered without a secret being revealed.

eridius 8y ago
What's the stop the other parties from simply running a round without you in order to find out what the secret is?
danShumway 8y ago
So, sort of like a secret generating linked list, where one node (you) are a bad actor? What prevents the participant right before you from simply circumventing you or secretly passing to the next participant directly? It also seems that once someone receives the correct answer for their step in the chain, they no longer need anyone beneath them? (A) -> (B) -> (C) -> (you) -> (D) Once C has participated in this one time, why do they need A or B?
- XR0CSWV3h3kZWg 8y ago
  Good point. You'd likely want to also encode something that opaque to who exactly has participated, only really show whether this is the last step and a way for individuals to tell if they have already added their secret. The really bad part would be that if the poisoner happens to be the last step then the final step would produce the secret before handing it to be poisoned.

bowmessage 8y ago

Why is everyone suddenly spelling Ethereum with an '-ium'?

TekMol 8y ago

Better and simpler solution: Create a Bitcoin address and send one Satoshi to yourself every month. When the transactions stop, people know you are dead. This way you need no trusted third party, no special software, no special contract.

sterlind 8y ago
You're describing a different problem. Killcord solves the Insurance Policy problem: Suppose you're a whistleblower, who exfiltrated gigabytes of unredacted data from the NSA. So far you've leaked only redacted excerpts, but the NSA might kill you to stop your leaking. However, the NSA really doesn't want the whole archive leaked, or it would blow their agents' covers. So, you put the whole archive up on the net, encrypted, and set up Killcord to decrypt unless you keep checking in. This keeps you alive, since the NSA knows it'll leak if you're dead.
- rojoroboto 8y ago
  yep. this falls in line with my design thinking on this.
rojoroboto 8y ago
This addresses the checkin aspect of killcord but it doesn't address the payload address broadcasting and decrytion key publication aspect of killcord. I am in the early stages of building a "providers" abstraction for killcord so that backend, publisher, etc are plugable. Using this bitcoin pattern for check-ins could be really cool.

rojoroboto 8y ago

Hey Gang. Author of killcord here. I'm honored and humbled this was submitted to HN and I'll be reading through the comments to answer questions and respond to feedback. I started this project after a thought experiment in using newer decentralized tech for internet activism.

sterlind 8y ago
Neat project! I thought up a trustless scheme for this a while back, but it's beyond my means to implement: You can encrypt an entire circuit with homomorphic encryption, which users can run without decrypting its internal state. Construct a device like so: Inputs: 1. Ethereum block 2. Previous run-state (encrypted) or zeros. Outputs: 1. Next run-state (encrypted) 2. Decryption key (if triggered) or zeros (if not.) Internal state: 0. Hash difficulty range 1. Hash of previous block seen 2. Pubkey to scan for 3. Counter of # blocks seen without a tx signed by pubkey. If you feed the device more than 1 week of blocks without a tx from pubkey, the accumulator hits zero and it spits out the secret. An attacker would have to mine 1 week of blocks at hash power IS.0 in order to trick the device into spilling its guts. If you die, and don't send txs for a week, anyone with the device can play a week of blocks into it and the secret will pop out. Unfortunately, homomorphic encryption is still too slow for this to be quite feasible. Food for thought though! And you can build this today with SGX, if you trust that.
- rojoroboto 8y ago
  neat. Yeah, I picked symmetric encryption for the payload due to its relative simplicity, speed, and resiliency.

everdev 8y ago

Have any legal systems weighed in on a dead man's switch? I get the premise, where typically it's illegal to take an action that releases confidential or censored information. But, to governments, especially ones that want to keep information secret or censored, I'm not sure that negating that sequence and failing to stop the release of information (that you willingly put in a dead man's switch) will get you out of trouble. Unless you're dead of course. But, I've seen this process promoted for living people to release information and I'm not sure it's any better than just posting the content anonymously, but with the added risk of accidentally releasing the information.

dogma1138 8y ago

Anyone who would think of using it you need to consider at least 2 threat models. 1) The key castodian can decrypt your Information either willingly or through coercion. If you use the same key to sign and encrypt the message or if you do not sign it then they may also be able to impersonate you. 2) A third party who would gain from the information being disclosed can force its release through a denial attack. Never use a deadman switch as a bargaining or as an insurance policy if you do not intend the information to be released to the public and if you are not comfortable with the information being released the moment the switch is set up rather than when it would be activated. The only manner in which this or any simmilar setup does not expose you to additional risk is if you only use it to ensure the release of said information in a timely manner and there is no adversarial motive to release it sooner. @the creators you might want to look at the possibility of implementing https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing over a blockchain.

s17n 8y ago

As far as I can tell, Ethereum isn't actually doing anything interesting here - it's just being used to transmit pings to the server, which could just as easily be done with, for example, tcp/ip.

deleted 8y ago

[deleted]