§ 00·0x00/STACK / ZEROKMS
14x faster key management.
Field-level encryption needs a unique key per value. AWS KMS breaks at this volume: the latency and cost at production scale make it impractical. ZeroKMS is 14x faster, built on proxy symmetric re-encryption (patent pending). Keys are derived on demand, never stored, with identity and policy baked into every key.
This is what makes "encrypt every field" deployable.
§ 01·0x01/THE PROBLEM / CLOUD KMS AT SCALE
Traditional key management falls short.
Cloud KMS services were designed for a world where you encrypted entire disks with a handful of keys. The economics and latency assume a few thousand operations per day, not a few thousand per second. Push field-level encryption through AWS KMS and you will hit two walls at once: the latency of a network round trip for every decrypt, and a bill that makes per-value encryption financially unviable.
Per-value encryption was always the right answer. The bottleneck was the key manager, not the math.
§ 02·0x02/THE UNLOCK / PROXY SYMMETRIC
Proxy symmetric re-encryption.
ZeroKMS is a new cryptographic primitive, not a faster version of an old one. The construction was designed specifically to make field-level encryption deployable at production scale.
→ 01
Keys derived on demand
No per-value key sits in a database table waiting to be stolen. Each key is derived cryptographically from a root key and a context, on the exact request that needs it, and discarded afterward.
→ 02
Identity baked into every key
The context used to derive a key includes the requesting user or service identity. A different identity produces a different key, which decrypts nothing. Policy lives in the key itself, not in a separate RBAC table.
→ 03
Proxy symmetric re-encryption
Patent-pending construction that lets ZeroKMS re-key ciphertext under a new identity without decrypting the plaintext in the middle. Migrations, rotations, and tenant moves happen over ciphertext.
→ 04
Nine global regions
Deployed in every region where we run CipherStash production infrastructure. Your keys live near your data, your latency budget stays single-digit milliseconds.
§ 03·0x03/HOW IT WORKS / REQUEST LIFECYCLE
Every encryption is a fresh key.
01
Root key issued
A keyset root key is provisioned in ZeroKMS. The root never leaves the key manager. You get back an opaque keyset identifier to reference in your application.
02
Context collected
When your application needs to encrypt a value, it sends the plaintext, the keyset identifier, and a context object (user id, workspace id, policy tag) to ZeroKMS.
03
Per-value key derived
ZeroKMS derives a unique key from the root and the context. The key is used to encrypt the value, the resulting ciphertext is returned, and the derived key is discarded.
04
Identity enforced at read
On decryption, ZeroKMS re-derives the same key only if the caller presents a matching identity. A stolen ciphertext is ciphertext forever without the right caller.
§ 04·0x04/BENCHMARKS / NUMBERS
The performance.
14x
Faster than AWS KMS
<1ms
Per-operation latency
9
Global regions
0
Keys stored at rest
§ 05·0x05/SHIP / BUILD
Cloud KMS was built for the wrong threat model.
If you are reaching for AWS KMS, Google Cloud KMS, or HashiCorp Vault to encrypt individual fields, you are about to hit the same latency and cost wall every team before you has hit. ZeroKMS was designed from scratch for the "encrypt every field" world that CipherStash makes possible.