What is encrypted

• Messages — every text message is encrypted on your device with PGP (Curve25519) for the recipients and for yourself. The server stores only ciphertext.
• Files and images — encrypted with the same scheme before upload; the server never sees the original bytes.
• Voice messages — same as files.
• Private-channel posts and files — encrypted with a random AES-256 channel key. The key is wrapped to each member with their PGP public key. Invite links carry the key in the URL fragment, which browsers never send to the server.
• Voice calls — WebRTC media is encrypted with DTLS-SRTP between peers. TURN credentials are issued per user and expire.
• Your private key — generated in your browser at registration and stored encrypted. The server holds only the encrypted blob.
• Login TOTP secret — generated on your device and stored server-side encrypted with a server key. It is used only to verify sign-in codes, and is separate from the password-derived key-wrap secret that protects your private key.

How your keys work

At registration your device generates a PGP keypair. Your password derives a key that encrypts a random private-key wrapping secret; that secret never leaves your device in plaintext. The server stores the encrypted private key and the encrypted key-wrap secret, but never receives either in plaintext. The server receives your password over TLS to verify the Argon2id hash; it does not store the plaintext password.

TOTP is a sign-in factor, not a second encryption layer. The login TOTP secret is separate and is used only by the server to verify authentication codes. It does not derive, wrap, encrypt or unlock the private key. With TOTP enabled, an attacker also needs a current code or recovery code to sign in, but the key itself remains protected by the password-derived key-wrap secret.

When you change your password, the key material is re-wrapped on your device with the new password; the server only stores the new encrypted blobs.

Private channels use a separate random channel key. The owner creates it, wraps it to each member's public key, and the client stores it encrypted with the device key. The server keeps only the wrapped copies. Invite tokens are stored as hashes plus a token copy encrypted with the channel key; the actual key travels in the link fragment and is never included in an HTTP request.

Account security

• Argon2 password hashing (memory-hard, salted).
• Optional TOTP two-factor authentication for every account. It is strongly recommended but not required: you can skip it at signup and enable it later in settings. With 2FA enabled, sign-in needs your password plus a code or recovery code.
• Recovery codes stored only as SHA-256 hashes, single-use.
• Session management — every device has a revocable session record; revoking one signs that device out immediately.
• Rate limiting on login, TOTP, registration, messaging, uploads and previews.

What the server can see

Honesty matters more than marketing, so here is the metadata the service necessarily processes:

• Your username and public key.
• Your password, transiently: received over TLS during registration and login to verify the Argon2id hash. It is not stored in plaintext.
• Who you exchanged messages with, and when (message timestamps).
• Attachments are stored under opaque names. File size, MIME type and an optional original filename remain metadata. For private-channel files the stored MIME type and filename are generic; the real values are inside the encrypted post.
• Private-channel metadata: channel name, description, avatar, member and admin lists, invite creator and expiry, and post timestamps. Not channel keys, post text, or file contents.
• Session and network data: clearnet session records store the IP address and user agent, plus creation and last-seen timestamps. Onion sessions store tor instead of an IP. IP addresses are also used for rate limiting. Session records expire after 7 days, or 3 days of inactivity. Rate-limit counters use keyed hashes, not raw IP addresses. Application request logs exclude client IP addresses, request paths, user agents and referers and are retained for up to 3 days; Markero access logging is disabled.
• Push subscription data if you enable notifications.

It cannot read message content, files, or your private key, and it cannot recover your password.

Operational practices

• Encrypted files are deleted from disk when messages, conversations or accounts are removed, including attachments that were never delivered.
• Sessions and rate-limit counters are the only per-user state files; rate-limit counters contain keyed hashes, not raw IP addresses.
• No advertising, no tracking cookies, no third-party analytics that profile you (a cookieless visitor counter may be enabled for the marketing pages).
• Nightly database backups are size-verified and kept for seven days.

What Markero does not protect against

• A compromised device — malware or a keylogger sees everything before encryption.
• The person you're talking to — they can screenshot, copy or forward anything.
• Network-level correlation — the server sees IP addresses; use a VPN or Tor if your threat model requires it.
• Metadata analysis — who talks to whom and when is visible to the operator.

Tor access

Markero publishes an official v3 onion service. Tor hides your network origin from the server, but not your identity, device or metadata. Read Markero over Tor for the setup steps and the limits of Tor.

Reporting a vulnerability

If you find a security issue, please report it to [email protected] before disclosing it publicly. We'll confirm receipt and keep you updated on the fix.