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.
THE PROBLEM
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.
THE PRIMITIVE
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.
HOW IT WORKS
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
Key seed requested
When your application needs to encrypt a value, it sends a key ID to ZeroKMS. Just the ID. The plaintext never leaves your infrastructure, and a key ID is not key material.
03
Per-value key derived locally
ZeroKMS uses proxy symmetric re-encryption on the root key to produce a key seed for that ID and returns it. Your application combines the seed with a client key that never leaves your infrastructure, derives a unique data key, encrypts the value in its own memory, and discards the key. ZeroKMS never sees the plaintext, the client key, or the data key.
04
Identity enforced at read
On decryption, your application requests the seed again using the key ID stored with the ciphertext. ZeroKMS releases it only to a caller with a matching identity and keyset access, and only the client key can turn it into the data key. A stolen ciphertext is ciphertext forever without the right caller.
BENCHMARKS
The performance.
14x
Faster than AWS KMS
<1ms
Per-operation latency
9
Global regions
0
Keys stored at rest
GET STARTED
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.