On this page
Client-side encryption means data is encrypted on the user's own device, before it is sent anywhere, with keys that the receiving server never gets.
What it changes
With server-side encryption, a service encrypts data after it arrives and decrypts it whenever asked. A breach of the server, a careless backup or a malicious insider can expose plaintext. With client-side encryption, the server only ever holds ciphertext, and a full copy of its database is useless without keys that live elsewhere.
Where the trust moves
The weak point becomes the code running on the client. A desktop binary can be verified once when you install it. A web app is sent by the server on every visit, so a compromised server could serve a modified page that captures a password as it is typed. Careful client-side designs answer this with:
- signed releases that clients verify before trusting new code;
- a strict content security policy that blocks third-party scripts;
- reproducible builds, so anyone can rebuild a release and compare the bytes;
- a way to run the client from a local copy instead of loading it from the server.
How Crunu does it
Crunu encrypts only in the browser and in the crunu agent. The browser uses WebCrypto, which requires Chrome 113 or later, Safari 17 or later, or Firefox 129 or later. The agent is written in Go. Both implement the same primitives (AES-256-GCM, X25519, Ed25519 and HKDF-SHA256) and are checked against shared test vectors.
For the web-client risk, Crunu:
- signs releases of the agent and the web client with Ed25519;
- builds the web client reproducibly, so the same commit gives the same bytes;
- serves it with a content security policy and Subresource Integrity checksums;
- offers the same client as a single local file,
crunu.html, that loads its code from disk and checks the site against the signed release. It is the recommended way for administrators to work.
The agent's installer and crunu self-update verify signatures and checksums too.
Limits
These measures reduce the risk; they do not remove it. A tampered web client remains the main residual risk of any browser-based vault, and malware on the device itself is out of reach of any encryption scheme. Values hidden in the interface are a client-side safeguard against accidents, not against someone who already holds the key. See how encryption works and the limitations page.
From the blog
Security
Why a vault vendor can’t reset your password
With a password and a Secret Key, nobody at the vendor can open your account, or reset it. How the Emergency Kit works, and what to do when something is lost.
Security
What “the server can’t read it” actually means
A blind server is a precise claim with precise limits. What Crunu's server stores, what it cannot do even if compromised, and what it still sees.
Teams
An offboarding checklist for engineering teams
Removing an account takes seconds. Secrets outlive it. A practical checklist for engineering offboarding, from sessions and tokens to reissuing values.