Security FAQ

No. Every message is sealed with a hybrid ML-KEM-768 + X25519 key encapsulation and dual-signed with ML-DSA-65 + Ed25519. Private keys never leave your device. The relay only sees opaque ciphertext and the recipient ID.

Every layer that touches user data uses a quantum-resistant primitive. Shor-breakable algorithms (RSA, plain ECDH, plain ECDSA) appear nowhere in the data path.

• Messages. Hybrid ML-KEM-768 + X25519 for confidentiality and ML-DSA-65 + Ed25519 for authenticity. If the classical half is broken later, the post-quantum half still holds.
• Symmetric layer. ChaCha20-Poly1305 with 256-bit keys — Grover's algorithm only halves the search space, leaving ≥128-bit security, which NIST classifies as quantum-safe.
• Local vault & keystore. Argon2id (memory-hard) + ChaCha20-Poly1305. No PBKDF2, no AES-CBC, no RSA-wrapped keys.
• Encrypted appointment export (.qapt). Same Argon2id + ChaCha20-Poly1305 profile as the keystore. Legacy v1 files (PBKDF2 + AES-GCM-256, also symmetrically quantum-safe) can still be opened, but new exports are written in the v2 profile.
• Attachments & voice notes. Per-file ChaCha20-Poly1305 with random 256-bit keys, themselves wrapped by the recipient's hybrid ML-KEM-768 + X25519 envelope.
• Device unlock (Face ID / Touch ID / Windows Hello). Uses the WebAuthn PRF extension: the platform authenticator releases 32 raw bytes that we mix into a ChaCha20-Poly1305 wrap key via SHA-256. The classical WebAuthn signature (ES256/RS256) only gates access on-device — it never protects data in transit or at rest, so a future quantum break of ES256 still can't extract the PRF output from the secure enclave. Key derivation and the wrapped mnemonic are symmetric-only and quantum-safe.
• Key-change indicator. Non-security DJB2 fingerprint of an already-public key — used only to detect rotation, never to authenticate.

Even captured ciphertext stays unreadable and unforgeable in a "harvest-now, decrypt-later" scenario.

The local database is encrypted with audited Argon2id (memory ≥ 64 MiB, t ≥ 3) and ChaCha20-Poly1305. Without your passphrase or device biometric, an attacker cannot read it. The one-tap Lockdown wipe destroys all keys and the message cache.

No. The client tracks a sliding replay window and rejects duplicate envelopes. Every envelope also carries a sender-signed counter and expiry, so the relay cannot extend timers or resurrect old messages.

End-to-end encryption only protects the wire. If the other endpoint leaks the plaintext — screenshot, malware, shoulder-surfing — Qendra cannot help. Pick contacts you trust.

If something is reading your screen or your keystrokes, no messenger on earth can save you. Keep your OS updated, prefer biometric unlock, and use Lockdown if you suspect compromise.

The relay sees the recipient address and the rough time a message arrived (bucketed). Sender is sealed inside the envelope, but if you and one contact are the only people online at a given second, traffic analysis is still possible — see §4.

No. There is no password reset. Lose the 24 words and the account is gone — by design. Store them on paper, in a safe place, not in a cloud password manager.

Only what the server actually holds: opaque per-user account IDs, encrypted envelopes (auto-purged after 14 days), and public keys. The server does not store plaintext, private keys, recovery phrases, or message history beyond the TTL.

In principle, any operator of any service can be compelled. The defense is auditability: the client is open source, builds are reproducible, and contact safety codes will change immediately if your keys are swapped server-side. Verify them.

Check the Warrant Canary. If it stops being updated past the "next update due" date, or if it disappears or is materially weakened, assume legal compulsion has occurred and treat the service as potentially compromised.

The relay deliberately retains as little metadata as possible: timestamps are bucketed, presence/broadcast channels are disabled, and messages are purged after 14 days. There is no IP log, no read receipt log, no device-identifier log beyond the auth session. The edge layer (Cloudflare) sees connection metadata only for the duration of a request — see §4 and the Privacy page for the sub-processor disclosure and CLOUD Act assessment.

Your TLS connection to the edge (IP, time, approximate byte count). Message bodies are padded to fixed-size buckets, so wire length does not leak content length.

Yes. Cloudflare terminates TLS at the edge, so it sees your IP, request timing, and byte count — but only opaque ciphertext as the payload. The origin relay sees the same ciphertext and a Cloudflare-forwarded IP. Neither party can read message content. If hiding your IP from the edge is part of your threat model, use Tor or a trusted VPN at the network layer. We treat the edge as untrusted by design: the cryptography assumes it can be observed, compelled, or replaced.

Push notifications carry no plaintext. They only tell the device that "something" arrived — the actual decrypt happens after the app is unlocked.

The appointment invite itself (date, time, coordinates, title, accept/decline answers) is end-to-end encrypted in the same envelope as a normal message — the Qendra server never sees it. The map tiles, however, are fetched directly from tile.openstreetmap.org by your browser, so OpenStreetMap sees your IP and the tile coordinates you are viewing. Pick Approximate precision (~100 m) when you do not want the exact pin in any party's logs, and use a VPN or Tor if hiding your IP from the tile provider matters.

The sealed-sender envelope prevents server-side linking, but a global adversary watching both endpoints can still correlate timing. If that is in your threat model, use Tor / a VPN at the network layer — that is the right tool for it.

Only what is needed to deliver: the recipient ID, the encrypted blob, a bucketed arrival timestamp, and an auth-session token. Realtime presence and broadcast channels are disabled to avoid accidental leaks.

On reinstall, restore from recovery phrase, or after Lockdown. The client publishes the new public keys (ML-KEM, X25519, Ed25519, ML-DSA) and signs a KEY_CHANGED notice that goes out to every verified contact.

Their app shows a warning, marks the contact as unverified, and blocks sending until they re-verify the safety code with you over a trusted channel. This is the same defense against an attacker-induced swap as against a legitimate reinstall.

Because without it, a server compromise could silently substitute keys (MitM) and you would never know. Comparing the 6-emoji code, numeric safety number, or hex fingerprint takes 10 seconds and defeats the entire class of attack.

Per-device. Each install enrols its own biometric and tracks its own verification state. A second device starts unverified for every contact until you re-check the safety code.