Every message you send traverses infrastructure you do not control. Email hops through relay servers that log metadata. Chat messages pass through centralized platforms that retain conversation graphs. DNS queries broadcast your intent to your ISP in plaintext. Even when the content of a message is encrypted, the envelope — who contacted whom, when, from where, how often — tells a story that surveillance systems read fluently.

A zero-knowledge communication stack does not eliminate this infrastructure. It replaces each layer with components engineered so that no single provider, and no combination of providers, can reconstruct a complete picture of your communications. The goal is not anonymity in the absolute sense. It is architectural compartmentalization: each layer knows as little as possible about the layers above and below it.

This guide walks through building that stack from the network layer up. Each component is selected not for brand preference but for verifiable architectural properties: open-source code, independent audits, jurisdictional separation, and cryptographic guarantees that do not depend on the provider’s good intentions.

Layer 0: Threat Modeling Before Tooling

Before installing anything, define what you are defending against. A journalist protecting sources in an authoritarian state has different requirements than a startup founder keeping product strategy confidential during fundraising. The tools are the same, but the configuration intensity varies dramatically.

Three questions frame the threat model:

Who is the adversary? A curious employer monitoring corporate network traffic requires different countermeasures than a nation-state with lawful intercept capabilities. The former is defeated by a VPN. The latter demands traffic analysis resistance.

What is the attack surface? If your adversary has physical access to your devices, no amount of network encryption helps. If they operate at the ISP level, DNS encryption becomes critical. If they hold legal authority to compel disclosure, provider jurisdiction determines whether your data can be subpoenaed.

What is the cost of failure? If a leaked email means competitive disadvantage, the stakes are commercial. If it means imprisonment, the stakes demand a stack where every component is configured for maximum resistance.

Write your threat model down. It is the specification document for every configuration decision that follows.

Layer 1: Network Privacy with Mullvad VPN

The network layer is the foundation. Without it, every subsequent layer leaks metadata to your ISP: which services you connect to, when, and how much data you exchange.

Why Mullvad

Mullvad is selected for structural reasons, not marketing claims. It accepts anonymous payment methods including cash sent by mail. It does not require an email address, username, or any identifier to create an account. Your account is a randomly generated number. There is no password recovery because there is no password.

Mullvad has been independently audited multiple times, publishes the results, and has undergone a law enforcement seizure event (Swedish police, 2023) where their servers were confirmed to contain no user data. Their infrastructure runs on RAM-only servers with full-disk encryption — when a server loses power, its contents are shredded cryptographically. This is a textbook example of ephemeral infrastructure in practice.

Configuration

Install the Mullvad client on every device in your communication stack. Configure the following:

Kill switch: enabled. If the VPN connection drops, all network traffic stops. This prevents accidental exposure of your real IP address during connection interruptions.

DNS: use Mullvad’s DNS servers. This prevents DNS leak, where your encrypted tunnel protects traffic content but your DNS queries still go to your ISP in plaintext.

Protocol: WireGuard. WireGuard’s codebase is roughly 4,000 lines compared to OpenVPN’s 100,000+. A smaller codebase means a smaller attack surface. WireGuard also provides superior performance, which matters for real-time communication.

Multi-hop: enable for high-threat scenarios. Multi-hop routes your traffic through two Mullvad servers in different jurisdictions. This means that even if one server is compromised, the adversary sees only encrypted traffic destined for another Mullvad node.

Account generation: do it from a public network or Tor. If you generate your Mullvad account from your home IP, your ISP knows you use Mullvad. This may or may not matter for your threat model, but it is trivially avoidable.

Layer 2: DNS Privacy

DNS is the internet’s address book, and by default, it operates in plaintext. Every domain you resolve — every website you visit, every service you connect to — is visible to your DNS resolver, typically your ISP. Even with a VPN, misconfigured DNS can leak your browsing intent.

Encrypted DNS Configuration

Configure DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) at the operating system level:

Primary resolver: Use a provider that commits to no-logging and has been independently audited. Mullvad’s own DNS (when connected to their VPN) is the simplest option. For devices not on the VPN, consider providers that support encrypted DNS with a verified no-log policy and operate outside Five Eyes jurisdictions.

System-level configuration: On macOS, create a DNS profile that forces all DNS queries through your chosen encrypted resolver. On Linux, configure systemd-resolved with DoT. On iOS and Android, use the native encrypted DNS settings introduced in recent OS versions.

Validation: After configuration, visit a DNS leak test service through your browser. You should see only your chosen resolver, not your ISP’s DNS servers. Run this test from each device in your stack.

Why This Matters

