The current iPhone client encrypts supported messages, media, statuses, group system events, and encoded call frames before they reach UIMessage relays. The backend routes and stores ciphertext in normal operation, while retaining account, profile, audience, delivery, call, and routing metadata.
How message envelopes work today
For each recipient, iPhone creates a fresh ephemeral Curve25519 key, derives an envelope key with HKDF-SHA256, and seals the payload with ChaCha20-Poly1305. This is not X3DH or Double Ratchet, and it does not provide Signal-style post-compromise security.
The current trust boundary
- Recipient public keys come from UIMessage's server directory without safety-number or key-transparency verification.
- An active compromise of that directory could substitute a recipient key.
- There is no X3DH, Double Ratchet, sender signature, or complete multi-device identity model in the current client.
- Direct-call key agreement uses long-term identities and does not provide forward secrecy after identity-key compromise.
- Android is a UI preview and does not implement this protocol.
Security claims should describe the implemented protection and its remaining trust assumptions — no more and no less.
