What Zero-Knowledge Actually Means (And How to Spot When It's Just Marketing)

Zero-knowledge might be the most overused, least verified term in product security. Every secrets manager, every password vault, every "secure" backend puts it on their landing page. Very few explain what it actually means in their architecture.

If you're about to trust a provider with your API keys, production tokens, or database credentials, it's worth understanding what the label actually requires before you buy it.

What "zero-knowledge" means in a real system

In applied cryptography (not the academic zero-knowledge proof sense), zero-knowledge means something specific: the provider cannot read your data even if it wants to — even if it gets breached, even if it receives a badly-executed legal request, even if a malicious employee has root access to the database.

That's only true if three conditions hold simultaneously:

Encryption happens on the client, before the data ever leaves the device or the developer's environment.
The server never sees the decryption key — only ciphertext and minimal operational metadata.
Decryption is only possible with a private key that never leaves the authorized device, not even in transit to the server.

Miss any one of these and it's not zero-knowledge. It's "encryption in transit and at rest" — which is fine, it's the standard baseline, but it's a much less demanding category.

The questions that separate the real thing from marketing

1. Who generates and holds the keys?

Ask directly: are private keys ever generated on the server? Are they ever transmitted unencrypted at any step, even "just during registration"? If the answer is yes to either, the provider can technically read your secrets, whatever they claim.

2. What happens if the server is compromised?

An attacker with full database access to a genuinely zero-knowledge system only gets ciphertext. Without the private keys of authorized devices, that ciphertext is useless. Ask the provider to walk you through that scenario in technical detail, not in a tagline.

3. How does it verify the client asking for the secret is legitimate?

End-to-end encryption protects data in transit and at rest, but it does nothing against a fake client impersonating a legitimate app. This is where device attestation comes in: cryptographically verifying, against real hardware (Apple App Attest, Google Play Integrity), that the thing requesting the secret is the authentic app running on an untampered device — not an emulator, not a patched binary.

4. What cryptographic properties does it actually have?

"End-to-end encryption" isn't one thing. There's a big difference between:

Envelope encryption with X25519 + AES-256-GCM (public-key crypto to transport a symmetric key, then AES-GCM for the payload).
A forward-secrecy protocol like Signal's, where every message uses fresh key material and compromising one key doesn't compromise history.

Both are legitimate, but they solve different problems. A secrets manager doesn't need the properties of an ephemeral messaging protocol; it needs the secret encrypted at rest and decryptable only by whoever is authorized at that moment. If a secrets provider throws around "Signal-grade" language without an actual ratchet, they're selling more than they have.

How Koove does it (and where the limits are)

Koove uses envelope encryption with X25519 for key exchange and AES-256-GCM for content, with HKDF-SHA256 for key derivation. The primitives are open source (@koove/crypto), so there's no black box — you can audit exactly what encryptSecret, sealKey, or computeAttestationBinding do.

# The developer (or their AI assistant) stores the secret once
koove set STRIPE_SECRET_KEY sk_live_xxx --env prod

# Code only ever references the name, never the value
koove list --env prod

On mobile, the secret only decrypts after biometric verification and device attestation:

import { KooveClient } from '@koove/sdk';

const client = new KooveClient({ apiUrl, appId, appToken });
await client.init(); // attestation + device registration

// decryptSecret only runs after biometric authentication
const value = await client.decryptSecret(envelope);

Attestation is verified end-to-end against real physical hardware on both iPhone and Pixel — no dev bypass, no accepted emulators. Koove's server only stores ciphertext: without the authorized device's private key, that data means nothing.

Now the limits, stated plainly:

There's no forward secrecy. We don't run a Signal-style ratchet. If a device's private key is compromised, an attacker holding that key can decrypt the secrets that device had access to. For this use case — application secrets management, not messaging — that's the right threat model, but it is not the same guarantee as real forward secrecy.
We don't hold SOC 2 or ISO 27001 certifications right now. A zero-knowledge architecture doesn't depend on an audit badge, but if your company needs that paperwork for compliance, we don't have it today.
You can review the full architecture and trust model at /security.

A quick checklist before you believe any "zero-knowledge" claim

Are private keys always generated and kept on the client, with no exceptions?
Can the provider describe, in technical detail, exactly what an attacker gets if the database is breached?
How does it verify the client requesting a secret is legitimate (attestation, not just a token)?
What cryptographic primitives does it use, exactly, and are they auditable?
What does the system explicitly NOT guarantee? (If nobody tells you, ask.)

Full CLI and SDK documentation lives at /docs/sdk, and answers to the most common questions about our threat model are in /faq.

Why this matters more in the AI-generated code era

AI assistants write code fast, and that code often includes a hardcoded key because that's the path of least resistance. A genuinely zero-knowledge system, where the secret never touches the repo from the first commit, is one of the few defenses that doesn't depend on the developer (or their copilot) remembering to do it right. We go deeper on this in /ai-security.

If you want to try it on your own projects, you can sign up at /register and check the available plans at /plans.