Zero-knowledge architecture

Note

Heads up

Terminology: in product copy, zero-knowledge means answers are sealed in the respondent's browser and stored as ciphertext, with nothing that links an answer to its author. It is not a claim about formal ZK proof systems in academic cryptography.

Our goal is simple to state: we can't read answers, and we can't tell who wrote one. This page maps that goal to behaviour a security reviewer can check; where it still rests on trusting us, most of all the code we serve to your browser, the threat model says so; for the seal path and crypto parameters, start with Encryption model overview.

#Poll and response path

Concept	Behaviour
Poll keys	Generated in the admin's browser when the poll is created
Server holds for each poll	The public key and the private key wrapped under a folder key
Respondent path	Answers sealed in the browser before they're sent
Response rows	The poll and the ciphertext. No time, order or identity.
Admin decrypt	In the admin's browser, after results unlock
Recovery	A password-protected recovery file, or inbox recovery that returns ciphertext only your password or recovery key opens

Good to know

What this buys you

A database dump, a compromised operator account, or a production snapshot holds answer ciphertext, not answer text, and nothing that says who wrote which answer.

#Key backup and inbox recovery

Your key backup is locked in your browser before it reaches us, with your password or your recovery key. Nothing we store can open it. Your recovery key never reaches us at all.

Inbox recovery stores your keys as ciphertext your browser made under your password or recovery key. We hold that ciphertext and can't open it; verifying your inbox releases it, and you still type your password or recovery key. An account with no password has to save a personal recovery key before it can use the admin app.

If someone loses both, an owner can restore a colleague's access only after confirming a code with them directly; we can't do it for them. The owner's browser re-wraps exactly what that person had before, never more.

#Shared folders and collaboration

Concept	Role
Poll → folder	The folder key wraps the poll's private key
Folder → people	One wrap of the folder key per person with access
Folder → workspace	Also wrapped under the workspace master key, so owners keep access
Unwrap location	The browser (folder → poll → answers)

Unwrap the folder key. Each collaborator unwraps their own wrap of the folder key with key material in their browser.

Unwrap the poll private key. The folder key unlocks the poll's wrapped private key.

Decrypt released answers. Released ciphertext loads into the admin app and is decrypted there. Nothing shows below the larger of three and the poll's minimum group size. While the poll is open, answers arrive in random groups of three to five with a few always held in reserve, and at close everything shows.

unwrap-folder-poll.tsILLUSTRATIVE

const folderKey = await unwrapFolderKey(localAdminKey, folderWrap);
const pollPrivate = await unwrapPollKey(folderKey, pollWrap);
const answers = await decryptReleased(pollPrivate, releasedBlobs);

Warning

Before you promise linkage

Don't promise identity linkage the design can't support. Access codes are hashed and marked used when the answer is stored, but no record says which answer used which code. Personal invites use blind-signed ballots, so the ballot we see come back can't be matched to the link that issued it. See Access codes and anonymity.

Pair these with Aggregate results and anti-inference, Batched release and the exit pool and Respondent anonymity and zero telemetry. Residual threats and honest limits live in the threat model.

Note

Next

Read Encryption model overview for the seal sequence and parameters, or Post-quantum cryptography for the algorithms.

#Poll and response path

#Key backup and inbox recovery

#Shared folders and collaboration

#Related anonymity controls

#Related