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