Glassbreak holds nothing it could decrypt.

The zero-knowledge contract

Three guarantees, each backed by an implementation detail you can audit in the codebase.

1. 1. Your passphrase never reaches our servers.

   In the browser, your passphrase is fed to scrypt (N=2^16, r=8, p=2) with a 16-byte random salt to derive a 256-bit AES key. That derived key unwraps your RSA + ML-KEM private keys locally. The passphrase is kept in JavaScript memory only, never serialised, and never sent over the wire — not at login, not at approval, not at decryption. Server-side password verification uses Argon2id (t=4, m=128 MB, p=2) with a salted hash. Two independent KDFs for two independent jobs.

2. 2. Two secret modes, one storage layer.

   Glassbreak stores secrets in two distinct modes — personal and team — and the database enforces the boundary, not policy:

   • Personal (T=1, N=1)— a single "share" that is the AES key itself, wrapped to the owner's RSA + ML-KEM keys. Used for individual credentials a single user holds. No Shamir math is invoked; only the owner can decrypt, by virtue of holding their own private keys.
   • Team (T-of-N, T >= 2, N >= T) — the AES key is split with Shamir's Secret Sharing over GF(2⁸). Recovery requires T independently approving members. Below the threshold the shares carry zero information about the key — a property of the polynomial, not a policy decision.

   A database CHECK constraint on the secrets table allows only those two combinations: (T=1, N=1) or (T>=2, N>=T). No in-between, no server-held extra share, no escrow, no per-secret service key. The team-secret quorum property follows from the storage shape, not from the application layer.

3. 3. Approval is a relay, not a decryption.

   The approve endpoint accepts only {encryptedShareForRequester, shareIndex}. No passphrase, no plaintext share, no key. The approver decrypts their share locally with their own keys, re-encrypts it to the requester's public keys (RSA-OAEP + ML-KEM hybrid), and the server forwards the ciphertext verbatim. The supplied shareIndexis validated against the approver's actual secret_shares.share_index row, so a malicious approver cannot lie about which point on the polynomial they are providing. A unique constraint on (request_id, share_index) stops two approvers from submitting the same index. Migration 008 permanently removed the tables and code paths that had ever held server-decryptable material.

Cryptographic primitives

Every primitive listed here is traceable to a specific file in the repository. No marketing nouns, no "military-grade" — just the algorithms we actually call.

Libraries we trust

We don't roll our own crypto. Every primitive above is implemented by a small set of vetted, narrow-scope libraries — chosen because they are auditable, pinned in our lockfile, and published by maintainers with a track record of disclosing and fixing issues openly.

Exact versions are pinned in each package-lock.json in the public repository. We do not auto-bump crypto dependencies — every change goes through a code review and a fresh Wycheproof run.

Post-quantum exposure

A sufficiently large quantum computer would break the classical public-key algorithms in widespread use today (RSA, Diffie-Hellman, ECDSA, EdDSA). It would not meaningfully weaken symmetric primitives like AES-256, HMAC, Argon2id, or scrypt. Our position is built around that distinction.

We treat "harvest now, decrypt later" as a real threat for anything an adversary could record off the wire today and retain. The table below is honest about what we protect against that threat and what we do not.

The single sentence: your content survives a quantum break; your session tokens have a finite harvest window. If you record a Glassbreak TLS session today and wait for a CRQC, what you decrypt is the envelope, not the message inside.

Where the keys live

