Zero-Knowledge Encryption Explained

Zero-knowledge is used in several ways. In a form product, it often describes a trust model where the service does not receive the private key needed to decrypt response contents. It is not automatically a mathematical zero-knowledge proof, and it does not mean the service sees no metadata.

Public and private keys

Your browser creates a public/private keypair. The public key lets a respondent encrypt a response; the private key is kept by the owner and protected in browser storage. In Cyphorm's intended application flow, the service does not receive that private key, so stored response data alone cannot be decrypted by the service.

This is the same fundamental principle behind technologies like PGP email and Signal messaging. The difference is that Cyphorm applies it to web forms, so any respondent can submit encrypted data to you without needing special software or a shared secret.

How this differs from encryption at rest

Encryption at rest protects stored files and disks. It does not by itself prevent a service's application from processing readable answers for features such as dashboards or exports. Client-side encryption sets a different goal: keep the response private key outside the form provider so stored response contents remain ciphertext.

Neither design describes every product. A vendor may offer multiple modes, each with different key and workflow properties. Read the current documentation for the exact feature you plan to use.

How Cyphorm implements this

When you create a Cyphorm account, your browser generates an RSA-OAEP keypair using the Web Crypto API. The public key is sent to the service so respondents can encrypt submissions. The private key is protected locally in account-scoped browser storage using a key derived from your password; it is not sent to the server through the intended flow.

When a respondent fills out your form, their browser:

1. Generates a fresh AES-GCM key for the response
2. Encrypts the form data with that AES key
3. Encrypts the AES key with your RSA public key
4. Sends both ciphertexts to our server

The server stores the encrypted payload, the RSA-wrapped AES key, the initialization vector, and operational metadata. Stored server-side response data alone cannot be decrypted. The application code delivered to the browser remains part of the trust boundary and could access plaintext if it were compromised or deliberately modified.

Backing up your key

Because the service cannot recreate your private key from stored responses, backups are essential. Cyphorm supports separately protected backup files and QR recovery sheets. Store them securely and test recovery before relying on them. If every copy is lost, encrypted responses cannot be decrypted by the owner or the service.