Every password manager asks you to trust someone. 1Password, Bitwarden, LastPass—they all promise your secrets are encrypted and safe. But you’re still trusting their infrastructure, their security practices, their business continuity. If they get breached, acquired, or shut down, you’re scrambling. And try sharing a secret with someone at a different company using a different password manager? You’re back to encrypted email attachments or awkward workarounds.
I’m building something different. What if secret management worked like email? Not the centralized webmail services most people use today, but the original federated model where anyone can run a mail server and communicate with any other server. No single company controlling the network. No central point of failure.
Email works because alice@company-a.com can send messages to bob@company-b.com without asking permission from a central authority. The protocol is open. The network is federated. You can self-host or pay for hosting. That’s the model I’m applying to secret management with KeyPears.
The core idea: attach a public key to every email-style address. When Alice wants to share a secret with Bob, her KeyPears client discovers Bob’s public key at his domain (bobscompany.com), then uses Diffie-Hellman key exchange to create a shared secret. They can now communicate securely without either of their servers reading the contents.
This isn’t a new protocol—Diffie-Hellman has been around since 1976. What’s new is wrapping it in an email-like architecture that makes decentralized secret management actually usable.
Let me walk through a concrete example. Alice needs to share a database password with Bob. They work at different companies, use different infrastructure, but both run KeyPears clients.
Alice types bob@bobscompany.com into her KeyPears app and creates a new shared secret. Her client makes an API request to bobscompany.com and retrieves Bob’s public key. Behind the scenes, her client uses Diffie-Hellman to compute a shared secret that only Alice and Bob can derive. She encrypts the database password with this shared secret and uploads it to Bob’s server.
Bob’s KeyPears client checks his server, finds the encrypted message from Alice, and decrypts it using his private key. He now has the database password. Neither Alice’s server nor Bob’s server could read the contents at any point. The cryptography happens entirely client-side.
If Bob doesn’t have a server, that’s fine too. KeyPears works fully offline as a local password manager. The server is optional—it just enables synchronization and discovery.
I’m designing KeyPears around three primary use cases at launch.
First, password management. The local-first client works like any other password manager—store passwords, API keys, environment variables. But unlike traditional password managers, your secrets sync across devices with end-to-end encryption that your server can’t break. And when you need to share a production API key with a contractor at a different company, you can send it directly through KeyPears instead of pasting it into Slack.
Second, cryptocurrency wallets. KeyPears manages private keys with full self-custody. Your keys stay encrypted on your devices and sync between your laptop and phone. If you want to share a wallet backup with a trusted family member, you can send it through KeyPears with the same Diffie-Hellman exchange. No third party custodian. No recovery service that might get hacked. Just you and the people you explicitly share with.
Third, secure messaging. Not a replacement for Signal or WhatsApp, but a way to exchange sensitive information across organizational boundaries. When you need to send financial details, legal documents, or confidential project information to someone at another company, KeyPears gives you a channel that neither company’s IT department can intercept.
Centralized services create single points of failure. When a password manager gets breached, millions of users are at risk simultaneously. When a company changes their pricing or terms of service, you have no recourse. When they shut down, you’re migrating in a panic.
KeyPears removes these failure modes. You can self-host your own node with full control over your infrastructure. Or you can use a commercial hosting provider if you prefer convenience. Or your employer can run a node for your team. Or you can just use the local client without any server at all.
The network is federated like email. Multiple independent nodes coexist and communicate. No central authority controls who can participate. The protocol is open source (Apache 2.0). Anyone can run a node, build a client, or fork the codebase.
This creates a marketplace of providers instead of a monopoly. If you don’t like your hosting provider’s terms, you switch. If a provider goes down, the network continues. If a government tries to shut down KeyPears, there’s no central server to raid.
KeyPears is still in active development. I’ve published some introductory posts at keypears.com that go deeper into the technical architecture, cryptographic primitives, and security model. The core is implemented in Rust with TypeScript clients, using Blake3 for hashing, and AES-256-CBC for encryption.
I’m building this as part of my work at Identellica, where we’re focused on decentralized identity and cryptographic systems. KeyPears sits at the intersection of several things I care about: practical cryptography, decentralization, developer tools, and self-custody for cryptocurrency.
If this sounds interesting, check out keypears.com for more details. I’ll be posting updates as the project progresses. The goal is to make decentralized secret management as straightforward as email—familiar enough that anyone can use it, open enough that anyone can host it, and secure enough that you never have to trust a central authority with your most sensitive data.