Zero-Knowledge Forms: Who Holds the Keys?
Cyphorm uses client-side encryption so the form service does not receive the owner's private key through the intended application flow. This page explains the boundary—and the parts users still need to trust.
Explore Encrypted Forms See How Encryption WorksWhat “zero knowledge” means for a form
For Cyphorm, zero-knowledge describes a product trust model: response contents are encrypted in the browser to the form owner's public key, and the matching private key stays with the owner. The server can store and return ciphertext without being able to decrypt it from its stored data alone. This is not a claim that the service knows nothing at all: it handles account details, form configuration, and operational metadata.
It also does not remove trust in the web application. The service delivers the JavaScript that runs in the respondent's browser. If that code were compromised or deliberately modified, it could capture answers or keys before encryption. Devices, account access, browser extensions, and owner key management also remain part of the user's trust boundary.
How the browser and keys work together
- The owner's browser generates an RSA public/private keypair. The public key is used for encryption; the private key stays in account-scoped browser storage, protected locally.
- A respondent fills out a form. The browser encrypts the response using a fresh AES-GCM key and wraps that key with the form owner's RSA public key.
- The server receives the encrypted payload, wrapped AES key, IV, and ordinary service metadata. The answer values are not sent as plaintext in the normal submission flow.
- The owner unlocks the private key in their browser and decrypts responses locally.
The interactive demo on the homepage runs the real Cyphorm encryption function locally and does not save a sample response.
What is visible to the service?
| Data category | What the service handles |
|---|---|
| Response content | Encrypted payload and wrapped AES key. The service cannot decrypt stored data alone. |
| Form structure | Form schema, field labels, and configuration needed to render and validate forms. |
| Account and operations | Account information, timestamps, response counts, and other operational metadata where applicable. |
| Browser execution | The JavaScript delivered by the site performs encryption and decryption. Users must trust that code and their endpoint devices. |
Key recovery is part of the design
A service that does not have the private key cannot restore it from encrypted responses. Cyphorm provides separately protected backup files and QR recovery sheets for account owners. Keep the backup and its passphrase in secure locations, and test recovery before relying on the form for important data.
If all copies of the private key are lost, the corresponding responses remain encrypted and cannot be recovered by Cyphorm. A forgotten login password and a lost private-key backup are also different problems; review the key recovery tradeoff.
What this model does and does not address
| Scenario | Effect of client-side encryption |
|---|---|
| Someone obtains stored ciphertext only | They do not get readable answers from those stored fields without the private key. |
| The service receives a normal response submission | The intended flow sends ciphertext for answer values; service metadata and form schema remain visible. |
| Compromised application code or device | Encryption cannot prevent code running before encryption, malware, or an unlocked endpoint from accessing plaintext. |
| Owner loses every private-key copy | Existing responses cannot be decrypted. Provider-blind storage means the provider cannot restore them. |
Use cases to evaluate
- Law firm intake
- Healthcare intake and its separate compliance requirements
- Whistleblower and ethics reports
- Employee feedback and surveys
- Client intake workflows
For product details and current plan limits, see Features & Pricing.
Zero-knowledge forms FAQ
Can Cyphorm read my form submissions?
Cyphorm does not receive the owner's private key through the intended application flow. Stored response data alone is ciphertext and cannot be decrypted by the service. Users still need to trust the browser code served by the site.
What metadata can Cyphorm see?
The service handles account and form metadata, schema and field labels, ciphertext, and operational details such as timestamps and counters where applicable. Response answers are not available from stored ciphertext alone.
What if I lose my private key?
Restore it from a separately protected backup file or QR recovery sheet. If every copy is lost, the responses cannot be decrypted; Cyphorm cannot recreate the key from ciphertext.
Does zero-knowledge protect against changed browser code?
No. A compromised or deliberately modified application could capture plaintext or keys before encryption. Users still trust the browser code and their devices.