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 (Shamir over
GF(256), scheme
SSS1). No single party — and no coalition of contacts — can recover your keys alone: each share is stored encrypted to its contact's key, so the server can't read any share; contacts never receive your encrypted keys; and recovery is time-delay protected and visible to the owner. - 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) |
| 📝 VESpost | Reference app — e2ee collaborative sticky notes in ~300 lines of libVES.subtle (live demo) |
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.
