End-to-End Encryption
End-to-end encryption in Dossira
Dossira is built for confidential work: we share files, comments, and decisions in one place, while keeping access controlled.
Most workspaces use strong encryption at rest and in transit. For some matters, we need a stronger boundary: the service provider must not be able to read the content.
That is what end-to-end encryption provides.
In Dossira, end-to-end encrypted rooms are called Confidential Workspaces. Encryption happens on our devices. Only workspace members can decrypt the content. Dossira can store and deliver encrypted data, but cannot read it because we do not hold the workspace keys.
For most teams there are no “crypto passwords” to remember. We use the security already built into modern devices—FaceID, TouchID, or Windows Hello—to protect access keys.
In slightly more technical terms: content is encrypted with AES-GCM (256-bit), workspace keys are shared using ML-KEM, and access is protected with phishing-resistant passkeys via WebAuthn / FIDO2.
In one minute: what E2EE means
With E2EE enabled:
- Data is encrypted on our device before it is uploaded.
- Workspace members decrypt data locally on their devices.
- Dossira can store and deliver encrypted data, but cannot decrypt it.
Note: Some minimal operational metadata (for example timestamps and file sizes) is still processed to run the service. Content and file names remain encrypted.
The boundary we get with E2EE
When E2EE is enabled:
- Dossira cannot read file contents.
- Dossira cannot read file names.
- Dossira cannot decrypt a workspace on request.
This is not a policy choice. It follows from how keys are held.
When we should use E2EE
E2EE is best when confidentiality outranks convenience:
- High-stakes workspaces where disclosure risk is unacceptable.
- Restricted projects where even the service operator must remain blind.
- Long-lived secrets where we want stronger resistance against future threats.
Pros & Cons (is E2EE the right tool?)
E2EE is not “more secure” in every dimension. It is more private by design, and it shifts some operational responsibility to the workspace.
Pros (what we gain)
- Provider-blind content: Dossira cannot decrypt workspace content because we do not hold the keys.
- Reduced insider and vendor risk: If a service account, operator, or dependency is compromised, encrypted content remains unreadable.
- Better fit for high-sensitivity work: E2EE fits when confidentiality requirements dominate convenience.
- Future-facing key exchange: Using post-quantum key encapsulation strengthens long-term confidentiality for secrets with long lifetimes. [1]
Cons (what we give up)
- Fewer server-side features: Integrations that require cleartext do not work. Some automation patterns are not compatible with E2EE.
- Search feels different at scale: Full-text search runs locally, which can be slower on large datasets and across many devices.
- Lost-key risk becomes real: If an organization loses all valid keys, the data cannot be recovered by Dossira.
- More deliberate admin operations: Offboarding, re-invites, and device replacement are routine—but require admins to follow process.
A simple rule of thumb
- If we need integrations, server-side indexing, and maximum convenience, use a standard workspace.
- If we need a provider-blind workspace, use E2EE and adopt basic admin hygiene (at least two keys per admin).
The trade-offs (what changes in an E2EE workspace)
E2EE imposes three practical limitations:
-
No server-side integrations
We cannot connect E2EE workspaces to automations that require cleartext. -
Search works differently
Full-text search happens locally on our device, not on the server. On very large datasets, this may feel different from standard search. -
Lost-key risk is real
Because Dossira does not have a master key, we cannot recover encrypted data if an organization loses all keys.
Key management & recovery
No “crypto password” to remember
Most users never handle cryptographic material directly.
- We use device-backed protection: FaceID / TouchID / Windows Hello.
- Technically, this is implemented via WebAuthn and the FIDO2 standard. [6]
- If preferred, we can use a dedicated hardware key instead (for example a compatible FIDO2 security key). This can be optional or mandatory by workspace policy.
If a regular user loses a device
Workspace members do not need to panic:
- If someone loses their device or access key, a Workspace Administrator can remove them and re-invite them.
- The user will generate a new key and regain access going forward.
Important boundary:
- Support cannot recover E2EE keys and cannot “reset” E2EE data access. Only workspace admins control membership and recovery actions.
What workspace admins should do
Admins are the safety margin. We should adopt simple operational hygiene:
- Register at least two keys per admin.
Example: one device + a second device, or one device + one security key. - Keep a backup key stored safely.
If we use hardware keys, keep a spare in controlled storage. - Use multiple devices where practical.
The system supports multiple keys per user, so redundancy is straightforward.
The “Super Admin” safety net
For organizations that want a predictable recovery path:
- A designated Super Admin can be a member of every workspace, so a trusted individual can help recover access if other admins lose keys.
- We choose who holds this role. We keep it limited to one or a few trusted individuals.
Setup: enabling E2EE
E2EE is a workspace-level decision.
- When creating a new workspace, select “End-to-End Encrypted” in the security options.
- Workspace members complete a one-time key setup on first access.
Irreversible by design
- We cannot convert an existing standard workspace to E2EE.
- We cannot “decrypt” an E2EE workspace to make it standard.
- The security model is set at workspace creation.
Technical appendix (for security and IT teams)
This section is intentionally placed at the end so teams can adopt E2EE without needing to read cryptography notes first.
Cryptographic building blocks
Content encryption
Workspace data is encrypted using AES-GCM with 256-bit keys. [2]
Post-quantum note: Symmetric cryptography like AES is not expected to fail the way today’s public-key cryptography does under large quantum computers. The main known quantum impact is a generic speedup, which is why 256-bit keys are commonly used to keep a large safety margin. National guidance in Europe also notes that the quantum impact is limited for symmetric cryptography, and that 256-bit symmetric keys are considered quantum-resistant in practice. [3][4]
Key encapsulation (post-quantum)
We employ ML-KEM for secure distribution of workspace keys among authorized members. ML-KEM is standardized by NIST as FIPS 203. [1]
This is designed to protect against “harvest now, decrypt later” scenarios where an attacker stores encrypted traffic today for future decryption attempts.
Why ML-KEM now: Governments and security agencies are publishing migration guidance, and ML-KEM is one of the baseline algorithms being prepared for broad adoption. [1][7][8]
Key storage
By default, keys are protected by device-backed security:
- Keys are stored in device secure storage (for example Secure Enclave / TPM equivalents) and unlocked via OS-level authentication.
- Where supported, we rely on WebAuthn capabilities so keys remain bound to strong device protections. [6]
As an alternative:
- Keys can be stored on hardware tokens supporting the relevant FIDO2 capabilities. [6]
Keys never leave the client device in cleartext.
Metadata protection
In E2EE mode:
- File content and file names remain encrypted.
- Only minimal operational metadata required to run the service may be processed (for example timestamps and sizes). We avoid storing unnecessary cleartext metadata.
Operational consequences
- Server-side indexing and third-party processing are restricted because the server cannot decrypt content.
- Local operations (search, preview, and decryption) are performed on the client.
References
-
US National Institute of Standards and Technology (NIST), Federal Information Processing Standard 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), 2024.
-
US National Institute of Standards and Technology (NIST), Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, 2007.
-
Norwegian National Security Authority (NSM), NSM Cryptographic Recommendations 2025, version 2.0, approved 17 March 2025.
-
National Cyber and Information Security Agency (NÚKIB), Annex to the document “Minimum Requirements for Cryptographic Algorithms”: Quantum threat and quantum-resistant cryptography, 20 May 2025.
-
European Commission, Commission Recommendation (EU) 2024/1101 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, 11 April 2024.
-
UK National Cyber Security Centre (NCSC), Recommended types of multi-factor authentication (includes FIDO2), updated 26 September 2024.
-
UK National Cyber Security Centre (NCSC), Timelines for migration to post-quantum cryptography, 20 March 2025.
-
German Federal Office for Information Security (BSI), Migration to Post Quantum Cryptography: Recommendations for action, 31 May 2021.
-
Agence nationale de la sécurité des systèmes d’information (ANSSI), Avis de l’ANSSI sur la migration vers la cryptographie post-quantique (suivi 2023), 21 December 2023.