Frequently Asked Questions
The Threat Model
Council's design starts from specific assumptions about what an adversary can do:
- Interception: traffic between you and any server can be captured in transit, so nothing readable should ever be in transit.
- Harvest now, decrypt later: captured ciphertext is kept, with the plan of decrypting it when quantum computers or new techniques mature. Encryption that holds up today has to keep holding up decades from now.
- Quantum computing: Lily Chen, manager of NIST's Cryptographic Technology Group, put it plainly: "Quantum computers will completely break current, well-deployed public-key cryptography standards." NIST finalized its first post-quantum standards in 2024 for exactly this reason. Most messaging apps still rely on the algorithms on the wrong side of that transition.
- Forensic extraction: tools like GrayKey and Cellebrite can pull whatever a seized device still holds. Council can't stop a tool from reading a compromised device, so the goal is to limit what exists to find: encryption keys are created and stored on member devices (our servers never hold them), and burning a network destroys those keys and cascade-deletes the server's records outright instead of flagging them for later.
How Council Responds
Council is built on the D4TE protocol -- a post-quantum encryption protocol whose cryptographic operations use algorithms designed to resist both classical and quantum attacks. Your message keys are derived on your device and are not sent to Council. The server relays and stores ciphertext.
We assume your traffic is being captured. That's why Council uses ML-KEM-768 for every key exchange and AES-256 for every message. The D4TE protocol contains no quantum-vulnerable primitives. (Scoped exceptions sit outside the protocol: on iOS, a device-bound P-256 key inside the Secure Enclave wraps data at rest, and transport rides standard TLS like any app; neither touches message encryption or key exchange.) Captured message content is ciphertext with no classical key exchange behind it to attack later.
Security Analysis: Where We Stand
We believe in transparency about what our encryption can and cannot do. Council's D4TE protocol has been through several layers of internal analysis: formal mathematical proofs, automated security testing, and AI-assisted review.
What Was Analyzed
The complete Rust cryptographic codebase that powers Council's encryption -- including key derivation, message encryption, forward secrecy mechanisms, passphrase handling, and memory cleanup.
How the Core Properties Were Graded
Our January 2026 internal review graded the properties below. A follow-up April 2026 internal audit identified additional findings; those are tracked in our hardening roadmap.
- Forward Secrecy. Forward secrecy holds at the cycle boundary: rotating a network to a new cycle destroys the old cycle's keys, and within a cycle each message advances a one-way ratchet. Compromising current keys does not expose messages from cycles that were rotated and destroyed.
- Key Isolation. Each network has its own master key. Each sender within a network has independent encryption keys. Compromising one network does not affect others.
- Passphrase Protection. Passphrases are processed through Argon2id (64MB memory, 3 iterations) and immediately erased from memory. A leaked passphrase alone is not enough to read your messages -- an attacker also needs your device secrets. One legacy sign-in verifier derived from the passphrase does not yet get Argon2id hardening; its replacement is coded and arrives with our next protocol update.
- Defense in Depth. Critical data requires both a secret held on your device AND server authorization to decrypt. Compromising one without the other is not sufficient.
- Replay Protection. A replayed message can only decrypt to its original content and never advances or rewinds session state. Message counters only move forward; out-of-order delivery is tolerated within a bounded window rather than rejected.
- Memory Cleanup. Sensitive material (passphrases, keys, intermediate values) is cryptographically erased from memory immediately after use. This is verified at every step of the key derivation chain.
- Group-Scoped Authentication. Messages are authenticated with keys shared by the network's members, so authenticity is scoped to the group rather than to individuals. There is no per-person digital signature tying a message to your identity; the network is the trust boundary.
What We're Honest About
- Metadata is visible. Our servers can see when messages are sent, between which device IDs, and message sizes. We cannot see message content, but the fact that communication occurred is visible to the server infrastructure. We're working on reducing this.
- Key rotation is manual. If a passphrase is compromised, users need to explicitly rotate to new network credentials. There is no automatic revocation signal yet. This is on our roadmap.
- No encryption is permanent. Council's security is based on mathematical problems believed to be extremely hard to solve. We use the strongest algorithms available (ML-KEM-768, AES-256, SHA-512), but we cannot guarantee that future breakthroughs won't weaken them. No one can.
- Our analysis so far is internal. It includes formal mathematical proofs, automated security testing, and AI-assisted code review. No security analysis is exhaustive, and undiscovered vulnerabilities may exist.
Formal Proofs Completed
The D4TE protocol has formal mathematical proofs (in the classical random-oracle model) covering: message confidentiality, forward secrecy, phrase-compromise resistance, authentication soundness, and tag unforgeability. The protocol specification is available upon request for independent review.
What is Council?
Council is an encrypted messaging app built on the D4TE protocol. You create and control your own encryption keys for each network you join. Message keys are derived on your device, are not sent to Council, and can be destroyed ("burned") when you're done. Message content is encrypted before it leaves your device; the server stores that ciphertext plus the routing and account records described in our Privacy Policy.
How is this different from other encrypted messaging apps?
Most encrypted messaging apps manage your keys for you and build a network from your contacts. Council is different in five ways: (1) no contact graph -- Council never reads your contact list, and your phone number is used for sign-in only, never to map connections (the server does keep a routing record of which accounts belong to which network; encrypting that record is on our roadmap); (2) passphrase-based membership -- you join networks by knowing a shared phrase, not by sharing contact info; (3) a post-quantum protocol -- ML-KEM key exchange and AES-256 throughout; (4) the server holds no key that can decrypt your messages; (5) when you delete, the server performs an immediate cascade delete rather than a soft delete.
What does "burn" mean?
Burning a network destroys its encryption key on your device, and every member device destroys its copy when it processes the burn. Without the key, the remaining ciphertext cannot be decrypted. On our servers, a burn triggers an immediate cascade delete of the network's records as a matter of policy -- not a soft delete or a 30-day retention window.
What happens if someone gets my passphrase?
A leaked passphrase alone is not enough to compromise your messages. Council's layered security means an attacker with your passphrase still needs a secret held on your device and network-specific secrets that are never transmitted in the clear. That said, you should rotate your network credentials immediately if you suspect a passphrase has been compromised.
What is "post-quantum" and why does it matter?
Quantum computers will be able to break the encryption algorithms used by most messaging apps today (RSA, ECDH, Ed25519). "Harvest now, decrypt later" is a real strategy: adversaries capture your encrypted traffic today, planning to decrypt it when quantum computers mature. Council uses ML-KEM-768 (a NIST-standardized post-quantum algorithm) for every key exchange and AES-256 for every message. The D4TE protocol contains no quantum-vulnerable components, so captured message content has no classical key exchange behind it to attack later.
Can Council read my messages?
No. Message keys are derived on your device from your passphrase and device-specific secrets, and the server holds no key that can decrypt your messages. If our servers were compromised, your message content would remain ciphertext to the attacker.
Are voice calls encrypted too?
Yes. Calls happen inside your network, one to one or with the group: audio is encrypted frame by frame on your device with keys derived from the network passphrase, and the server relays ciphertext it cannot decrypt. The same honesty note as for messages applies to call metadata: server infrastructure can see that a call took place, between which accounts, and for how long, though not what was said. We're working on reducing this.
Who is Council for?
Council is for group conversations that need real protection: a team coordinating sensitive work, a board deliberating before a decision goes public, a journalist talking with a source, a family managing its own affairs. You don't need a dramatic reason. Wanting your private conversations to stay private is enough.
What does Council's security audit cover?
Council's D4TE protocol has been through formal mathematical proofs (covering confidentiality, forward secrecy, phrase-compromise resistance, and authentication), automated security analysis of the Rust cryptographic codebase, and AI-assisted security review. In our January 2026 internal review, the core properties -- forward secrecy, key isolation, passphrase protection, defense in depth, and replay protection -- graded well; a follow-up April 2026 internal audit identified additional findings, which are tracked in our hardening roadmap. We publish our findings honestly, including the limitations.
What are Council's limitations?
We believe in being upfront. Council's servers can see message metadata (when messages are sent, between which devices, and message sizes) -- though not the content. Key rotation after a compromise is currently manual. Council cannot protect against a compromised device (malware, keyloggers). And no encryption system can guarantee absolute, permanent security against all future mathematical or computational advances. We use the strongest algorithms available today and are committed to evolving as the field advances.
Does a message prove who wrote it?
No. Council's D4TE protocol authenticates messages with keys shared by the network's members, so authenticity is scoped to the group rather than to individuals: any member could, in principle, have computed the authentication tag for any message. There is no per-person digital signature tying your words to your identity. The flip side is that the protocol also does not prove to other members which member sent a message; the network itself is the trust boundary.