Comparison
RVNT vs iMessage
RVNT: A peer-to-peer, post-quantum, end-to-end-encrypted messenger with no phone number and no servers. · iMessage: Apple's default messaging service for iPhone, iPad and Mac, end-to-end encrypted by default with post-quantum PQ3 cryptography, but closed-source, Apple-account-bound and Apple-device-only.
Bottom line: If you live in the Apple ecosystem and want strong, low-effort content encryption from a mature and well-resourced vendor, iMessage is the safer practical choice today: it is shipping at massive scale, its PQ3 protocol was independently reviewed by academic cryptographers and machine-verified with the Tamarin prover, and Apple actively hardens it. Be aware of its limits — it is closed-source, Apple-account-bound, exposes metadata, has no anonymity or duress feature, and its default E2EE is weakened by iCloud Backup unless you turn on Advanced Data Protection.
iMessage and RVNT both ship hybrid post-quantum encryption (ECDH + ML-KEM/Kyber) over a ratchet-based construction with forward secrecy, so on the core cryptography they are closely matched in ambition. They diverge sharply on architecture and trust model. iMessage is centralized, closed-source, and bound to an Apple Account tied to your real phone number or email — Apple's servers route every message and see metadata (who, when) in cleartext, and by default iCloud Backup can stash a copy of your Messages key on Apple's servers unless you enable Advanced Data Protection. RVNT is fully peer-to-peer with no central servers for content, requires no phone number or email, routes over Tor by default to suppress metadata, and adds an on-device duress PIN — but it is pre-release, unfunded, and not independently audited.
The facts, side by side
| RVNT | iMessage | |
|---|---|---|
| End-to-end encrypted by default | Yes | Yes iMessage (blue bubbles) is E2EE by default for the message body and attachments. This does NOT apply to SMS/MMS/RCS fallback (green bubbles), which are not E2EE. Critically, if iCloud Backup is on without Advanced Data Protection, a copy of the Messages in iCloud encryption key is stored in the backup, which Apple can access and disclose to law enforcement — so the default-on E2EE is undercut unless you also disable iCloud Backup or enable Advanced Data Protection. |
| Encryption protocol | Hybrid post-quantum X3DH (X25519 + ML-KEM-768) + Double Ratchet, AES-256-GCM | PQ3 (hybrid P-256 ECDH + ML-KEM/Kyber post-quantum, AES-128-CTR message payloads, AES-256-CTR attachments, ECDSA P-256 signing); replaced the legacy ECIES/RSA scheme starting iOS 17.4 (Feb 2024) PQ3 is a hybrid 'Level 3' design combining classical Elliptic Curve Diffie-Hellman (on NIST P-256) with NIST's ML-KEM (Kyber) — Kyber-1024 for initial key establishment and Kyber-768 for ongoing rekeying. It uses three ratchets (a symmetric-key ratchet, an ECDH ratchet, and a post-quantum Kyber ratchet that rekeys approximately every 50 messages and at least once every 7 days) for forward secrecy and self-healing post-compromise recovery. Per Apple's Platform Security guide, message content is encrypted with AES-CTR using a 128-bit key and attachments with a randomly generated AES-256-CTR key. |
| Post-quantum key exchange | Yes | Yes PQ3 protects both initial key establishment and the ongoing message ratchet with post-quantum cryptography, which Apple calls 'Level 3' — it claims to be the first to reach this tier and to surpass the post-quantum coverage of other widely deployed messaging apps (e.g. Signal's PQXDH, which Apple labels 'Level 2' because its post-quantum protection is limited to initial key establishment). Rolled out from iOS/iPadOS 17.4, macOS 14.4, watchOS 10.4 in February 2024. |
| Requires a phone number | No | Partial On an iPhone, iMessage can activate against the SIM phone number (via a hidden activation SMS), but full functionality (cross-device sync, iCloud, contact key verification) is tied to an Apple Account. On iPad/Mac there is no phone number; activation uses an Apple Account email. So a phone number is common but not strictly required everywhere. |
| Requires an email address | No | Partial An Apple Account (Apple ID) — which is itself an email address or phone number — is effectively required for the full service, and is mandatory to set up iMessage on iPad and Mac. Anonymous, identifier-free use is not supported. |
| How you’re identified | Local Ed25519 keypair, username claimed by proof-of-work | Apple Account (Apple ID) bound to a phone number and/or verified email address, registered with Apple's Identity Service (IDS) You are addressed by your real-world phone number and/or email, registered to Apple's centralized Identity Service. There is no anonymous or pseudonymous identifier; your contact graph is inherently tied to your Apple Account. |
| Architecture | peer-to-peer | centralized Fully centralized. All registration, key directory (IDS), routing and push delivery (APNs) run through Apple's servers. There is no federation, no P2P, and no self-hosting option. |
| Metadata protection | Sealed sender + Tor by default + mixnet (cover traffic, fixed-size padding) | None by design — Apple's IDS and APNs servers see sender/recipient identifiers, timestamps and routing data in cleartext; only message content and attachment bodies are E2EE Apple's IDS capability-query logs record who looked up whom, the date/time and the querying IP address. Apple can produce this iMessage metadata in response to legal process (pen-register / trap-and-trace orders) even though it cannot read default-E2EE message content. |
| Routes over Tor by default | Yes | No |
| Open-source client | Yes | No iMessage is fully proprietary and closed-source, built on Apple's binary APNs protocol. There is no official client outside Apple's ecosystem and no public source for independent review of the implementation. |
| Independently audited | No RVNT is pre-release and has not yet completed a formal third-party security audit — the code is open source so it can be reviewed, but treat it as not-yet-audited. | Partial PQ3's design received independent academic cryptographic review — game-based (computational) security proofs by Prof. Douglas Stebila (University of Waterloo) and machine-checked symbolic verification with the Tamarin prover by Prof. David Basin's group (ETH Zürich), plus an independent third-party assessment of the PQ3 source code that Apple says found no security issues. However, iMessage is otherwise closed-source, so the full shipping implementation cannot be independently audited the way an open-source client can; the published verification covered the protocol design rather than the complete proprietary codebase. |
| Jurisdiction / who can be subpoenaed | Peer-to-peer (no central operator to subpoena) There is no company-run server that relays or stores message content, so there is no inbox in a data center to subpoena. A small bootstrap server only holds public prekeys + peer-discovery data. | United States (Apple Inc., Cupertino, California) |
| On-device duress / panic defenses | Yes | No No duress/decoy PIN or panic feature specific to iMessage. Device-level protections (passcode, Face ID, Stolen Device Protection, Lockdown Mode) exist at the OS level but there is no in-app duress unlock or hidden-vault mechanism. |
| Max attachment size | No limit on a direct link (P2P streaming) No size limit on a direct peer-to-peer connection (segmented streaming with resume-on-disconnect). Transfers that fall back to a relay are currently capped at 256 MB until resumable relay ships. | 100 MB (larger media falls back to iCloud links) Commonly cited at 100 MB per attachment; Apple does not publish a formal limit in its security docs. Larger files (e.g. long videos in iCloud Photos) are shared as iCloud links rather than transmitted inline. Apple's security docs note APNs itself relays only small payloads (4–16 KB), so attachments are encrypted with a randomly generated AES-256 key and uploaded to iCloud, with the key sent inside the E2EE message. |
| Collects telemetry / analytics | No | Partial Message content is not used for ads and Apple states it does not read iMessage content. However, Apple is not zero-telemetry: device/OS diagnostics and analytics exist (opt-out), and operational metadata flows through Apple servers. This is far less data collection than typical, but not 'no telemetry/analytics' in the strict RVNT sense. |
The verdict
If you live in the Apple ecosystem and want strong, low-effort content encryption from a mature and well-resourced vendor, iMessage is the safer practical choice today: it is shipping at massive scale, its PQ3 protocol was independently reviewed by academic cryptographers and machine-verified with the Tamarin prover, and Apple actively hardens it. Be aware of its limits — it is closed-source, Apple-account-bound, exposes metadata, has no anonymity or duress feature, and its default E2EE is weakened by iCloud Backup unless you turn on Advanced Data Protection. RVNT targets the threat models iMessage does not address — no identifiers, no central servers, metadata protection via Tor, open-source auditability, and an on-device duress PIN — but as pre-release, unaudited software it cannot yet match iMessage's maturity, independent review, or reliability. Choose iMessage for proven everyday security inside Apple's walls; choose RVNT's goals when anonymity, metadata resistance, and self-sovereignty matter more than maturity.
Frequently asked questions
Is iMessage really end-to-end encrypted?
Yes, for blue-bubble iMessages and their attachments — content is E2EE by default and, since iOS 17.4 (2024), protected by the post-quantum PQ3 protocol. Two big caveats: SMS/MMS green-bubble fallback is not encrypted, and if iCloud Backup is on without Advanced Data Protection, a copy of your Messages encryption key is stored in your backup, which Apple can access and hand to law enforcement. To keep iMessage fully end-to-end encrypted at rest, enable Advanced Data Protection or turn off iCloud Backup.
Is iMessage quantum-safe?
For the most part, yes. Apple's PQ3 protocol (rolled out in 2024) is a hybrid design that pairs classical Elliptic Curve cryptography (P-256) with the NIST-standardized ML-KEM (Kyber) post-quantum algorithm for both initial key setup and ongoing rekeying, so an attacker would have to break both. PQ3 also rekeys roughly every 50 messages and at least once every 7 days for self-healing recovery.
Can I use iMessage anonymously or without an Apple ID?
Not really. iMessage is tied to your real phone number and/or email through an Apple Account registered with Apple's centralized Identity Service. On iPad and Mac an Apple Account is required, and even on iPhone full functionality depends on one. There is no anonymous or pseudonymous identifier, and the service only runs on Apple devices.
What can Apple or law enforcement see?
Apple cannot read default-E2EE message content, but its servers see metadata — sender and recipient identifiers, timestamps and routing information — which is not encrypted and can be disclosed under legal process. And without Advanced Data Protection, iCloud Backup gives Apple a copy of the key needed to decrypt your messages, which it can provide to law enforcement.
Comparisons here are kept honest and dated — we name where the other app wins. RVNT is the post-quantum, peer-to-peer option with no phone number and no servers.