[wyas]

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]

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?

[wyas]

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.

[xg15]

I imagine the second attack may be mitigated by the fact that the publisher might be easier to hide than with direct access. E.g., if your dead man's switch were just some daemon running on a machine somewhere that you have to ping periodically, attackers could find the IP address of the daemon by watching your network traffic.

In the OP, you and the daemon (aka the trusted publisher) communicate exclusively via the blockchain, so it will be a lot more difficult to find the daemon's location.

Not sure if this is in any way better than just accessing the daemon through Tor though.

[rojoroboto]

These are valid points and anyone thinking about using killcord should be aware of these.

As for the second attack vector, the publisher is built with idempotence, so it is important that a killcord owner configures n-number of publishers in geographically diverse areas to mitigate the false negative attack vector.

[danielvf]

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.

[danShumway]

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.

[dooglius]

No, the message sending system still needs to actually send the message to the network at some point, which gives away the sender’s IP.

[danielvf]

Fixed my post. You are correct - just one side is secure.

[gruez]

You can achieve the same with tor hidden service.

[VectorLock]

Its basically treating Ethereum as an anonymous signal bus.

[tantalor]

If your machine is within range of your enemy, then they could simply destroy or disable it before publishing (a single point of failure).