For geeks
Updated
This is the wire-level writeup for security teams, DevSecOps, and anyone who will not take "end-to-end" as a slogan. It describes the primitives, the key hierarchy, the envelope formats, and the exact hop where a ciphertext becomes plaintext.
The operator guide stays on Encryption. That page is how you enroll a vault and rotate a key. This section is how the bytes move.
Kryptic is a blind store. Secret values are encrypted on a client (browser, daemon, CI runner, or cluster operator) under a 256-bit organization key that exists in plaintext only on clients. The four API hosts store and serve ciphertext they have no function to open. Anything that can see a secret in plaintext is open source.
We do not use the phrase "zero-knowledge". The design is end-to-end encryption with a client-held org key. An independent cryptographic review has not been published yet. Read the engines and the interop vectors instead of a label.
The map
Click a node. Clients on the top row can hold plaintext. The blind store on the bottom row cannot.
System map
Who talks to whom
Click a node
What the server actually holds
Management API, Daemon BFF, Pipelines BFF, and Secrets API all store or serve the same wire objects: secret envelopes, sealed-box grants, public keys, wrapped private keys, and Argon2id hashes. None of those hosts has a function that opens a secret value.
A separate server-side org data key wraps operational ciphertexts the platform itself must read (SSO IdP client secrets). It is not on the path that encrypts customer secret values.
Org key, party private keys, passphrases, secret plaintext
TLS 1.3 in; local socket never crosses this boundary
Transport between a client and an API host is TLS 1.3. The only path that carries plaintext off a crypto client is the local OS socket from daemon to SDK, which never leaves the machine and is gated by kernel peer credentials (or a Windows named-pipe ACL).
What this section covers
Key hierarchy
Passphrase, device key, machine secret, recovery code, party P-256, org key, and what the server data key is for.
Envelopes
v1 secret envelopes, sbx.v1 sealed boxes, associated data, Argon2id wraps, and the interop contract.
Decrypt paths
Dashboard reveal, daemon injection, and CI or Kubernetes: when plaintext appears, and what never decrypts.
What the server can see
| Visible to the platform | Invisible to the platform |
|---|---|
| Envelope metadata (version, key id, nonce, ciphertext length) | Secret values |
Secret names (DATABASE_URL) | The org key |
| Project, catalog, and environment structure | Party private keys |
| Grant recipients and public keys | Vault passphrases and recovery codes |
| Wrapped private keys and Argon2id hashes it cannot open | Machine client secrets (hash only) |
| Audit metadata (who fetched which key name, never the value) | Any server-side decrypt path for values (it does not exist) |
Losing MASTER_KEY on a self-hosted install breaks operational ciphertexts
(SSO IdP secrets and similar). It does not decrypt customer secret values and
it does not stop clients that already hold the org key.
Read the engines
The same bytes are implemented three times. A format change must land in all
three repositories in the same release. interop-vectors/ is the contract.
| Repository | Runtime | Who uses it |
|---|---|---|
| Kryptic.Encryption.Net | .NET AesGcm / ECDH | Platform operational ciphertexts only |
| Kryptic.Encryption.NPM | WebCrypto + hash-wasm | Management dashboard |
| Kryptic.Encryption.Go | crypto/ecdh + x/crypto | Daemon, kryptic ci export, Kubernetes operator |
No custom primitives. Each engine ships a SECURITY.md that matches this
section. Language SDKs never decrypt.