End-to-end encryption you can actually recover from

Real end-to-end encryption with a way back in after a lost device — and now post-quantum by default.

End-to-end encryption has one notorious failure mode: lose the key and the data is gone forever. There is no “forgot password” link for a private key. That single problem is why most “encrypted” products quietly fall back to server-side encryption — where the provider holds the keys and can read everything.

VES is built to give you real end-to-end encryption and a realistic way back in after a lost device — without the service ever being able to read your keys or your data. libVES.c is the C implementation (plus ves, a command-line tool); there is also a JavaScript library. All Apache-2.0.

How recovery works without a backdoor

The server is a zero-knowledge store and router: it holds public keys, encrypted private keys, and encrypted vault entries. It never receives a VESkey or a decrypted private key — every decryption happens client-side. Sharing a value with someone is just “add a copy of the content key encrypted to their key,” and that one primitive — re-sharing a key to a new key — powers both everyday access and catastrophic recovery.

The common case is mundane — a new phone, a second laptop. Your identity holds several device keys; items are re-encrypted to each, so any authorized device decrypts them.
Total loss (every device and your VESkey gone) is the hard case. VESrecovery solves it with threshold secret sharing among recovery contacts you pick in advance. Your recovery secret is split into shares (scheme RDX1.2); each share is a vault item encrypted to one contact’s key. Recovery needs a threshold — n of m contacts — to actively help. Fewer than n shares reveal nothing. No single party — not the server, not any one contact — can recover your keys alone.

The honest tradeoff

We don’t hide the cost of social recovery. A coalition could in principle take a vault — but only if all of these hold at once:

a threshold of the contacts you chose collude;
they also seize your email (recovery is OTP-gated to it);
they sustain it through the entire Security Time Delay — you set it (typically 12–24h), during which the server withholds the recovered keys and you can stop the recovery; and
no honest friend warns you — because initiating recovery alerts every recovery contact, not just the colluding ones, and emails you.

That is a detection-and-response boundary, not an unconditional “yes.” And the right comparison isn’t “VES vs. perfect E2E” — it is “VES vs. the server-side encryption products fall back to because perfect E2E loses data.” Against that baseline, VES removes the provider’s ability to read your data while keeping a recovery path no single party controls. The full mechanism and threat model — including what the server can see (metadata) — are written up in VESrecovery (design & threat model), with the formal scheme in the RDX1.2 specification (PDF).

Post-quantum by default

New keys use ML-KEM (FIPS 203) by default — not opt-in. “Harvest now, decrypt later” means data exchanged with classical-only keys can be captured today and broken once quantum hardware arrives, so we would rather you have to opt out than remember to opt in. You can still build a classical-only library, and existing keys keep working — keys carry their own algorithm.

Try it

Open an App Vault in the shared demo domain, store an encrypted value, and read it back:

ves -a //demo/me@example.com/ -E -o note-1 -i "hello"   # encrypt + store
ves -a //demo/me@example.com/ -E -o note-1 -ip          # decrypt + print  ->  hello

The library and CLI are free and open source (Apache-2.0); recovery relies on the VESvault service, which is zero-knowledge and has a free tier. Code, docs, and the threat model are on GitHub. We welcome scrutiny of the design.