Security model
Architecture, guarantees and assumptions. For the formal proofs and exact bounds, this page refers to the source document.
In brief
Kintaya splits a secret into shares distributed to people you trust: the secret is only reconstructed once a chosen quorum of those shares is gathered. Every cryptographic operation happens in the browser; no secret, no share, no key reaches Kintaya's servers. This is the founding invariant.
The reconstruction core is Shamir secret sharing over the finite field GF(256). For small secrets, it provides unconditional security. Larger secrets are encrypted with AES-256-GCM, Shamir then only covering the 32-byte key: computational security, resistant to quantum computers.
Two traits are worth naming upfront: the reconstruction path contains no asymmetric cryptography, and one criterion governs the whole, the apocalypse test - the secret must stay reconstructible even if Kintaya no longer exists.
Threat model
The defended invariant is narrow and absolute: no secret, no share at or above the threshold, no AES key ever leaves the browser in a form readable by Kintaya.
The main threat is not breaking the cryptography, but running hostile code on the legitimate origin: code served from kintaya.eu that would read the secret before encryption would make every downstream primitive moot. The identity, build and deployment chain is therefore part of the security perimeter.
The assumed adversary is a realistic remote attacker: phishing, real-time phishing, token theft, supply-chain compromise. The device and browser are assumed sound; client-side code injection remains the true residual risk.
The zero-knowledge invariant
This invariant is enforced by the code in several layers: a continuous-integration guard that blocks any leak, a runtime guard that bounds network egress, and a strict content security policy.