# Split Knowledge ## What is Split Knowledge? Split knowledge means dividing sensitive information across multiple parties so that no single party has enough to reconstruct the complete picture. In the context of VPNs: no single provider sees both who you are AND what you do online. This is the same principle behind Tor, multi-party computation, and many cryptographic protocols. You distribute trust across independent entities. Even if one is compromised or compelled to log, they only have a fragment. ## The Single VPN Problem When you route traffic through a single VPN provider, you shift observation from your ISP to your VPN. The provider now sees: | Your VPN Provider Sees | Your ISP Used to See | |------------------------|----------------------| | Your real IP address | Your real IP address | | Every destination you connect to | Every destination you connect to | | All your DNS queries | All your DNS queries | | Data volumes and timing | Data volumes and timing | You traded one observer for another. The VPN provider knows both your identity (from your IP and payment method) and your activity (every site, every query, every connection). This is not a critique of VPN providers. It is the architecture. Single-hop VPN shifts trust. It does not eliminate it. **Trust Boundaries:** Even "no-logs" providers are a trust boundary. Audits are point-in-time snapshots, not continuous proof. A provider could be compromised, legally compelled, or change their practices. Split knowledge reduces the damage any single point of failure can cause. ## How Split Knowledge Works Chain two or more VPN providers. Each provider sees only part of the picture. ### Two Providers: A then B ``` Your Device -> Wirebump -> Provider A -> Provider B -> Internet ``` | Provider | Knows | Does Not Know | |----------|-------|---------------| | Provider A (entry) | Your real IP address | Your destinations, DNS queries, traffic content | | Provider B (exit) | Your destinations, DNS queries, traffic content | Your real IP address | **Neither provider has both pieces.** Provider A knows who you are but only sees encrypted traffic to Provider B. Provider B sees what you do but only sees Provider A's IP, not yours. ## Why Multiple Providers Matter Using the same provider at both hops defeats the purpose. Same provider = same trust boundary = same logs = same legal jurisdiction = no split. | Configuration | Split Knowledge? | |---------------|------------------| | Mullvad VPN -> Mullvad VPN | No. Same company, same potential logging. | | Proton VPN -> Proton VPN | No. Same company, same potential logging. | | Mullvad VPN -> Proton VPN | Yes. Different companies, different jurisdictions. | | Proton VPN -> Mullvad VPN | Yes. Different companies, different jurisdictions. | Different providers means: - **Different legal jurisdictions.** Swiss law differs from Swedish law. A subpoena in one country does not automatically reach the other. - **Different infrastructure.** Separate data centers, separate systems, separate access controls. - **Different incentives.** Two independent companies would need to collude and correlate their data to reconstruct your activity. ## Three Layers: Entry, Middle, Exit For additional separation: ``` Your Device -> Wirebump -> Entry -> Middle -> Exit -> Internet ``` | Provider | Knows | Does Not Know | |----------|-------|---------------| | Entry | Your real IP | Destinations, middle's destinations, content | | Middle | Entry's IP, Exit's IP | Your real IP, your destinations, content | | Exit | Your destinations, traffic | Your real IP (only sees middle's IP) | The middle provider sees neither your identity nor your final destinations. It only knows the previous and next hop in the chain. This mirrors Tor's guard/relay/exit architecture, applied to commercial VPN providers with better performance characteristics. ## Multiple Accounts Per Provider Wirebump supports multiple accounts per provider. You can have: - Multiple Mullvad VPN accounts (different payment methods, different account numbers) - Multiple Proton VPN accounts - Any combination of the above This enables configurations where even "same provider" hops use genuinely separate accounts with no link between them. Pay for one account with cryptocurrency, another with a different payment method, and they are operationally independent. See [VPN Providers](https://wirebump.net/docs/vpn-providers) for account configuration details. ## Achieving Split Knowledge in Wirebump ### Step 1: Add Multiple Provider Accounts Go to Settings and add accounts for at least two providers (or two accounts from the same provider if you have genuinely separate accounts). ### Step 2: Configure a Nested Topology In the circuit builder, create a multi-layer circuit: - **Layer 0 (entry):** Provider A - **Layer 1 (exit):** Provider B Your traffic routes through Provider A first, then exits through Provider B. The "nested" topology ensures each layer only sees what it needs to. ### Step 3: Deploy Deploy the circuit. All LAN traffic now routes through the split-knowledge path. For detailed configuration steps: - [Nested VPNs](https://wirebump.net/docs/vpn-topologies/nested-vpns) - Two and three layer configurations - [Nested + Parallel](https://wirebump.net/docs/vpn-topologies/nested-parallel) - Combine split knowledge with load-balanced throughput ## What Split Knowledge Does Not Protect Against Split knowledge improves your privacy posture. It does not provide complete anonymity. ### Traffic Analysis Timing patterns can still reveal information. If you connect to Provider A at 3:14:23 PM and traffic exits Provider B at 3:14:24 PM, an adversary observing both points could correlate the timing. Mitigation: Mullvad VPN offers DAITA (Defense Against AI-guided Traffic Analysis) which adds traffic padding to obscure patterns. This trades throughput for additional protection. ### Endpoint Fingerprinting Your browser, operating system, and application behaviors can fingerprint you regardless of VPN configuration. ### Provider Collusion If both providers actively collaborate and share logs in real-time, they could reconstruct your activity. The defense is choosing providers in different jurisdictions with different ownership and no business relationship. ### Metadata Patterns Volume of traffic, connection timing, session duration. These reveal patterns even when content is encrypted. **Defense in Depth:** Split knowledge is one layer in a defense-in-depth strategy. It reduces what any single observer can learn. Combine it with good endpoint security, browser hardening, and operational awareness for stronger overall privacy. ## When Split Knowledge Matters | Scenario | Single VPN | Split Knowledge | |----------|------------|-----------------| | Hide browsing from ISP | Sufficient | Overkill | | General privacy improvement | Fine | Better, if you have concerns | | Distrust any single provider | Risky | Appropriate | | Legal/regulatory requirements | Check specifics | May be required | | High-stakes research or journalism | Insufficient | Strongly consider | | Adversary can compel one provider | Exposed | Protected (partial info only) | For most casual use, a single reputable VPN provider is fine. Split knowledge is for when your threat model includes the possibility that a VPN provider could be compromised, compelled, or untrustworthy. ## Summary | Key Point | Detail | |-----------|--------| | What is split knowledge? | No single entity sees both your identity and your traffic | | How do you achieve it? | Chain different VPN providers | | Same provider at both hops? | Defeats the purpose | | Different providers? | Different jurisdictions, different trust boundaries | | What remains exposed? | Timing correlations, traffic patterns, endpoint fingerprints | | When does it matter? | High-stakes scenarios where single-provider trust is insufficient | Split knowledge does not eliminate trust. It distributes it. The right configuration depends on your threat model, your risk tolerance, and how much latency you are willing to accept. --- Mullvad and Mullvad VPN are trademarks of Mullvad VPN AB. Proton VPN is a registered trademark of Proton AG.