SafeMeet / Security Overview
SafeMeet Security & Encryption Overview
SafeMeet is a privacy-first communication platform designed with security as the default.
- Messaging & files
- Fully end-to-end encrypted
- Calls & meetings
- Frame-level E2EE, on by default
- Cryptographic core
- Hybrid classical + post-quantum
Every message, file, call, and meeting on SafeMeet is protected by end-to-end encryption (E2EE) and cannot be read, heard, or accessed by SafeMeet servers or operators.
Built for the post-quantum era, and for adversaries who can wait
Encryption protects a conversation only for as long as the mathematics underneath it holds. SafeMeet is engineered on the assumption that this will change.
The threat is retroactive, and it is patient
Nearly all encryption in use today establishes keys using elliptic-curve cryptography. A sufficiently capable quantum computer would break that mathematics — and, critically, it would break it retroactively.
An adversary does not need a quantum computer today to benefit from one tomorrow. They need only to record encrypted traffic now, store it, and decrypt it once the hardware exists. This is known as harvest-now, decrypt-later.
That threat model belongs squarely to well-resourced state actors. Intercepting traffic at national scale, storing it for decades, and waiting for a cryptographic capability to mature is not a theoretical adversary — it is a budgeted programme. For anyone whose communications must remain confidential for ten or twenty years — journalists and their sources, legal and medical practice, diplomatic and defence communication, human-rights work — the protection has to be in place before the traffic is sent, not after.
What SafeMeet does about it
SafeMeet Core E2EE v1.0 implements a hybrid cryptographic core. Every message key depends on both a classical and a post-quantum secret, so an attacker must break both to learn anything.
- ML-KEM-768 (NIST FIPS 203) contributes post-quantum shared secrets at session setup and at each sparse post-quantum ratchet epoch.
- ML-DSA-44 (NIST FIPS 204) authenticates device identity alongside Ed25519, so device bundles cannot be forged by a quantum-capable attacker.
- Classical X25519 and Ed25519 run in parallel — neither branch is a single point of failure.
- Production policy fails closed: no classical-only downgrade, no legacy frames, and group keys must travel over post-quantum-protected channels.
We have released the complete technical whitepaper, a normative protocol specification, and the reference implementation — with archive hashes so reviewers can verify they are reading the same snapshot we are. Cryptography earns trust by being examined, not announced.
SafeMeet is built for environments where confidentiality, integrity, and trust are essential.
End-to-end encryption by default
SafeMeet enforces E2EE across all communication types. There is no configuration to get wrong.
Messaging & file sharing
End-to-end encrypted using the Matrix cryptographic protocol (Olm / Megolm). Encryption happens on your device before anything leaves it.
Calls & meetings
Audio and video streams are encrypted end-to-end using frame-by-frame media encryption. SafeMeet servers function solely as encrypted data relays and do not have access to plaintext audio, video, messages, or shared files.
Messaging security: the Matrix protocol
SafeMeet uses the Matrix protocol for secure messaging and file transfer — chosen because its cryptography is publicly specified, publicly reviewed, and independently implementable.
Key properties
- True end-to-end encryption
- Device-based identity and verification
- Forward secrecy
- Post-compromise security for one-to-one messaging
- Open, publicly reviewed cryptography
How it relates to Signal
The Matrix encryption design is cryptographically comparable to the Signal protocol and follows the same modern security principles used by leading secure messengers.
Olm is an implementation of a Double Ratchet–based protocol, similar in design to the Signal protocol. Megolm extends Olm to efficiently support large group chats at government-level and nationwide scale, using a sender-based shared-key model conceptually similar to Signal's Sender Keys approach.
Unlike proprietary systems, Matrix cryptography is open source and publicly analysed, reducing the risk of hidden backdoors.
Taking Matrix into the quantum era
Matrix gives SafeMeet an open, peer-reviewed foundation with forward secrecy, device verification and post-compromise security. Like every widely deployed end-to-end encryption protocol in use today, that foundation establishes keys using elliptic-curve cryptography — mathematics a large quantum computer would eventually break, including for traffic recorded years earlier.
SafeMeet does not replace that foundation. We extend it, and the extension is our own engineering work:
Post-quantum key establishment
SafeMeet Olm-ML-KEM Session Binding ties verified ML-KEM-768 key material and both endpoint device bundles to the established Matrix session. The derivation transcript binds the session identifier, both bundles and the post-quantum ciphertext together, so no piece can be transplanted into another conversation.
Post-quantum identity
Device bundles are signed with ML-DSA-44 as well as Ed25519 — the ML-KEM key once, then the complete bundle again at a second layer. A quantum-capable adversary cannot forge a SafeMeet device identity, which matters for active interception, not only for recorded traffic.
Continuous post-quantum ratcheting
The SafeMeet EC-PQ Epoch Ratchet runs a classical message ratchet alongside a sparse ML-KEM epoch branch, combining both through a domain-separated HKDF-SHA-256 combiner. Post-quantum entropy is refreshed as the conversation continues, not only when it starts.
The result is a conversation whose message keys depend on both a classical and a post-quantum secret. Breaking one branch is not enough — an attacker has to break both, and a future quantum computer breaks only one of them.
Group rooms inherit the same protection: room keys are distributed over channels that production policy requires to be post-quantum protected, and room state is ML-DSA signed with membership and epoch bound in. See the full design
Where Matrix-based encryption is trusted
Matrix is one of the few open protocols with real deployment in environments that cannot rely on closed or proprietary encryption.
Government and defence environments
Matrix-based encryption has been adopted in government and defence-related environments where secure, auditable communication is required. Examples include:
- French Government — uses Tchap, a secure messaging platform built on Matrix, for official government communications.
- German Federal Government — supports Matrix-based secure messaging initiatives for internal and inter-agency communication.
- NATO — Matrix has been evaluated and referenced in secure collaboration and federated communication research within NATO-affiliated contexts.
Armed forces and European public sector
Matrix is one of the few open protocols that has seen actual deployment within European armed forces and public-sector institutions. Examples include:
- Bundeswehr — uses BwMessenger, a secure messaging system built on Matrix, for military personnel.
- French Ministry of the Interior — deploys Matrix-based secure communications for public-sector and internal use.
- European public sector bodies — multiple EU institutions and agencies have adopted Matrix for sovereign and interoperable communications.
Healthcare and regulated industries
Matrix encryption is used in healthcare and regulated environments where data protection, auditability and compliance are essential. Examples include:
- National Health Service (UK) — Matrix-based platforms such as Element have been adopted in clinical, operational and administrative contexts.
- European hospitals and research institutions — use Matrix for secure collaboration where GDPR compliance is required.
- Healthcare IT providers — integrate Matrix for secure messaging due to its open, inspectable encryption model.
Organisations requiring open, auditable standards
Matrix is especially trusted by organisations that cannot rely on closed or proprietary encryption systems. Examples include:
- Public sector IT organisations — prefer Matrix due to its open standards and public cryptographic review.
- Research institutions — use Matrix for transparent, peer-reviewed security.
- Privacy-focused enterprises — adopt Matrix to avoid vendor lock-in and opaque encryption.
- Open-source communities — trust Matrix because its cryptography and implementations are fully auditable.
SafeMeet's messaging encryption is based on protocols analysed in peer-reviewed research, including:
- Matrix Cryptography — Technical University of Munich.
- Device-Oriented Group Messaging: A Formal Cryptographic Analysis of Matrix' Core — IACR ePrint 2023/1300.
Call & meeting security: frame-level E2EE
SafeMeet secures calls and meetings using end-to-end encryption implemented with modern WebRTC — encrypting the media itself, not just the transport.
How it works
- Audio and video are encrypted on the sender's device
- Media is encrypted frame by frame
- Decryption occurs only on participant devices
- SafeMeet servers cannot decrypt, record, or monitor calls
What this design prevents
- Server-side recording
- Insider access
- Cloud provider interception
- Network-level surveillance
Even if network traffic is intercepted, the encrypted media cannot be reconstructed or listened to.
What SafeMeet can and cannot see
Operating a real-time communication service requires processing some routing information. Here is exactly where the line sits.
Cannot decrypt or access
- Message content
- Files and attachments
- Audio, video, or screen-sharing streams
- Meeting conversations
- End-to-end encryption keys
Does process, to deliver the service
- User and device identifiers
- Room or meeting identifiers
- Encrypted message and media payloads
- Timestamps and delivery metadata
- Minimal technical metadata required for delivery
- Network information required to establish connections, such as IP addresses
This information is used solely to deliver messages and calls. SafeMeet servers cannot use it to reconstruct message content or media.
Independent testing and open source
Claims about security should be checkable. Here is what has been tested externally, and where you can read the code yourself.
Third-party penetration testing
SafeMeet's applications and public infrastructure have undergone an independent third-party penetration test based on OWASP and PTES standards. The official assessment certificates are published in full:
Open source client
The SafeMeet app source code is open and publicly available for full transparency. Developers and security researchers can review exactly how encryption is implemented rather than taking our word for it.
What SafeMeet gives you
Encryption you don't have to enable
Matrix-based E2EE (Olm / Megolm) for messaging and file sharing, and frame-level E2EE for calls and meetings — enforced by default. Many mainstream collaboration platforms offer end-to-end encryption only in optional or limited configurations.
Keys that stay yours
Device-generated, client-side encryption keys, following the same architectural model used by modern secure messaging platforms such as Signal. We do not sell, share, or disclose user communication content to external platforms, advertisers, or third-party vendors.
A cryptographic core built to last
Hybrid classical and post-quantum encryption, open peer-reviewed standards, published penetration-test certificates and open source clients — so the guarantees can be verified rather than taken on trust.
SafeMeet provides verifiable end-to-end encryption by default, ensuring that communication content remains accessible only to intended participants. SafeMeet is built for individuals and organisations that require strong privacy guarantees, architectural transparency, and clear security boundaries.