DNS queries reveal intent. A journalist querying whistleblower-submission.example.org has disclosed their activity even if the subsequent HTTPS connection is encrypted. DNS privacy eliminates this metadata leak at the resolution layer.

Layer 3: Encrypted Email with ProtonMail

Email is structurally hostile to privacy. The SMTP protocol was designed in 1982 for a network where every participant was a trusted academic institution. Headers expose sender and recipient addresses, originating IP addresses, mail server paths, timestamps, and client software versions. The content may be encrypted, but the envelope is a surveillance gift.

ProtonMail does not fix SMTP. Nothing can. What it does is minimize the damage by encrypting mailbox contents with keys the provider cannot access, operating under Swiss jurisdiction (which requires a Swiss court order for data disclosure, and does not recognize foreign mass surveillance orders), and providing features designed to reduce metadata exposure.

Configuration for Maximum Privacy

Account creation: Create your ProtonMail account while connected to Mullvad. Use a dedicated email address that is not linked to your real identity. ProtonMail may request a verification method — use a disposable SMS service or an existing anonymous email if available.

Default encryption: ProtonMail encrypts all stored mail with your account password. Enable two-password mode: one password for login, a separate mailbox password for decryption. This means a compromised login does not automatically expose your mail archive.

PGP for external recipients: For contacts who do not use ProtonMail, configure PGP encryption. ProtonMail integrates PGP key management directly into the interface. Import your contacts’ public keys so that outbound mail to non-ProtonMail addresses is still encrypted end-to-end.

Expiring messages: For sensitive communications, set message expiration timers. The recipient receives a link to view the message, and the content is shredded after the timer expires. This is not cryptographically guaranteed deletion — the recipient can screenshot — but it limits the persistence window.

Disable remote content loading: HTML emails routinely contain tracking pixels that phone home when opened, leaking your IP address, device type, and open timestamp. Disable remote content loading in ProtonMail settings.

Layer 4: Email Aliasing with SimpleLogin

Even with ProtonMail, every service you register with sees your email address. Over time, this creates a graph: one email address linked to dozens of services, each of which can be breached, sold, or subpoenaed independently.

SimpleLogin (now owned by Proton) creates disposable email aliases that forward to your real inbox. Each service gets a unique alias. If one alias is compromised, you burn it without affecting anything else.

Configuration Strategy

One alias per service. Never reuse aliases. If a service is breached, the leaked email address connects to nothing else in your digital life.

Alias naming convention: Use random strings, not descriptive names. a7k9m2@simplelogin.co reveals nothing. my-banking-alias@simplelogin.co reveals intent.

Reply routing: When you reply through a SimpleLogin alias, the recipient sees the alias address, not your real ProtonMail address. Verify this behavior by sending a test email through each alias.

Directory aliases: For services you expect to use heavily, create a dedicated SimpleLogin directory. This allows you to generate aliases on-the-fly by prepending any string to your directory address.

Burn compromised aliases: The moment an alias receives spam or appears in a breach database, shred it. SimpleLogin allows instant deactivation. The alias stops forwarding immediately. Create a fresh alias for the service and update your registration.

Layer 5: Secure Messaging with Signal

Signal is the only major messaging application where the server architecturally cannot read message content, cannot access contact lists, and retains essentially no metadata about its users. This is not a policy claim. It is a consequence of the Signal Protocol’s cryptographic design and Signal’s sealed sender mechanism.

Configuration for Maximum Privacy

Registration number: Signal requires a phone number for registration. This is the protocol’s primary privacy weakness. Use a dedicated number not linked to your identity — a prepaid SIM purchased with cash, or a VoIP number from a privacy-respecting provider. Register while connected to Mullvad.

Registration lock: Enable registration lock (Settings > Account > Registration Lock). This prevents an adversary who obtains your phone number from re-registering your Signal account on a different device and intercepting your messages.

Disappearing messages: Set a default disappearing message timer for all conversations. For routine communication, 24 hours is reasonable. For sensitive exchanges, consider one hour or less. This is not a security guarantee — the recipient’s device stores messages until the timer fires — but it limits the exposure window if a device is later compromised or seized.

Screen security: Enable screen security (Settings > Privacy > Screen Security). This prevents Signal content from appearing in app switchers and blocks screenshots within the application on Android.

Notification privacy: Configure notifications to show neither the sender name nor message content. On iOS: Settings > Notifications > Show > No Name or Content. This prevents shoulder-surfing attacks and ensures that a locked phone’s lock screen does not display message previews.

