The Zero-Knowledge Architecture
We built VerifID so we structurally cannot read your data
Not a policy promise, not a pinky swear in a privacy policy — a mathematical guarantee. Here is exactly how the encryption pipeline works, from key generation to decryption.
Three zones. Only one of them ever sees plaintext.
Zone 1
Respondent's browser
Plaintext exists here, briefly, while someone types. It is encrypted with AES-256 before the form even calls our API.
Sees plaintext: yes (transiently, locally)
Zone 2
Network in transit
TLS wraps an already-encrypted payload. Even a successful TLS interception yields ciphertext inside ciphertext.
Sees plaintext: no
Zone 3
VerifID servers
Stores the encrypted blob and encrypted data key. Never receives, generates, or stores the private key needed to open them.
Sees plaintext: never
The key lifecycle, step by step
Every stage from form creation to viewing a decrypted response.
Key pair generated in your browser
The moment you create a form, your browser generates a fresh RSA-3072 key pair using the Web Crypto API. The private key is written to your download/clipboard — it is never sent anywhere.
Public key published with the form
Only the public key travels to our servers, embedded in the published form. A public key can encrypt data but cannot decrypt it — this is the entire trick.
Respondent submits — encryption happens before transmission
When someone fills out the form, their browser generates a one-time AES-256 data key, encrypts the response with it, then encrypts that data key with your RSA-3072 public key. Ciphertext leaves the browser; plaintext never does.
Server stores ciphertext it cannot read
Our database receives an encrypted blob and an encrypted data key. There is no code path in our infrastructure that holds the private key needed to open either.
You decrypt locally with your private key
When you view submissions, your browser downloads the ciphertext and asks you for the private key you saved in step 1. Decryption happens on your machine, not ours.
Plaintext exists only where you choose to see it
The decrypted response is rendered in your browser session and discarded when you navigate away — it was never persisted anywhere in readable form outside your own device.
Who can see what
The honest answer for every realistic threat scenario.
| Scenario | What they actually get |
|---|---|
| Network eavesdropper (public Wi-Fi, ISP) | TLS-wrapped ciphertext — same as everyone else on the wire. |
| Database breach / stolen backup | Encrypted blobs and encrypted data keys. No private keys are stored anywhere on our infrastructure to unlock them. |
| Malicious or compromised VerifID employee | The same ciphertext as an external attacker — there is no internal decryption tool or master key. |
| Legal order compelling data disclosure | We can only hand over what we hold: unreadable ciphertext. We cannot produce plaintext we never had. |
| Lost or stolen respondent device (post-submission) | Nothing extra — the response was already encrypted before it left that device. |
The technical specifics
RSA-3072
Asymmetric encryption
AES-256-GCM
Symmetric encryption
Client-side, Web Crypto API
Key generation
Zero — ciphertext only
Server-side visibility
Want the compliance-specific breakdown instead? See DPDP, HIPAA, GDPR & PDPA coverage.
See it hold up on your own data
Create a form, save the private key, and try to imagine how we'd ever hand your data to anyone.