Client-Side Quorum Cryptography in the Browser
Glassbreak Team · Published 2026-07-17
Client-side quorum cryptography means a browser, not a server, does every operation that touches a plaintext key — including the moment several people combine their shares to recover a shared secret — so the platform coordinating the process never holds anything it could decrypt itself, even if it wanted to or were compelled to. This is a stronger guarantee than "we encrypt your data," because it removes the server from the trust boundary entirely rather than asking you to trust how well the server protects a key it does hold.
The problem with server-side secret sharing
A naive implementation of quorum-based recovery does the math on the server: shares arrive, the server combines them, reconstructs the secret, and hands it back. This works functionally, but it means the server holds the plaintext secret at the moment of reconstruction — briefly, but completely. Anyone who compromises that server, subpoenas its operator, or exploits a bug in that reconstruction code gets the same access a legitimate quorum would have gotten, without needing to convince any of the actual approvers. The quorum requirement becomes a policy the server enforces rather than a mathematical property the requester's browser verifies for itself.
Doing the math where the server can't see it
The alternative is to keep every decrypt and every reconstruction operation client-side, in the requester's and approvers' browsers, and give the server exactly one job: relay already-encrypted material between them.
Splitting. When a team secret is created, the browser generates an AES-256 key for the secret itself, encrypts the secret with it (AES-256-GCM, random IV per encryption), and then splits that AES key using Shamir's Secret Sharing — not the secret's plaintext, the key that unlocks it. Each of the N shares is wrapped to one team member's public keys before it ever leaves the browser.
Requesting. When someone needs the secret, they trigger a request. The server's role here is coordination only: it knows a request exists and who the eligible approvers are, not any cryptographic material.
Approving. Each approver decrypts their own share locally, using their own private keys — keys that never leave their device — then re-encrypts that share directly to the requester's public keys. What reaches the server is ciphertext addressed to the requester, meaningless to anyone else, including the server itself.
Reconstructing. Once the requester's browser has collected T re-encrypted shares (the threshold set when the secret was created), it decrypts each one locally and runs Shamir reconstruction client-side. Below the threshold, the shares the server has relayed carry zero information about the secret — not weak information, none — so a server compromise or a single coerced approver can't produce anything usable on its own.
Two independent keys for two independent jobs
This design also separates the key that authenticates you from the key that protects your data, which is easy to conflate. Your login passphrase is fed through scrypt in the browser to derive a key that unwraps your private keys locally — it's never sent over the wire, at login or at any later step. A completely separate derivation, Argon2id, runs server-side purely to verify you know your password, and that hash can't be used to derive your encryption keys even if it were exposed. The share re-encryption step itself uses a hybrid of RSA-OAEP-4096 and ML-KEM-1024, so a share surviving both a classical break of one primitive and a future quantum break of the other is a design goal, not an accident. The complete primitive list — algorithms, key sizes, and where each one runs — is on the security page.
What this buys a team evaluating break-glass tools
The practical test for any vendor claiming zero-knowledge or end-to-end encrypted quorum recovery is simple: ask exactly what the approval endpoint's request body contains. If the answer is anything resembling a plaintext share, a passphrase, or a reconstructable key, the server is a participant in decryption, not a relay — and every guarantee downstream of "the server can't read your data" depends on trusting how well that server is operated, not on math. For the broader mechanics of why a threshold, rather than a single approver, is the right shape for emergency access in the first place, see what is quorum-based (Shamir) secret sharing. Teams ready to see this running against a real team secret can start for free with a single team before deciding on a wider rollout.
Frequently asked questions
- If the server never sees a plaintext share, how does it know an approval is legitimate?
- It validates structure, not content. The server checks that the submitted shareIndex matches a row it already has on record for that approver, and enforces a unique constraint so two approvers can't submit the same index — but the actual cryptographic payload (the re-encrypted share) passes through unread. Legitimacy comes from the requester being able to successfully reconstruct the secret with the shares they receive, not from the server vouching for any single approval.
- What stops a malicious approver from sending garbage instead of a real share?
- Reconstruction below the threshold reveals nothing, and reconstruction with a corrupted share at or above the threshold simply fails to produce the correct secret — Shamir's Secret Sharing doesn't silently accept bad input, it fails to interpolate the original polynomial correctly. A requester who suspects a bad approval can request a fresh share from another approver, since redundancy above the threshold (N greater than T) is exactly what tolerates one participant acting in bad faith or making a mistake.
- Why split the secret with Shamir's Secret Sharing instead of just encrypting it to multiple people's public keys separately?
- Encrypting the same secret separately to multiple public keys means any one of those people can decrypt it alone — that's an OR condition, not a quorum. Shamir's Secret Sharing produces an AND-of-a-threshold condition instead: no subset smaller than T can do anything with what they have, which is the actual property a quorum-based break-glass design needs.