Threat Model

Threat Model

Occulta Protects Against

• A messaging platform reading your files or contact list
• A cloud provider scanning attachments for advertising
• A network attacker intercepting your encrypted files in transit
• Someone finding an encrypted file on your device or in email
• A remote attacker with no physical access substituting keys
• SIM-swap and phone number hijacking — no phone number exists in the system
• Server-side account compromise or provider-compelled key insertion — no server exists
• Credential phishing — no password
• A passive observer correlating messages to relationships via wire metadata
• Compromise of long-term keys exposing past messages (forward secrecy)
• A quantum adversary recording public keys today for future decryption (hybrid PQ key agreement)
• A quantum adversary targeting individual forward-secret messages (ML-KEM secrets mixed into every FS session key for PQ contacts)
• Coerced device access — entering a duress PIN presents a decoy view that is visually and structurally identical to the real one at rest: same UI, same settings, same layout, filtered share index
• A coercer testing live protocol behavior to detect duress mode — inbound bundles are never rejected because of restriction state, for any contact at any depth, so there is no accept/reject asymmetry between real and duress depths to probe

---

Occulta Does Not Protect Against

• An attacker physically present at a key exchange who can observe and intercept the MC channel before NI proximity is confirmed (mitigated but not eliminated by the peer ID guard and Diceware verification)
• Compromise of the device itself (unlocked phone, jailbreak, MDM) — an attacker with full device access can decrypt the SwiftData store and extract ML-KEM shared secrets, breaking the PQ protection for that contact
• Loss of your iPhone — contact keys are device-local with no automatic backup
• Future message confidentiality after device compromise — forward secrecy protects past messages, not future ones
• Contacts exchanged before the PQ upgrade remain classical-only until re-exchanged in person
• A quantum attacker targeting classical-only contacts — prekeys and messages are protected by P-256 ECDH only
• A coercer who has already forced a duress unlock and is watching the screen when a real, previously-hidden contact's genuinely new message arrives — that message decrypts and displays the same as any other, since decryption itself cannot differ by depth without reopening the detection asymmetry above; only the content shown at that moment is exposed, not the mode
• A contact added during a duress session before this protection existed — no prior version recorded why a contact had a given visibility setting, so a contact from a past coercion event can't be retroactively identified and confined; contacts created going forward are protected from the moment they're created