Your browser holds your passphrase. The passphrase derives a key. The key unwraps your private keys. Your private keys unwrap your shares. Shamir recombines the shares into an AES key. The AES key decrypts the secret. Every arrow that crosses the network carries ciphertext only.

   BROWSER (you)                              SERVER (us)
   ─────────────                              ───────────
   passphrase                                 (never sees passphrase)
        │
        ▼ scrypt
   derived AES key
        │
        ▼ unwraps
   RSA + ML-KEM private keys ───┐
        │                       │
        ▼ encrypt new secret    │
   AES-256-GCM ciphertext       │
        │                       │
        ▼ Shamir split          │     ┌───────────────────┐
   shares[1..N]                 │     │ encrypted blob    │
        │                       │     │ encrypted shares  │  ─── store ──▶
        ▼ wrap each share       │     │   (per recipient) │
   RSA-OAEP + ML-KEM ────────── │ ──▶ │ audit metadata    │
                                │     └───────────────────┘
                                │
   ╔════════════════════════════════════════════════════════╗
   ║  APPROVAL FLOW — server-as-relay                       ║
   ╠════════════════════════════════════════════════════════╣
   ║                                                        ║
   ║  approver browser              server                  ║
   ║  ────────────────              ──────                  ║
   ║  unwrap own share                                      ║
   ║       │                                                ║
   ║       ▼ re-encrypt to                                  ║
   ║       requester's keys ────▶ store ciphertext verbatim ║
   ║                              validate shareIndex       ║
   ║                              against approver's row    ║
   ║                                                        ║
   ╚════════════════════════════════════════════════════════╝

   requester browser              server
   ─────────────────              ──────
   fetch shares       ◀────────── pure assembly:
   unwrap each                    encrypted blob
   Shamir combine                 + own share
   AES-GCM decrypt                + relayed shares
   plaintext secret               (no server decrypt)

What the server can and cannot see

Glassbreak protects secret material. Metadata is intentional — humans need to read audit logs and approval prompts. Here is the precise split, documented in ARCHITECTURE.md.

A compromised database read would expose who is requesting what — but not the secret value itself. We chose readable audit trails over an encrypted-reason mode that would block compliance review; that tradeoff is documented and revisitable.

Defence in depth

The cryptographic core is the last line of defence, not the only one. Layers above it:

• ›HttpOnly + Secure + SameSite=Strict cookies for the web access and refresh tokens. The refresh cookie is scoped to /api/auth/refresh only. The CSRF cookie is deliberately readable by JavaScript — that is the double-submit pattern, not a leak.
• ›Strict Content Security Policy served from both the Caddy origin and the Fastly edge. object-src 'none', frame-ancestors 'none', base-uri 'self', form-action 'self', upgrade-insecure-requests. HSTS preload at max-age=63072000 (two years).
• ›Per-IP and per-user rate limits backed by the same Postgres database that holds the rest of application state — counters live in the rate_limit_counters table per vertical. The in-memory backend hard-fails at startup outside development, so a misconfigured deployment cannot ship with effectively no limit. Trusted edge headers (fastly-client-ip, x-real-ip) take precedence over user-supplied X-Forwarded-For to stop spoofing.
• ›DNSSEC, SPF/DKIM/DMARC, CAA on every zone. DMARC p=reject with strict alignment. Mail-sending DKIM keys are intentionally empty for the apex zones (we don't send from them), with the empty record hardening against unauthorised key publication. CAA pins issuance to the providers each edge uses; the iodef contact is security@glassbreak.io.
• ›Audit log on every security-relevant action — failed logins, token issuance, share retrievals, decryption requests, approvals, impersonation, GDPR actions. Audit writes that fail are surfaced to the logger, not swallowed.
• ›Multi-cloud redundancy across two fully isolated stacks today — AWS (Lambda + Neon Postgres) and Scaleway (Functions + Scaleway Serverless SQL) — with a third (Fly.io / GCP) on the way. No shared compute, network, or control plane. A full outage of any one provider takes out one stack; the others continue serving.

Coordinated disclosure

What we don't claim

Security pages that only list strengths are not credible. Here is what Glassbreak is not, today.

• ·Not SOC 2 or ISO 27001 certified. We have not committed to an audit timeline yet — when we do, this page will say so.
• ·Not yet third-party penetration-tested. Internal threat modelling and code review feed every release; an external engagement is on the pre-launch checklist.
• ·We do not store backups of your encryption keys. If you lose your team's quorum, the data is unrecoverable — by design. There is no support process that can restore it because no such key material exists on our side.
• ·The web app currently stores JWTs in HttpOnly cookies; the previous localStorage fallback path is removed. CSRF middleware is mounted on every state-changing route.
• ·Metadata (secret names, request reasons, audit timestamps) is stored in plaintext on the server so audit and notification flows can name the resource a row refers to. A future encrypted-metadata mode is on the roadmap; we will not pretend it ships today.