Security
Designed for systems where trust cannot sit in one place.
Anastasis assumes providers can fail, be breached, or be curious. The architecture is built so that those assumptions do not translate into the loss or disclosure of a protected secret.
Architecture
Where the material lives.
Separation of roles
The party that authenticates a user is not the party that can reconstruct a secret. No role in the system is both gatekeeper and custodian.
Insufficiency by construction
Material held by any single provider is designed to be insufficient to recover the protected secret on its own.
Client-side reconstruction
Reconstruction happens on the user's device. There is no server-side moment at which the whole secret exists.
Explicit policies
What it takes to recover is written down as a policy, not implied by an operator's internal procedures.
Threat model
What the design is intended to withstand.
These are design goals, stated as goals. Whether a specific deployment meets them depends on provider independence, policy configuration and operational practice.
| Scenario | Anastasis design goal |
|---|---|
| User device lost or destroyed | Recovery remains possible through the configured policy, without the original device. |
| A single provider is compromised | The protected secret should remain protected; one provider's material is designed to be insufficient on its own. |
| A provider database is leaked | Stored material should not reveal the original secret to whoever obtains the dump. |
| A provider becomes unavailable or ceases operation | Alternative recovery policies may remain usable, provided the policy was configured with redundancy. |
| The user forgets a password | Recovery need not depend solely on a memorised secret; other authentication methods can be part of the policy. |
| A provider tries to profile its users | The protocol is designed to limit what a provider learns about the user and about the wider recovery policy. |
Long-term confidentiality
On post-quantum threats.
Recovery material may sit with a provider for years. That makes long-term confidentiality a real design concern rather than a marketing line: material captured today should not become readable to an adversary with future capabilities.
The cryptographic architecture is designed with long-term confidentiality and post-quantum threats in mind.
We do not claim certification, quantum-proof security or guaranteed quantum resistance. The cryptographic design is documented so that reviewers can judge the specific constructions and their assumptions for themselves.
Read the cryptographic designDeployment considerations
Where the remaining risk actually is.
The cryptography is the part we can reason about in the abstract. These are the decisions that determine what a deployment is really worth.
Provider independence
Providers operated by one organisation, on one platform, in one jurisdiction, are not independent in the sense the design assumes.
Authentication strength
A recovery policy is only as strong as the weakest authentication step it accepts.
Operational rehearsal
Recovery paths that are never exercised tend to fail exactly when they are needed.
Bring your threat model, and we will work through it.
Security architects evaluating Anastasis get direct access to the people who designed the protocol.