Threat Model
Security assumptions, attacker capabilities, and mitigations in Zentalk.
Trust Assumptions
What Zentalk Trusts
| Component | Trust Level | Assumption |
|---|---|---|
| Client device | Full | Device not compromised |
| Client code | Full | Code integrity verified |
| Cryptographic primitives | Full | X25519, AES-256, etc. are secure |
| Random number generator | Full | OS provides secure randomness |
What Zentalk Does NOT Trust
| Component | Trust Level | Mitigation |
|---|---|---|
| Servers | Zero | E2EE, zero-knowledge design |
| Network | Zero | TLS + E2EE + 3-hop relay |
| Other users | Partial | Verification, blocklist |
| Service operators | Zero | Cannot access content |
Attacker Model
Passive Network Adversary
Capabilities:
- Observe all network traffic
- Record encrypted messages
- Perform traffic analysis
Mitigations:
| Attack | Mitigation |
|---|---|
| Content inspection | AES-256-GCM encryption |
| Metadata analysis | 3-hop relay, traffic padding |
| Traffic correlation | Constant-rate dummy traffic |
| Long-term decryption | Forward secrecy (Double Ratchet) |
Active Network Adversary
Capabilities:
- Modify network traffic
- Inject messages
- Perform MITM attacks
Mitigations:
| Attack | Mitigation |
|---|---|
| Message injection | Ed25519 signatures |
| Message modification | GCM authentication tags |
| MITM key exchange | Identity verification, fingerprints |
| Replay attacks | Message counters, nonce uniqueness |
Compromised Server
Capabilities:
- Access all stored data
- Modify server behavior
- Log all requests
Mitigations:
| Attack | Mitigation |
|---|---|
| Read messages | E2EE (keys never on server) |
| Read contacts | Encrypted contact list |
| Identify users | Pseudonymous wallet addresses |
| Correlate sender/recipient | 3-hop relay |
| Serve malicious code | Client-side integrity checks |
Compromised Relay Node
Capabilities:
- Observe traffic through node
- Correlate timing
Mitigations:
| Attack | Mitigation |
|---|---|
| Traffic observation | Multi-hop routing (3 nodes) |
| Timing correlation | Traffic padding |
| Content inspection | Per-hop encryption layers |
Device Theft/Seizure
Capabilities:
- Physical access to device
- Extract storage contents
Mitigations:
| Attack | Mitigation |
|---|---|
| Key extraction | Device key + PIN/biometric |
| Message history | Local encryption (AES-256-GCM) |
| Session hijacking | Re-authentication required |
| Future messages | Revoke device, rotate keys |
Quantum Adversary (Future)
Capabilities:
- Break elliptic curve cryptography
- Factor RSA keys
- Run Shor’s algorithm
Mitigations:
| Attack | Mitigation |
|---|---|
| Break X25519 | Hybrid Kyber-768 (post-quantum) |
| Decrypt recorded traffic | Kyber + forward secrecy |
| Break signatures | Ed25519 → future PQ signatures |
Attack Vectors
Key Exchange Attacks
| Attack | Threat Level | Defense |
|---|---|---|
| MITM on X3DH | High | Identity key verification |
| Prekey exhaustion | Medium | Server rate limiting |
| Malicious prekeys | Medium | Signature verification |
| Key reuse | Low | Ephemeral keys per session |
Message Layer Attacks
| Attack | Threat Level | Defense |
|---|---|---|
| Replay | High | Unique nonces, counters |
| Reordering | Medium | Sequence numbers |
| Deletion | Medium | Delivery receipts |
| Modification | High | GCM authentication |
Metadata Attacks
| Attack | Threat Level | Defense |
|---|---|---|
| Social graph analysis | High | Encrypted contacts, 3-hop relay |
| Timing analysis | High | Traffic padding |
| Message size analysis | Medium | Padding to fixed sizes |
| Online status | Medium | Configurable presence |
Application Layer Attacks
| Attack | Threat Level | Defense |
|---|---|---|
| Malicious updates | Critical | Code signing, reproducible builds |
| XSS | High | CSP, input sanitization |
| CSRF | Medium | SameSite cookies, tokens |
| SQL injection | High | Parameterized queries |
Security Properties
Confidentiality
| Scope | Guarantee |
|---|---|
| Message content | Only sender and recipient(s) can read |
| Contact list | Only user can access |
| Call content | Only participants can hear/see |
| Metadata | Minimized, protected by 3-hop relay |
Integrity
| Data | Protection |
|---|---|
| Messages | GCM tag, signatures |
| Keys | Authenticated key exchange |
| Profile data | Signed by identity key |
Authenticity
| Assertion | Verification |
|---|---|
| Message author | Ed25519 signature chain |
| User identity | Identity key fingerprint |
| Device | Device-specific signatures |
Forward Secrecy
| Time Window | Protection |
|---|---|
| Per message | Double Ratchet key rotation |
| Per session | Ephemeral DH keys |
| Long-term | Key deletion policy |
Guarantee: Compromising current keys does not reveal past messages.
Post-Compromise Security
| Event | Recovery |
|---|---|
| Session key leaked | Next ratchet step heals |
| Identity key leaked | User must rotate identity |
| Device compromised | Revoke device, re-establish sessions |
Guarantee: Compromising current keys provides only temporary advantage.
Identity Key Compromise Recovery
When an Identity Key is compromised, immediate action is required to restore security and prevent impersonation. This section outlines the detection, response, and recovery process.
Compromise Detection
Warning Signs
| Indicator | Severity | Description |
|---|---|---|
| Unknown devices | Critical | Devices you did not authorize appear in linked devices |
| Unauthorized sessions | Critical | Active sessions from unknown locations |
| Safety number changes | High | Contacts report unexpected fingerprint changes |
| Messages you did not send | Critical | Contacts receive messages you never wrote |
| Account setting changes | High | Profile, privacy settings modified without your action |
| Login notifications | High | Authentication alerts from unknown locations |
Server-Side Anomaly Detection
Zentalk servers monitor for suspicious patterns without accessing message content:
| Detection Type | Monitored Behavior |
|---|---|
| Geographic anomalies | Logins from physically impossible locations |
| Session velocity | Multiple new sessions in short timeframe |
| Device fingerprinting | Unusual device characteristics |
| Behavioral patterns | Deviation from normal usage patterns |
| Prekey consumption | Abnormal rate of prekey requests |
Note: Anomaly detection is privacy-preserving and operates on metadata patterns only.
Immediate Response
When you suspect your Identity Key is compromised, take these steps immediately:
| Step | Action | Priority |
|---|---|---|
| 1 | Open Security Settings → Emergency Revocation | Immediate |
| 2 | Revoke all active sessions | Immediate |
| 3 | Remove all linked devices | Immediate |
| 4 | Enable account lockdown mode | Immediate |
| 5 | Notify critical contacts through alternative channels | Within minutes |
| 6 | Document any suspicious activity observed | Within hour |
Session Revocation Process
1. Navigate to Settings → Security → Active Sessions
2. Select "Revoke All Sessions"
3. Confirm with device PIN/biometric
4. All session keys are immediately invalidated
5. Server marks all prekeys as revokedContact Notification
Immediately inform your contacts through alternative secure channels:
- Use a pre-established verification code/phrase
- Confirm your new Identity Key fingerprint
- Warn them to ignore messages from old sessions
- Request they verify safety numbers before communicating
Identity Key Rotation Process
Step-by-Step Rotation Procedure
| Phase | Action | Technical Details |
|---|---|---|
| 1 | Generate new Identity Key pair | Ed25519 keypair generated locally |
| 2 | Generate new Signed Prekey | Signed with new Identity Key |
| 3 | Upload new prekey bundle | Old bundle marked as revoked |
| 4 | Cryptographically link old → new | Signed transition statement |
| 5 | Broadcast key change | Push notification to all contacts |
| 6 | Invalidate old Identity Key | Permanently marked as compromised |
How Contacts Learn About New Identity Key
| Method | Description |
|---|---|
| Push notification | Immediate alert: “Contact has rotated Identity Key” |
| Safety number change | Visual indicator on conversation |
| Verification prompt | App prompts to re-verify fingerprint |
| Signed transition | Old key signs statement pointing to new key |
Transition Period Handling
During the transition period (typically 24-72 hours):
| Concern | Handling |
|---|---|
| Old key messages | Rejected by client, warning displayed |
| New key messages | Require safety number verification |
| Pending messages | Re-encrypted with new session keys |
| Group messages | Require session re-establishment |
What Happens to Pending Messages
| Message State | Outcome |
|---|---|
| Undelivered (in transit) | Discarded, sender notified to resend |
| Delivered but unread | Remain readable if device not compromised |
| Queued on server | Deleted, cannot be decrypted |
| In sender’s outbox | Sender must re-establish session and resend |
Impact on Existing Sessions
All Sessions Must Be Re-established
After Identity Key rotation, all existing Double Ratchet sessions become invalid:
| Session Type | Required Action |
|---|---|
| 1:1 conversations | New X3DH key exchange required |
| Group memberships | Sender key redistribution |
| Linked devices | Re-link with new Identity Key |
| Verified contacts | Re-verify safety numbers |
Message History Implications
| Data Type | Accessibility |
|---|---|
| Messages before compromise | Readable (forward secrecy protected) |
| Messages during compromise | Potentially exposed to attacker |
| Messages after rotation | Secure with new keys |
| Local message database | Intact if device not compromised |
Important: Messages encrypted with compromised keys should be considered potentially exposed.
Group Membership Re-verification
| Step | Action |
|---|---|
| 1 | Automatic removal from all groups (security measure) |
| 2 | Group admins notified of member key change |
| 3 | Re-invitation required for each group |
| 4 | Other members verify your new Identity Key |
| 5 | New Sender Key distributed after re-joining |
Contact Notification
How Contacts Are Notified of Key Change
Contacts receive multiple indicators of your key change:
| Notification Type | Visibility |
|---|---|
| Safety number changed banner | Prominent, in conversation |
| Push notification | ”Security alert: Contact changed keys” |
| Identity key fingerprint | New fingerprint displayed |
| Verification status reset | Previously verified → unverified |
| Warning on message send | Prompt to verify before sending |
Verification Requirement
After your Identity Key changes, contacts see:
⚠️ Safety Number Changed
[Your Name]'s security keys have changed.
This could mean:
• They reinstalled Zentalk
• They switched devices
• Someone may be trying to impersonate them
Verify the new safety number before sending
sensitive messages.
[Verify] [Accept Risk]Risk of Impersonation During Transition
| Risk | Mitigation |
|---|---|
| Attacker uses old key | Old key marked revoked, messages rejected |
| Attacker races to new key | Cryptographic link from old to new |
| Social engineering | Out-of-band verification required |
| Delayed revocation | Immediate server-side invalidation |
Critical: Always verify new Identity Keys through a separate secure channel.
Recovery Timeline
| Phase | Duration | Actions |
|---|---|---|
| Detection | 0-30 minutes | Identify suspicious activity, confirm compromise |
| Revocation | 1-5 minutes | Revoke sessions, remove devices, enable lockdown |
| Key Generation | < 1 minute | Generate new Identity Key and prekey bundle |
| Upload & Broadcast | 1-2 minutes | Push new keys to server, notify contacts |
| Contact Notification | 1-24 hours | All contacts receive key change alerts |
| Session Re-establishment | 24-72 hours | Rebuild sessions as contacts come online |
| Full Recovery | 1-7 days | All regular contacts have verified new key |
Timeline Considerations
| Factor | Impact on Timeline |
|---|---|
| Number of contacts | More contacts = longer full recovery |
| Contact activity level | Inactive contacts may take weeks |
| Group memberships | Each group requires admin action |
| Linked devices | Must re-establish each device |
Prevention Measures
Hardware Security Keys
| Feature | Benefit |
|---|---|
| FIDO2/WebAuthn | Identity Key stored in secure element |
| Tamper-resistant | Physical extraction extremely difficult |
| No key export | Private key never leaves device |
| Transaction confirmation | User presence required for signing |
Supported hardware: YubiKey, Titan Security Key, Trezor, Ledger
Multi-Factor for Sensitive Operations
| Operation | Required Factors |
|---|---|
| Identity Key export | Device PIN + biometric + time delay |
| New device linking | Existing device approval + verification |
| Session revocation | Device PIN + biometric |
| Account recovery | Recovery code + verification |
Regular Key Verification Habits
| Practice | Frequency | Benefit |
|---|---|---|
| Verify critical contacts | After any key change | Detect MITM attacks |
| Review linked devices | Weekly | Detect unauthorized access |
| Check active sessions | Weekly | Identify suspicious activity |
| Rotate prekeys | Automatic (monthly) | Limit exposure window |
| Export/backup recovery codes | Annually | Ensure recovery capability |
Additional Prevention Recommendations
| Recommendation | Description |
|---|---|
| Dedicated device | Use separate device for sensitive communications |
| Secure enclave | Enable hardware-backed key storage |
| Minimal linking | Only link essential devices |
| Regular audits | Review security settings monthly |
| Incident response plan | Know steps to take before compromise occurs |
Out of Scope
Zentalk does not protect against:
| Threat | Reason |
|---|---|
| Compromised device | Endpoint security is OS responsibility |
| Rubber-hose cryptanalysis | Physical coercion outside protocol |
| Malicious recipient | Cannot prevent screenshots/forwarding |
| Side-channel attacks | Timing, power analysis require physical access |
| Bugs in implementation | Mitigated by audits, not by design |
Security Recommendations
For Users
| Action | Benefit |
|---|---|
| Verify key fingerprints | Prevents MITM attacks |
| Use strong device PIN | Protects local data |
| Enable disappearing messages | Reduces exposure window |
| Review linked devices | Detect unauthorized access |
| Keep app updated | Receive security patches |
For High-Risk Users
| Action | Benefit |
|---|---|
| Use dedicated device | Isolation from other apps |
| Enable relay-only calls | Hide IP address |
| Disable link previews | Prevent URL tracking |
| Use through Tor | Additional anonymity layer |
| Rotate identity periodically | Limit correlation window |
Audit Status
| Component | Status |
|---|---|
| Protocol design | Internal review |
| Cryptographic implementation | Pending external audit |
| Client application | Pending external audit |
| Server infrastructure | Pending external audit |
Related Documentation
- Protocol Specification - Cryptographic details
- Architecture - System design
- Zero-Knowledge - Privacy architecture
Last updated on