Skip to main content
Back to Blog
securityencryptiontechnical

Understanding Zero-Knowledge Encryption

CloudKeep Team· SecurityFebruary 5, 20266 min read

What Is Zero-Knowledge Encryption?

Zero-knowledge encryption means the service provider — CloudKeep, in this case — never has access to your unencrypted data. Your secrets are encrypted and decrypted entirely on your device. The server stores only ciphertext that is computationally indistinguishable from random noise.

This is fundamentally different from "encryption at rest" that most cloud services advertise. With encryption at rest, the provider holds the decryption key. With zero-knowledge, only you hold the key.

How CloudKeep Implements It

CloudKeep uses a multi-layer key hierarchy to keep your data safe while still enabling features like sharing and team vaults.

Step 1 — Key Derivation

When you set your master password, we derive a 256-bit encryption key on your device:

masterKey = PBKDF2-SHA256(
  password    = masterPassword,
  salt        = userSalt,         // unique per account
  iterations  = 600_000,
  keyLength   = 32 bytes
)

The raw master password is never sent to the server. We send only an authentication hash derived from a separate HKDF-expand step so the server can verify your identity without learning your encryption key.

Step 2 — Vault Key Encryption

Each vault has its own randomly generated vault key. This vault key is encrypted with your master key using NaCl secretbox (XSalsa20-Poly1305):

encryptedVaultKey = nacl.secretbox(
  message = vaultKey,
  nonce   = random(24 bytes),
  key     = masterKey
)

Step 3 — Secret Encryption

Individual secrets are encrypted with the vault key, again using NaCl secretbox:

encryptedSecret = nacl.secretbox(
  message = JSON.stringify(secretFields),
  nonce   = random(24 bytes),
  key     = vaultKey
)

This layered approach means that sharing a vault only requires re-encrypting the vault key for each recipient — the secrets themselves do not need to be re-encrypted.

Why It Matters

| Scenario | Traditional Manager | CloudKeep (Zero-Knowledge) | |----------|--------------------|-----------------------------| | Server breach | Attacker gets your encrypted data and the decryption key | Attacker gets ciphertext with no usable key | | Insider threat | Employees with server access can read secrets | No one at CloudKeep can decrypt your data | | Legal subpoena | Provider can be compelled to hand over readable data | Provider can only hand over indecipherable ciphertext | | Compromised backup | Backups contain keys alongside data | Backups contain only ciphertext |

The Tradeoff

Zero-knowledge encryption shifts responsibility to you. If you lose your master password and your recovery key, your data is unrecoverable. We cannot reset it for you because we never had access to begin with.

That is why CloudKeep generates a recovery key during onboarding. Store it somewhere safe — a physical safe, a safety deposit box, or a trusted family member. It is your last line of defense.

In Practice

For most developers, the experience is seamless. You set a strong master password once, and CloudKeep handles the rest. The CLI caches your derived key in your OS keychain for the duration of a session, so you are not re-entering your password every time you pull a secret.

# Authenticate once
cloudkeep auth login

# Use secrets without re-entering your password
cloudkeep get production/STRIPE_SECRET_KEY
cloudkeep inject --vault staging -- docker compose up

Zero-knowledge is not just a marketing checkbox for us. It is the foundation everything else is built on.

All posts