Zero-knowledge encryption, explained for investigators

“Encrypted” is on almost every software vendor’s website, and it can mean very different things. For a private investigator deciding where to keep case files, surveillance video and client communications, the difference that matters most is simple: who holds the keys?

This guide explains the common kinds of encryption in plain terms, what “zero-knowledge” means (and what it doesn’t), and the questions to ask any vendor, including us. It’s written to be accurate rather than persuasive. Zero-knowledge designs have real trade-offs, and you should know them before choosing one.

The three places data can be encrypted

In transit. Data is encrypted while traveling between your device and the vendor’s servers, usually with TLS (the padlock in your browser). Almost every reputable service does this. It stops someone on the same Wi-Fi network from reading your traffic. It does nothing once the data arrives.

At rest. Data is encrypted while stored on the vendor’s disks, typically with AES-256. This protects against someone walking off with a physical disk. But the vendor holds the keys, and its application decrypts your data whenever it needs to: to show it to you, to index it for search, to generate a preview, to run a support tool. Anyone with sufficient access to the vendor’s systems can, in principle, read it.

On your device (client-side, end-to-end or zero-knowledge). Data is encrypted on your own device before it’s uploaded, with keys the vendor never receives. The vendor stores ciphertext it can’t read. Only people who hold the keys (you, and anyone you deliberately share with) can decrypt it.

Most business software, including most case-management tools, uses the first two. That’s a competent, standard design, not a failing. But it’s a different promise from the third. “Encrypted in transit and at rest” means outsiders can’t read your files. It doesn’t mean the vendor can’t.

What “zero-knowledge” means

In the software market, “zero-knowledge” is used to mean that the provider has no knowledge of your data’s contents because it never has the keys. (The term is borrowed loosely from cryptography’s “zero-knowledge proofs,” which are a different thing.) You’ll also see “end-to-end encrypted” and “client-side encrypted” used for similar designs.

In practice, a zero-knowledge service works roughly like this:

1. When you set up your account, keys are created on your device. Typically a key is derived from your password, which then protects other keys.
2. Before any file, note or message leaves your device, it’s encrypted with those keys.
3. The server stores and returns ciphertext. It can’t decrypt it because it never receives the keys or your password in usable form.
4. When you share with a client, the data (or a key to it) is encrypted for that client, so only they can open it.

The consequence that matters for you: if the vendor is breached, subpoenaed, sold or simply curious, what it can hand over is ciphertext plus whatever metadata it has, not the contents of your case files.

Why this matters for PIs in particular

Your files hold exactly the kind of information people go to lengths to obtain, and your clients, attorneys especially, have their own confidentiality duties and will ask how you protect what they share. When an attorney asks how you store and deliver investigative work product, “our vendor encrypts it” is a weaker answer than “our vendor can’t read it.”

It also matters when you compare vendors’ own terms. Some case-management vendors’ privacy policies explicitly allow their staff to access customer data “as reasonably necessary” for support and maintenance. That’s normal for server-held-key systems, and often done responsibly. It’s still worth knowing which kind of promise you’re relying on.

What zero-knowledge does not protect

This is the part vendors tend to skip.

Metadata. The server still has to know some things to work: your account email, when you log in and from which IP address, how many files you have, their sizes, when they were uploaded, and billing details. A good vendor minimizes this and documents exactly what it can see. None can make it zero.

Your device. Encryption protects data on the server. If your laptop has malware, or someone has your unlocked phone, they see what you see.

Your password. If a key is derived from your password, a weak password is the weak point. Well-designed systems slow down guessing with deliberately expensive key-derivation functions, but a long, unique password still matters. NIST’s current guidance (SP 800-63B-4) favors long passwords over complexity rules. Add two-factor authentication.

What you share. Once a client decrypts a report and downloads it, it’s on their device, outside anyone’s encryption.

The code you’re trusted to run. In a web app, your browser downloads the application code from the vendor each time. A malicious or compromised update could, in principle, capture keys before encryption. This is a known limitation of browser-based end-to-end encryption. It’s reduced by careful engineering, security reviews and transparency about how the code is built and delivered, but it’s why “the vendor can’t read your data” means “the design doesn’t give the vendor your keys,” not “it’s impossible for anything to go wrong.”

The trade-offs you’ll notice

Password reset works differently. If the vendor can reset your password and restore access to your data, it has a path to your keys, which means it isn’t zero-knowledge. In a true zero-knowledge service, forgetting your password without a recovery key can mean losing access to your data. Expect to be given a recovery key and asked to store it safely.

Support can’t see your data. Support staff can help with your account, but can’t open a case file to see what’s wrong. You may need to describe problems or share screenshots yourself.

Some features are harder. Server-side full-text search, automatic previews and AI summarization all normally need the server to read content. Zero-knowledge products either do this work on your device, use privacy-preserving techniques with narrower capabilities, or leave the feature out.

For most PIs these trade-offs are worth it. But they’re real, and a vendor that doesn’t mention them isn’t telling you the whole story.

How it compares with tools you may already use

• Consumer cloud storage (Google Drive, Dropbox, OneDrive) uses provider-held keys by default. Google does offer client-side encryption for Workspace, but only on certain higher-tier Workspace editions, and it has to be set up by an administrator.
• Signal uses a well-regarded end-to-end encryption protocol for messages. It’s excellent for messaging, but it isn’t a case file: no evidence records, no reports, no client portal.
• WhatsApp messages are end-to-end encrypted, but chat backups are only end-to-end encrypted if the user turns that option on.

Questions to ask any vendor

1. Where are my case files encrypted: on my device, or on your servers?
2. Who holds the keys? Can any of your staff, under any procedure, decrypt my data?
3. If I forget my password, how do I get my data back, and what does that tell me about who has access?
4. Exactly what metadata can you see? Is it documented?
5. If you receive a subpoena for my data, what can you actually produce?
6. Do you send any of my content to third parties (AI services, transcription, analytics)?
7. Has the design been independently reviewed? If not, is it documented well enough for someone to check?

If a vendor answers the first question with “we use bank-level encryption,” ask the question again.

For the wider checklist of what to compare between products, see our buyer’s guide to PI case-management software. For the parts of security that no vendor can handle for you, see data security for private investigators and password managers and 2FA for investigators.

Spotted an error? Tell us by email and we'll correct it.