Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A censorship resistant deadman's switch

killcord.io

Post reply on HN
Print view View original

11–20 of 69 posts

Re: A censorship resistant deadman's switch

#11

Post by danielvf »

danShumway wrote: post #9
wyas wrote: post #6

Earlier quoted context omitted.

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 t…

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…

The one attack that I can see it blocking is that it allows for 100% untraceable monitoring [edit: of the deadman's switch by the the system-that-should-send-the-message]. Since every bit of data pushed to Ethereum goes to every single full node, you can't find out who has the keys to the secret data and will release them.

Re: A censorship resistant deadman's switch

#13

Post by wyas »

danShumway wrote: post #9
wyas wrote: post #6

Earlier quoted context omitted.

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 t…

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…

There's a bunch of attack vectors, but most fall on the trusted publisher and client itself. IPFS and Ethereum are, by assumption (difficulty wise), ``secure''.

Assuming both client and publisher's internal systems are intact, then you have two attack vectors:

There's the false positive attack vector, where you can shut down the client's network access and force the secret to be prematurely leaked.

There's the false negative attack vector, where you can shut down the trusted publisher's network access, and indefinitely keep the secret ``safe''.

However, in general, the first attack is not as worrisome as the second for these kinds of application. The second is more worrisome, and there's many ways to distribute the trusted published using some crypto threshold scheme such that as long as no more than some threshold of the trusted publishers are shut down, the secret will be released in case of client shutdown.

Re: A censorship resistant deadman's switch

#15

Post by danShumway »

danielvf wrote: post #11
danShumway wrote: post #9

Earlier quoted context omitted.

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…

The one attack that I can see it blocking is that it allows for 100% untraceable monitoring [edit: of the deadman's switch by the the system-that-should-send-the-message]. Since every bit of data pushed to Ethereum goes to every single full node, you can't find out who has the keys to the secret data and will release them.

Oh, cool, this would actually help protect against a lot of things!

If you can set up a deadman's switch and there's no way to figure out who it belongs to, that should make it significantly harder to find out which publisher to attack.

Contrast that against 'every day at 5, I publish a signed checkin to Facebook, Twitter, Reddit, Dropbox, my blog, and a hundred other sites simultaneously.'

In that scenario, blocking or faking the trigger isn't the attack vector. The attack vector is that it's really obvious who the trigger belongs to, so to find the publishing IP an attacker can just monitor who connects to those domains.

I guess the trick is actually getting Ether anonymously, but that's not the hardest problem in the world to solve.

Re: A censorship resistant deadman's switch

#16

Post by matte_black »

arisAlexis wrote: post #12

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

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.

Re: A censorship resistant deadman's switch

#18

Post by tshannon »

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?

Re: A censorship resistant deadman's switch

#19

Post by azernik »

matte_black wrote: post #16
arisAlexis wrote: post #12

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

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.

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.

Re: A censorship resistant deadman's switch

#20

Post by rtkwe »

decentralised wrote: post #8
ofcourseianal wrote: post #2

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

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.

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.
Post reply on HN