D4TE Security Model
No security system protects against everything. This document honestly describes what D4TE does and doesn't protect against, so you can make informed decisions about your communications.
What D4TE Protects Against
Server Compromise
Threat: An attacker gains access to Council's servers.
Protection: Even with full server access, attackers cannot read message content. The server only handles encrypted data and never possesses decryption keys.
Network Eavesdropping
Threat: Someone intercepts your internet traffic.
Protection: All messages are encrypted before transmission. Intercepted data is unreadable without the passphrase and device keys.
Future Quantum Computers
Threat: Quantum computers could break today's encryption (the "harvest now, decrypt later" attack).
Protection: D4TE uses ML-KEM-768, a quantum-resistant algorithm standardized by NIST. Messages encrypted today remain secure even if quantum computers become practical.
Passphrase Brute Force
Threat: An attacker tries to guess your passphrase.
Protection: D4TE uses Argon2id, which requires significant memory and computation for each guess. A strong passphrase makes brute force attacks impractical.
Compromised Past Keys
Threat: An attacker obtains keys that were used in the past.
Protection: Forward secrecy means past message keys are mathematically destroyed after use. Old keys cannot decrypt past messages.
Replay Attacks
Threat: An attacker captures and re-sends old messages.
Protection: Each message is bound to a specific time interval and counter, making replayed messages detectable and rejectable.
What D4TE Does NOT Protect Against
Unlocked Device Access
Threat: Someone accesses your phone or computer while you're logged in.
Reality: If someone can see your screen, they can read your messages. D4TE protects messages in transit and at rest, but not from someone looking over your shoulder.
Passphrase Compromise
Threat: Someone learns your network's passphrase (e.g., you tell them, they guess it, or it's written down somewhere).
Reality: D4TE's device-binding helps here—the passphrase alone isn't enough. But if an attacker has the passphrase AND their own device in your network, they can read messages.
Metadata
Threat: An observer wants to know who you communicate with and when, without reading content.
Reality: Council servers must know which network a message belongs to in order to route it. This metadata is visible to Council and potentially to network observers.
Compromised Network Member
Threat: Someone in your network isn't trustworthy.
Reality: Anyone with the passphrase and a device in the network can read messages—that's by design. D4TE protects the network from outsiders, not from members.
Device Malware
Threat: Malware on your device captures messages before encryption or after decryption.
Reality: D4TE cannot protect against a compromised operating system. If malware can read your screen, it can read your messages.
Security Comparison
| Feature | Council (D4TE) | Signal | iMessage | |
|---|---|---|---|---|
| End-to-end encryption | ✓ | ✓ | ✓ | ✓ |
| Quantum-resistant | ✓ Native | Partial | ✗ | ✗ |
| Passphrase-based groups | ✓ | ✗ | ✗ | ✗ |
| Server has no keys | ✓ | ✓ | ✓* | ✓* |
| Forward secrecy | Per-message | Per-session | Per-session | Per-session |
| Device-bound keys | ✓ | ✗ | ✗ | ✗ |
*WhatsApp and iMessage backup features may expose keys to servers.
Key Takeaways
- D4TE protects against server compromise, eavesdropping, and quantum attacks
- D4TE does NOT protect against unlocked device access, compromised members, or metadata observation
- Strong passphrases and trusted networks are essential complements to encryption
- Understand your threat model and choose appropriate mitigations