51–60 of 69 posts
if someone puts a gun and steals your private key he can continue checking in after he kills you right?
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.
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.
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.) I…
Earlier quoted context omitted.
Killcord is described as resilient and resistant. The resilience is undefined, and the resistance is defined as censorship resistance. I'll ignore the censorship resistance, as it doesn't seem to have any qualities different from any other Ethereum contract. I don't see what this project is resilient against. In fact is seems unable to recover from issues such as the trusted third party publishing early. How is key c…
Solid feedback. Killcord is designed to let the public know that a killcord project exists, where to find the encrypted payload, and how to check the status of the killcord project. Unpublished secrets are currently stored on the owner and publisher project folders in clear text on a config file. This isn't meant to replace an HSM or secret manager, by any means. Though I've got some ideas on how to incorporate syste…
Awesome! Please keep building, for sure. :). Please just be bit careful about using security language in a way that people will misunderstand.
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?
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.
Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.
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.
I'm working with a friend who is a copy writer to help make the landing page clearer and more helpful.
Earlier quoted context omitted.
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.
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.
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.
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.
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 over a blockchain.
Earlier quoted context omitted.
Killcord is described as resilient and resistant. The resilience is undefined, and the resistance is defined as censorship resistance. I'll ignore the censorship resistance, as it doesn't seem to have any qualities different from any other Ethereum contract. I don't see what this project is resilient against. In fact is seems unable to recover from issues such as the trusted third party publishing early. How is key c…
Solid feedback. Killcord is designed to let the public know that a killcord project exists, where to find the encrypted payload, and how to check the status of the killcord project. Unpublished secrets are currently stored on the owner and publisher project folders in clear text on a config file. This isn't meant to replace an HSM or secret manager, by any means. Though I've got some ideas on how to incorporate syste…
I think it's really, really hard to guarantee that information has been destroyed, especially in a decentralized system, so you won't have the assurance that information was (1) available to encrypt, then (2) unavailable to anyone because it was destroyed, and then (3) somehow recovered, recalculated, or discovered to once again allow decryption. That feels isomorphic to the problem of time travel.
But maybe combining these technologies will provide a way to compartmentalize the risk of early disclosure sufficiently to satisfy some use cases.