Security stack
Concrete controls, concrete primitives
ZeeMSG exposes its security story as product behavior: how identity is established, how sessions are verified, what gets encrypted, and what still exists at the transport layer.
X25519 + Double Ratchet
Session establishment and message security are built around modern ratcheting primitives rather than a static shared secret.
XChaCha20-Poly1305
Message and media payloads use authenticated encryption to keep content confidential and tamper-evident.
Ed25519 + HKDF-SHA256
Signatures and key derivation are part of the app’s documented cryptographic stack, not hidden implementation trivia.
SQLCipher when protected
Local storage can be coupled to PIN-derived protection, and the app can rekey the database when the user changes their lock posture.
Encrypted backups
Backup export/import uses password-protected encryption so users can move devices without handing raw data to the network.
Call verification support
The calling layer includes verification-aware handling and settings for stricter offer validation when needed.
Trust model
Verification is a user action, not a hidden guess
ZeeMSG lets people compare fingerprints out of band and decide when a contact becomes verified. That is deliberate. The app does not silently replace trust with convenience.
- Compare local and peer fingerprints in the app.
- Mark or unmark verification based on what you confirmed out of band.
- Reset a secure session and verify again when compromise is suspected.
Local safety matters too
PIN lock, privacy shield, storage mode, backup tooling, and local erase controls matter as much as transport encryption when the device itself is at risk.
Network privacy
Transport choices are visible in the product
ZeeMSG does not pretend the network layer is magic. The app exposes the relay path and gives the user tools to understand it.
Switch between direct transport and Tor mode inside the app depending on the privacy/performance tradeoff you need.
Set relay URLs and tokens, inspect active relay state, and manage Cloudflare Access credentials when the deployment requires it.
Run public-IP checks, relay-health checks, and relay traces instead of guessing why a network path is failing.
Calling support includes TURN configuration and relay-enforcement controls for more difficult network conditions.
What the server can still see
Honest limits
End-to-end encryption protects content, but any relay service still sees enough metadata to route traffic. ZeeMSG is strongest when users understand that difference.
Not visible to the relay
Message plaintext, media plaintext, and the local trust decisions you make on device.
Still visible to the relay layer
Connection metadata needed to route messages, serve files, handle polling, and support call transport.
Mitigations
Tor mode, relay transparency, local storage protection, and verification workflows reduce the risk of treating routing metadata as harmless.