Relay calls through Signal servers: In Settings > Privacy > Advanced, enable “Always Relay Calls.” Direct calls can expose your IP address to the recipient. Relaying through Signal’s servers prevents this at the cost of marginal latency.

Verify safety numbers: For critical contacts, verify safety numbers in person or through a separate secure channel. This confirms that no man-in-the-middle has inserted themselves into the key exchange.

Layer 6: Operational Security Practices

Tools are necessary but insufficient. A zero-knowledge communication stack fails if the human operating it leaks information through behavior.

Compartmentalization

Maintain strict separation between your private communication stack and your conventional digital life. Do not sign into your privacy email from the same browser session where you are logged into Google. Do not use Signal on a phone that also runs Facebook Messenger with microphone permissions enabled.

Consider dedicated devices: one phone for conventional use, one for private communications. At minimum, use separate browser profiles with distinct cookie jars, extensions, and DNS configurations.

Metadata Discipline

Encrypted content protects what you say. Metadata discipline protects the fact that you said anything at all.

Timing patterns: If you consistently message a contact at the same time every day, that pattern is metadata even if the content is encrypted. Vary your communication timing when the stakes warrant it.

Contact graph: Every person you communicate with through your private stack is a node in a graph. If one node is compromised, the adversary learns that you communicate with that person. Limit your private communication graph to contacts who genuinely require that level of protection.

Cross-channel references: Never reference a Signal conversation in an unencrypted email. Never mention a ProtonMail contact in a Slack message. Information leaks sideways through casual cross-references more often than it leaks through cryptographic compromise.

Regular Auditing

Review your stack quarterly:

  • Test for DNS leaks from every device.
  • Verify that Mullvad’s kill switch is still enabled.
  • Review your SimpleLogin aliases and burn any that are unused or compromised.
  • Check Signal’s safety numbers for key contacts.
  • Review ProtonMail’s active sessions and revoke any you do not recognize.
  • Update all software in the stack. Security vulnerabilities in outdated versions negate cryptographic protections.

Assembling the Stack

When all layers are operational, a message’s journey looks like this:

You compose a message in Signal on a device connected to Mullvad VPN. Your DNS queries resolve through encrypted DNS. The Signal Protocol encrypts the message content with keys that the Signal server cannot access. The sealed sender mechanism encrypts the sender’s identity so that even Signal’s servers do not know who sent the message. The encrypted payload traverses the VPN tunnel, exits from a Mullvad server in a jurisdiction you selected, and reaches Signal’s infrastructure. The recipient’s device decrypts the message. After the disappearing message timer expires, both devices shred the plaintext.

For email: you compose in ProtonMail, connected through Mullvad. The message is encrypted with the recipient’s PGP key before it leaves ProtonMail’s servers. Your sending address is a SimpleLogin alias, so the recipient sees no connection to your real mailbox. ProtonMail’s servers store only the encrypted blob. Swiss law protects against foreign disclosure orders.

No single provider in this chain sees the complete picture. Mullvad knows you connect to their network but not what you do. Signal knows encrypted blobs are exchanged but not their content or the sender’s identity. ProtonMail stores encrypted mail it cannot read. SimpleLogin routes emails it cannot decrypt to an inbox it cannot access.

This is not theoretical privacy. This is architectural compartmentalization — the same design principle that underpins Stealth Cloud’s zero-knowledge infrastructure. Each layer is designed so that compromise of any single component does not cascade into total exposure.

What This Stack Does Not Protect Against

Honesty about limitations is itself a security practice.

This stack does not protect against endpoint compromise. If malware on your device captures keystrokes before encryption, the entire stack is irrelevant. Endpoint security — OS updates, full-disk encryption, minimal application installation — is a prerequisite, not a layer in this guide.

This stack does not protect against compelled disclosure. If an adversary can legally or coercively compel you to unlock your device, encryption at rest provides limited protection. For scenarios involving compelled disclosure, consider duress mechanisms, hidden volumes, and plausible deniability architectures.

This stack does not defeat traffic analysis by a global passive adversary. A nation-state that monitors all internet traffic can correlate timing patterns even through VPN tunnels. Defending against this class of adversary requires Tor-level traffic analysis resistance, which imposes latency costs incompatible with real-time communication.

What this stack does is raise the cost of surveillance from trivial to substantial. It transforms passive, bulk collection into targeted, resource-intensive operations that must be justified and funded individually. For the overwhelming majority of professionals, this is the difference between having privacy and having none.

Build the stack. Maintain it. The infrastructure of private communication does not maintain itself, but the alternative — trusting providers, protocols, and jurisdictions by default — is an architecture designed for someone else’s benefit, not yours.