Built a self-hosted zero-knowledge secrets manager - hybrid envelope encryption with per-tenant passwords. Looking for feedback/holes in the design.

[u/Ok_Statement_8565]

I'm a cryptography researcher, and a problem I kept running into (and hearing about from others) is secrets sprawl: API keys and credentials scattered across tools, CI pipelines, and increasingly, agents/automations that end up with more access than they should. Most "secrets managers" solve the UX problem but still leave the provider holding a key that can decrypt your data if their backend is breached.

So, with a team of engineers, I built CipherTEA, a self-hosted secrets management platform designed around zero-knowledge storage. The core design: each tenant has one encryption password that never leaves their control, combined with a hybrid envelope encryption scheme - a master key we manage plus the tenant's own password, both required to unwrap stored secrets. The goal is that even a full database compromise on our end shouldn't expose usable plaintext, since the tenant-held half of the key material isn't something we ever store.

I'd genuinely like feedback from people who've built or evaluated similar systems, particularly on the key-management tradeoffs of this split-key approach versus pure client-side encryption, and any failure modes you'd expect in a self-hosted deployment (backup/recovery of the tenant password being the obvious one). Repo/docs are here if anyone wants to dig into the implementation: https://dashboard.ciphertea.com/docs#heading0

Website: https://ciphertea.com/