[IncRnd]

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 confidentiality preserved? The integrity of the keys? What if the keys are changed or deleted? How are DOSes protected against, so early disclosures don't get forced?

There are quite a few issues with the project. Unfortunately, killcord doesn't seem ready for release into prime-time as a key-management method. Killcord seems equivalent in intended operation to a non-blockchain HSM, but all the protections of an HSM, all the key management, all the security controls, they are all gone. This actually introduces security issues instead of solving for them.

What is the actual problem that killcord is attempting to solve? There are likely more robust designs, such as secret sharing, that will solve the target problem.

[rojoroboto]

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 systems like Vault, Chamber, or other secret stores in the future.

It is also, indeed, early alpha and dealing with secret management for the owner and publisher are absolutely top of mind.

[sowbug]

See also https://github.com/petertodd/timelock and similar projects. There might be a way to combine these two concepts plus ephemeral keys as used in perfect forward secrecy, so that the switching technology isn't a single decision to publish a key, but rather time-locking a share of a Shamir-split secret and constantly rolling it forward as the pings happen -- or letting it run out and reveal enough shares for anyone to decrypt.

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.

[IncRnd]

> It is also, indeed, early alpha and dealing with secret management for the owner and publisher are absolutely top of mind.

Awesome! Please keep building, for sure. :). Please just be bit careful about using security language in a way that people will misunderstand.