TECHNICAL SECURITY
Security Architecture & Threat Model
We believe in cryptographic transparency rather than marketing buzzwords. Here is how MNDO encrypts messages, manages keys, isolates transport relays, and handles technical limitations.
No Buzzwords: Cryptographic Transparency
You will never see MNDO claim “military-grade encryption”, “unhackable”, or “zero metadata.”Those phrases communicate no mathematical or architectural reality. Below is the exact cryptographic pipeline, what intermediaries can inspect, and where security boundaries begin and end.
01 · ARCHITECTURE MODEL
Separation of cryptography and transport
Nostr is the transport and distribution mesh. It is NOT the mechanism that provides private-message confidentiality. Confidentiality comes entirely from the Signal Protocol cryptographic layer.
02 · DATA EXPOSURE MATRIX
Classification of what is encrypted vs visible
Every layer of the MNDO protocol has distinct confidentiality properties.
MNDO Data Classification & Exposure Matrix
Clear cryptographic boundaries: distinguish what is encrypted, what is public, and what relays can observe.
| Data Category | Encryption Status | Publicly Visible? | Who Can Potentially Access It? |
|---|---|---|---|
Private message plaintext | E2EE (Signal Double Ratchet) | No | Conversation endpoints only |
Private message ciphertext | Encrypted payload | No (Ciphertext) | Nostr relays & network carriers |
Private media attachments | Client-side encrypted blob | No | Storage host sees only encrypted blob & hash |
Public profile (Name, bio) | None (Plain Nostr event) | Yes | Anyone querying relay events |
Public posts & reactions | None | Yes | Network peers & relay users |
Recovery phrase (12 words) | Local keystore secret | No | Local user device only; never transmitted |
Public key / Identifier | No secrecy intended | Yes | Publicly discoverable across the mesh |
Relay & network metadata | Transport-level | Relay-visible | Independent relay operators (IP, timing, frequency) |
03 · CRYPTOGRAPHY
End-to-End Encryption: X3DH and Double Ratchet
MNDO implements peer-reviewed cryptographic primitives via libsignal_protocol_dart.
X3DH Key Agreement
Asynchronous session initiation uses the Extended Triple Diffie-Hellman (X3DH) protocol. When initiating a conversation, the sender fetches the recipient's prekey bundle (Identity Key, Signed PreKey, and One-Time PreKey) published as signed Nostr events. This allows establishing mutually authenticated secret keys even when the recipient is offline.
Double Ratchet Algorithm
Active sessions continuously evolve via the Double Ratchet, combining a symmetric KDF ratchet with an asymmetric Diffie-Hellman ratchet. Each message derives a fresh ephemeral encryption key that is permanently destroyed after decryption:
- • Forward Secrecy (FS): Compromise of current keys cannot decrypt past messages.
- • Post-Compromise Security (PCS): The ratchet automatically self-heals after a temporary state compromise.
04 · INTERMEDIARY VISIBILITY
What relays can and cannot observe
What Relays CAN Observe
- Event IDs: Canonical SHA256 hashes of the Nostr event structure.
- Public Keys: The sender's public key (
pubkey) and recipient's public key tag (p-tag). - Timestamps: Event creation time (
created_atunix epoch). - Connection Metadata: Connecting IP address, ISP routing data, and WebSocket session timings.
- Payload Size: Byte length of the encrypted ciphertext envelope.
What Relays CANNOT Observe
- Plaintext Messages: Private chat contents are unreadable ciphertext to all intermediaries.
- Voice Note Plaintext: Audio samples are encrypted locally before upload.
- Attachment Keys: AES-256 media decryption keys and IVs are transmitted only inside the E2EE envelope.
- Ratchet & Session Keys: Double Ratchet ephemeral states never leave user device memory.
- 12-Word Seed Phrase: Private identity seed is never broadcast over any network packet.
05 · THREAT REALITY
Metadata protection vs anonymity
It is critical to understand that end-to-end encryption does not provide anonymity. While the contents of your messages are protected by Signal cryptography, traffic analysis across Nostr relays allows relay operators or state-level adversaries observing network traffic to correlate:
Users requiring higher levels of traffic analysis resistance should use external anonymizing networks (such as Tor, Orbot, or verified VPNs) when connecting to Nostr relays.
06 · KEY MANAGEMENT
Cryptographic key lifecycle
MNDO manages multiple tiers of keys across the identity, prekey, and session ratchets.
Curve25519 / Ed25519 long-term identity key. Stored in hardware-backed secure storage.
Medium-term keys rotated periodically, signed by the identity key to prevent man-in-the-middle attacks.
Pool of ephemeral keys consumed once during X3DH session initialization and immediately discarded.
Derived per-message by the Double Ratchet. Deleted immediately after message processing.
07 · IDENTITY VERIFICATION
Verifying contacts & what we do not yet claim
In accordance with Signal's X3DH specifications, cryptographic key agreements ensure that messages are encrypted for the keypair received, but they do not automatically authenticate that the public key belongs to the real-world person you intend to contact.
To prevent man-in-the-middle substitutions, users should verify contacts by comparing public-key fingerprints (npub) or scanning contact QR codes out-of-band.
What we do not currently claim: MNDO does not yet claim automated protection against identity-key changes or automated server-verified end-to-end identity authentication. Ongoing protocol development is working toward standardized safety numbers and key-change alerts.
08 · ENDPOINT SECURITY
The limits of endpoint compromise
Endpoints are the Ultimate Security Boundary
No mathematical encryption can protect communications if the physical device itself is compromised. If an endpoint is infected with keylogging malware, screen recorders, compromised operating systems, or if physical custody is lost while unlocked, attackers can capture plaintext messages directly from screen memory.
Keep your mobile OS updated, use screen lock biometric authentication, and avoid rooting or jailbreaking devices running MNDO.
09 · DATA AT REST
Local storage and database encryption
SQLCipher AES-256 Database
All message history, contact records, and active ratchet session states are stored in an SQLite database encrypted with 256-bit AES in CBC mode (via SQLCipher). The database encryption key is derived using PBKDF2 with 256,000 iterations.
Hardware-Backed Keystore
Your 12-word recovery mnemonic and master seed keys are stored using flutter_secure_storage, utilizing the Android Keystore (hardware TEE/StrongBox) on Android and the Keychain / Secure Enclave on iOS.
10 · MEDIA PIPELINE
Zero-Knowledge media storage and distribution
Media attachments (voice notes, photos, documents) never touch storage servers in plaintext.
11 · VULNERABILITY DISCLOSURE
Reporting security issues and audit status
Responsible Disclosure
If you discover a security flaw or cryptographic vulnerability in MNDO client applications, protocol implementations, or web services at mndo.online, email risvandev@gmail.com. We pledge to:
- • Acknowledge receipt within 48 hours.
- • Provide regular progress updates during triage.
- • Coordinate responsible disclosure and patch release before public announcements.
Audit Status
Audit Transparency: MNDO is currently in public beta. While our cryptographic implementation relies on established open-source libraries (libsignal_protocol_dart, sqlcipher), MNDO has not yet undergone a formal independent third-party code audit. All source code is publicly accessible on GitHub for peer inspection.
12 · LIMITATIONS
Honest summary of security boundaries
No software can provide absolute, infallible security. MNDO explicitly operates within the following boundaries: