Every Spojiti conversation is protected against quantum computers — today, for everyone, on every plan. Not a roadmap line: a Level-5 key agreement, a ratchet that turns post-quantumly with every reply, and post-quantum signatures on every key — all three from the NIST post-quantum standards, running in the app in your hand and checked against NIST's own test vectors every time it starts. Cryptographic strength is never a tier.
FIPS 203 at security level 5 — the strongest parameter set the standard defines — alongside the classical curve on every session start. Both secrets feed the root key through HKDF-SHA-256: an attacker must break both, and a quantum computer breaks only one.
The Double Ratchet's forward secrecy and self-healing happen post-quantumly too. Every time the conversation changes direction a fresh ML-KEM-768 key rides in the message header and the reply encapsulates to it, so the root key steps forward with a post-quantum secret at every turn — a key compromised tomorrow does not unlock what was said today, or next week.
FIPS 204 signs every published key beside Ed25519 — the classical prekey, the post-quantum prekey, and the identity behind them. A forged bundle needs both signatures forged, which closes the last classical door in the handshake: the one every other messenger still leaves open.
Message keys, media keys, database and backup keys are all 256-bit — already beyond the reach of Grover's algorithm. Nothing on the confidentiality path is classical-only.
The quantum threat to messaging is not a future break-in; it is a recording made today. Traffic captured now and stored will be opened the day a large enough quantum computer exists, unless the key agreement that protected it was already post-quantum. Spojiti's session setup has been hybrid since the first beta build, and is now ML-KEM-1024: the recording is worthless because the post-quantum half of the root key was never exposed to a curve a quantum computer can solve.
The in-session ratchet closes the second gap. A classical Double Ratchet heals a compromised session with a new Diffie–Hellman step — which is exactly the step a quantum computer can undo in retrospect. Spojiti's ratchet folds a fresh ML-KEM-768 secret into the chain at every turn of the conversation, so healing is post-quantum as well — not once at setup, but continuously, for as long as you talk.
A post-quantum library is new native code. A silently wrong one is worse than none: it would look like protection while producing keys the other side cannot reproduce — or predictable ones. So Spojiti runs the NIST known-answer tests for ML-KEM-768, ML-KEM-1024 and ML-DSA-65 on your device at every launch, before any of them is allowed near a conversation. The result is shown in Settings → Post-quantum protection, and the safety number you compare with a contact commits to the post-quantum keys as well as the classical ones.
Settings → Post-quantum protection shows the self-test result for each algorithm and the parameter sets in use. Compare safety numbers with a contact: they include the ML-KEM and ML-DSA public keys. Read the code — Spojiti Private Messenger Core is published under the AGPL v3, and the white paper documents every construction on this page.
The honest table, as of September 2026, by class of messenger: those with a post-quantum key agreement, those with classical end-to-end encryption only, and those where encryption is optional. Every row is a construction you can find in a published protocol specification or in source code.
| Protection | Spojiti | PQ key agreement | Classical E2EE only | Encryption optional |
|---|---|---|---|---|
| Post-quantum key agreement (ML-KEM hybrid) | Yes (ML-KEM-1024) | Yes | No | No |
| Post-quantum ratchet inside the session | Yes, every reply (ML-KEM-768) | Some | No | No |
| Post-quantum signatures on every key | Yes (ML-DSA-65) | No | No | No |
| Self-test against NIST vectors on the device | Yes, every launch | No | No | No |
| Post-quantum for every user, every plan | Yes | Yes | — | — |
| No phone number, no account to attack | Yes | No | Rarely | No |
| Open-source messaging core | Yes (Spojiti Private Messenger Core, AGPL v3) | Yes | Some | Partial |
Sources: the published protocol specifications and source code of the messengers surveyed; NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). Corrections to spojiti@spojiti.world.
PQXDH-style: X3DH over X25519 with a signed prekey, a one-time prekey and a signed ML-KEM-1024 prekey. The initiator encapsulates to the ML-KEM prekey; the shared secrets are concatenated (DH1 ‖ DH2 ‖ DH3 ‖ DH4 ‖ KEM) and HKDF-SHA-256 derives the root key. The signed prekey and the post-quantum prekey each carry an Ed25519 signature and an ML-DSA-65 signature under the account's post-quantum signing key; a bundle that publishes a post-quantum signing key and is missing either signature is refused, and the safety number commits to both signing keys.
Double Ratchet (X25519 DH ratchet, HKDF-SHA-256 chain keys, AES-256-GCM message keys with the header as associated data) plus an ML-KEM-768 ratchet that turns with the DH ratchet: every new sending chain publishes a fresh ML-KEM-768 encapsulation key in the header and encapsulates to the peer's last one; the KEM secret is concatenated with the DH output (DH ‖ SS) into the root-key KDF step. The header, KEM key and ciphertext included, is authenticated as associated data, so a relay that strips the post-quantum leg is refused as a downgrade rather than silently downgraded.
Media: AES-256-GCM under a fresh 256-bit key per item, the key carried inside the ratcheted message. Local database: SQLCipher, AES-256. Backups: sealed under a key derived from the 12-word phrase (HKDF, 256-bit). Group messages: per-member ratcheted sessions — no shared group key to harvest. Anonymous entitlements and Echo attunement: RSA blind signatures — an anonymity property, not a confidentiality one, and independent of the quantum question.