How Sublemonable works

Signal Protocol

Sublemonable uses the Signal Protocol — the X3DH key agreement for establishing a shared secret with someone you've never messaged before, and the Double Ratchet for everything after. It's the most scrutinized messaging cryptography in existence. We didn't invent our own. You should be suspicious of anyone who does.

Every single message is encrypted with its own AES-256-GCM message key, derived by the ratchet and discarded after use. Keys rotate with every message, which gives you forward secrecy: if a key were ever compromised, it unlocks one message, not your history — and your history is probably already gone anyway.

The implementations are established libraries, not homemade: libsodium.js in the browser, and libsignal-client on iOS and Android.

Key generation and storage

Your identity is a Curve25519 keypair generated on your device. The private half never leaves it. There is no account recovery, because there is nothing on our side to recover.

• Identity key — long-term Curve25519 keypair, generated on device, never leaves the device.
• Signed prekey — Curve25519, rotated every 7 days, signed by your identity key.
• One-time prekeys — uploaded in batches of 100 (public keys only), each consumed exactly once.
• Session keys — derived via X3DH on first contact, then advanced by the Double Ratchet.
• Message keys — AES-256-GCM, one per message, discarded after use.

Where your keys live depends on your platform:

• Browser — IndexedDB, encrypted with AES-256-GCM under a master key derived from your passphrase via Argon2id (64 MB memory, 3 iterations, 4 lanes — parameters chosen to make brute force expensive).
• iOS — Secure Enclave and Keychain, biometric-protected.
• Android — Android Keystore System, hardware-backed where the device supports it.
• Linux — the Secret Service API (GNOME Keyring on GNOME, KWallet on KDE). On minimal desktops with no Secret Service daemon, an Argon2id+AES-256-GCM encrypted file fallback is used. Either way the vault is encrypted before it reaches the storage layer.

What the server stores (and doesn't)

The server is a relay, not an archive. Store-and-forward only: a message sits on the server as an opaque encrypted blob until your recipient's device confirms delivery, at which point it is deleted immediately. Undelivered messages are purged after 72 hours and the sender is told so.

The complete list of what the server stores:

• Your account ID — a random UUID, not a username
• Your public identity key (Curve25519)
• Your public prekeys (one-time and signed)
• Encrypted message envelopes in transit — blob only
• Delivery receipts — a hash of the message ID, nothing else
• Account creation timestamp

And what it never stores:

• Plaintext messages, or message content of any kind
• IP addresses
• Device identifiers
• Contact lists
• Read receipts linked to identity
• Any logs that identify users — access logs are disabled outright

Transport is WebSocket over TLS 1.3 with certificate pinning on every platform. Typing indicators and read receipts travel as encrypted signals too — the server can't even tell whether you've read something. Deleting your account purges everything: prekeys, pending envelopes, the account record. Irreversibly.

Screenshot protection, by platform

Each platform allows a different level of protection, so we're specific about it:

• Android — FLAG_SECURE on every screen with message content. This is an OS-level hard block: screenshots and screen recordings come out black. The strongest protection of the three.
• iOS — screen recording is detected in real time and the message list is blurred immediately. Screenshots can't be prevented on iOS — the API only fires after the fact — so we detect them, warn you, and log the event locally on your device.
• Browser — the moment the window loses focus or visibility, the message list is blurred and desaturated within 120 milliseconds. On top of that, every conversation carries an invisible watermark encoding the recipient and timestamp — if a screenshot leaks, it identifies who leaked it.
• Linux (desktop app) — a focus-loss blur overlay, the same mechanism as the browser. This is best-effort: Linux exposes no universal API to hard-block screen capture on either Wayland or X11, and we won't pretend otherwise. Android remains the platform with a true OS-level hard block.

Honesty clause: a compromised device with an OS-level keylogger, or someone pointing a second camera at the screen, is outside any app's power. We don't pretend otherwise.

Tor routing

Network-level metadata — who connected, from where — is the hardest thing for any messenger to hide. Sublemonable keeps stored metadata minimal, and for the network layer it offers optional Tor routing: Orbot integration on iOS and Android, and a .onion address for the browser app via Tor Browser. It's opt-in, not on by default, because it trades latency for anonymity and that should be your call.

Open source and audit history

Everything — the encryption, the server, all three apps — is open source under AGPL-3.0 at github.com/jackofall1232/sublemonable. The AGPL means anyone running a modified Sublemonable as a service must publish their changes. No silent forks with weakened crypto.

Audit history: no third-party audits have been conducted yet. We'd rather tell you that plainly than imply otherwise. The audit log updates as audits complete, and researchers who want to conduct one — or who find a vulnerability — should follow the responsible disclosure policy: acknowledgement within 48 hours, fix target within 90 days, good-faith research explicitly authorized.

For the full technical treatment — threat model, transport details, the works — read the security model documentation.