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