The Unlocked Key Problem
Why OS keychains protect only cold credentials, and why freedom tech clients are pushing private keys into dedicated companion processes.
An enduring assumption among desktop and mobile users is that an operating system keychain offers continuous protection for cryptographic secrets. But as client software handles increasingly complex media formats, public JSON feeds, and untrusted network payloads, architectural discussions are refocusing on what happens after a key is loaded into process memory.
keychain only helps while the key is sitting still. like a stolen laptop, copied home directory, or a backup someone restores. it does nothing about bad code in the process that already unlocked the key. that’s why the key should live in its own process, not the one decoding public pictures or JSONs.
The distinction separates physical-theft resistance from memory safety during active execution. When an application that renders arbitrary web content, uncompressed bitmaps, or complex protocol schemas shares an address space with an unlocked private key, any vulnerability in media decoders becomes a potential credential leak. The emerging consensus across privacy clients points toward isolating signing operations into sandboxed companion daemons, where untrusted incoming data never crosses the execution boundary.