Real end-to-end encryption — with a way back in.
VESvault gives developers true end-to-end encryption and a realistic recovery path after a lost device — without the service ever being able to read your keys or your data. New keys are post-quantum by default (ML-KEM / FIPS 203).
- Zero-knowledge server. It stores only public keys, encrypted private keys, and encrypted vault entries. It never sees a VESkey or a decrypted private key — every decryption happens client-side.
- Recovery without a backdoor. Total device loss is handled by threshold
secret sharing among recovery contacts you choose in advance (scheme
RDX1.2). No single party — not the server, not any one contact — can recover your keys alone. - Open source. The client libraries and the
vesCLI are Apache-2.0.
Encryption libraries
| 📦 libVES.c | End-to-end encryption for data at rest — C library + ves CLI |
| 📦 libVES | End-to-end encryption for the browser & Node — JavaScript (npm: libves) |
Apps & services
| ✉️ VESmail | End-to-end encrypted email via a local proxy (Android · Apple · Windows) |
| 🔐 VESlocker | Hardware-grade PIN security API |
| 🌐 SNIF | End-to-end TLS trust for IoT |
- 📖 Developer Center — docs, specs, REST APIs
- 🌐 vesvault.com — what is VES?
- 🍺 homebrew-ves —
brewtap for libVES.c & the VES CLI
Questions, integration help, ideas, and design scrutiny are all welcome in Discussions. We built VES to be examined — hard questions about the threat model are exactly what we want.
Security issues: please report vulnerabilities privately — see our security policy — not in a public Discussion or issue.
