Frequently Asked Questions
The Modern Threat Landscape
Your digital privacy faces sophisticated threats that most encrypted messaging apps weren't built to handle. Here's what's out there:
- Man-in-the-Middle (MITM): Attackers intercept internet traffic and spoof certificates to gain access to your data in transit.
- Harvest Now, Decrypt Later (HNDL): Well-funded actors are capturing encrypted traffic today, planning to decrypt it when quantum computers or new techniques become available.
- Quantum Computing: According to the NIST Quantum Program Director, quantum computing has effectively defeated the encryption algorithms used by most messaging apps today.
- Forensic Extraction: Tools like GrayKey and Cellebrite can extract data from devices, making it critical that encryption keys and deleted data are truly gone -- not just hidden.
How Council Responds
Council is built on the D4TE protocol -- a post-quantum encryption protocol where every cryptographic operation uses algorithms that resist both classical and quantum attacks. Your encryption keys are generated on your device and never leave it. Not even our servers have access.
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. There are zero quantum-vulnerable primitives in the entire stack. For harvest-now-decrypt-later threats, there's nothing worth harvesting.
Security Audit Results
We believe in transparency about what our encryption can and cannot do. Council's D4TE protocol has undergone multiple layers of security analysis.
What Was Audited
The complete Rust cryptographic codebase that powers Council's encryption -- including key derivation, message encryption, forward secrecy mechanisms, passphrase handling, and memory cleanup.
Key Findings
- Forward Secrecy: Strong. Each message advances a one-way ratchet. Compromising a key at time T does not expose messages from before T. This is mathematically irreversible.
- Key Isolation: Strong. 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: Strong. 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.
- Defense in Depth: Strong. Critical data requires both your device keystore (hardware-backed) AND server authorization to decrypt. Compromising one without the other is not sufficient.
- Replay Protection: Strong. Messages cannot be replayed or reordered to produce different results. Counters are strictly monotonic.
- Memory Cleanup: Strong. 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.
- Deniable Authentication: Strong. Messages are authenticated using group-shared keys that any member can compute. This means a message cannot be cryptographically proven to have come from a specific sender to a third party outside the group -- providing the same deniability properties found in leading encrypted messaging protocols.
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.
- An independent human-led audit is in progress. Our current analysis includes formal mathematical proofs, automated security testing, and AI-assisted code review. An independent third-party cryptographic audit is underway and results will be published when complete.
Formal Proofs Completed
The D4TE protocol has formal mathematical proofs 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. Keys are generated on your device, never leave it, and can be destroyed ("burned") when you're done. Our servers store only encrypted data that we cannot read.
How is this different from other encrypted messaging apps?
Most encrypted messaging apps manage your keys for you and tie your identity to a phone number. Council is different in five ways: (1) no social graph -- your phone or email is for account security only, never shared or used to map connections; (2) passphrase-based membership -- you join networks by knowing a shared phrase, not by sharing contact info; (3) fully post-quantum -- zero vulnerable primitives in the entire stack; (4) the server is cryptographically excluded from key material, not just policy-excluded; (5) when you delete, it's a cascade delete -- immediately and permanently gone.
What does "burn" mean?
Burning a network permanently destroys the encryption key. Once the key is gone, all messages associated with that network become unreadable cryptographic noise -- on every device, on our servers, everywhere. This is not a soft delete or a 30-day retention. The data is gone. No tool, present or future, can reconstruct it.
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 your device secret (stored in your phone's secure hardware) and network-specific secrets that are never transmitted in the clear. This defense-in-depth is verified by our security audit. 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. There are zero quantum-vulnerable components in the entire system. Nothing to harvest, nothing to decrypt later.
Can Council read my messages?
No. This isn't a policy -- it's a consequence of our architecture. Encryption keys are derived on your device from your passphrase and device-specific secrets. Our servers never receive key material. Even if our servers were compromised, the attacker would only find encrypted data they cannot decrypt. We designed it this way on purpose.
Who is Council for?
Council is for anyone who believes their private conversations should stay private. That includes teams handling sensitive information, journalists protecting sources, organizations discussing strategy, and people who simply value their privacy. You shouldn't need a reason to want secure communication. Innocence deserves protection.
What does Council's security audit cover?
Council's D4TE protocol has undergone 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. All key properties -- forward secrecy, key isolation, passphrase protection, defense in depth, and replay protection -- received a "Strong" verdict. An independent human-led third-party audit is currently in progress. 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.
What is deniable authentication?
Deniable authentication means that while members of your network can verify that a message came from you, they cannot prove it to anyone outside the group. Council's D4TE protocol uses group-shared keys for message authentication -- any member could have computed the authentication tag for any other member. This means a screenshot or forwarded message cannot be cryptographically attributed to you. The message is authentic within the group, but deniable to everyone else.