| Security
VESvault Corp. builds end-to-end encryption products: VES, a key management and recovery service, and VESmail, end-to-end email encryption for existing IMAP accounts. This page describes how our security works, precisely what it does and does not protect, and how to report a vulnerability. Architecture and key custody
All encryption and decryption happens on the user's device. VESvault servers store only encrypted key material and ciphertext: public keys, private keys encrypted under keys we never receive, and encrypted data items. The VESkey — the user's master passphrase — and the app keys derived from it are never transmitted to or stored by VESvault in usable form. A detailed map of what is stored where, who can access it, and every attack scenario we have analyzed is published in the VESvault Security Assessment. Encryption
VES is not proprietary cryptography. We use standard, open algorithms with published specifications: • AES-256-GCM for symmetric encryption
(spec) The client libraries are open source: libVES.js and libVES.c. Recovery: the trust model, stated exactly
VESrecovery lets a user regain access after losing their VESkey with the assistance of friends they selected in advance. The recovery key is scrambled into tokens using secret-sharing techniques; individual tokens are useless on their own. We state the trust model precisely, because it is where careless claims would be easiest to make: recovery security is enforced by a combination of cryptographic secret-splitting, server-side access control, and a user-configurable security time delay with real-time notification. It is not purely cryptographic. A group of colluding recovery friends cannot decrypt a user's data through the normal operation of the system, but this guarantee depends on VESvault's access-control layer, not on mathematics alone. The exact conditions under which recovery-related attacks could succeed, and their mitigations, are analyzed in the Security Assessment and in the published VESrecovery threat model. Scope limits
Security claims are only useful when their boundaries are explicit. Ours: • VESmail encrypts what passes through it. Messages sent through VESmail, and copies it saves to mail folders, are encrypted at rest. Mail that arrives in plaintext from senders outside VESmail remains plaintext on the mail server. VESmail does not provide whole-mailbox at-rest encryption. • Recovery is access-control enforced, as described above — not "cryptographically impossible to abuse." • Item version history and authorship metadata are server-maintained records. They are suitable for operational review, but they are not client-signed cryptographic attestations. Reporting a vulnerability
Please do not open public issues, pull requests, or discussions for security problems. Email security@vesvault.com with a description of the issue, steps to reproduce, and affected versions. If you need to share sensitive details, say so in your first message and we will arrange an encrypted channel. We aim to acknowledge reports within 3 business days and to share an initial assessment within 10 business days. We coordinate disclosure timelines with reporters and ask for a reasonable window to ship a fix before publication, typically up to 90 days. This policy covers the hosted VESvault service and APIs as well as our open-source repositories, each of which carries the same policy in its SECURITY.md. Machine-readable contact information is published at /.well-known/security.txt (RFC 9116). Security documentation
• VESvault Security Assessment — data inventory, access control, attack scenarios Infrastructure and subprocessors
A current list of infrastructure providers and subprocessors is available on request at security@vesvault.com. Last updated: July 15, 2026 |