The three layers of GhostShield's security model
Most VPNs explain themselves as “encryption” or “privacy” — single-word answers to a question with three answers. GhostShield is built in three layers, and understanding them separately is the only way to understand what we actually protect against and what we do not.
Layer 1 — Transport: WireGuard + ChaCha20-Poly1305
All GhostShield traffic moves over the WireGuard protocol. WireGuard is a 4,000-line UDP-based VPN protocol designed by Jason Donenfeld, audited multiple times since its 2018 mainstream release, and merged into the Linux kernel in 2020. It is significantly smaller than OpenVPN (which is roughly 100,000 lines), which makes the attack surface auditable in days rather than months.
The cipher we use within WireGuard is ChaCha20-Poly1305 — an authenticated-encryption-with-associated-data (AEAD) construction. ChaCha20 is a stream cipher with a 256-bit key; Poly1305 is its message-authentication-code companion that detects tampering. The combination is faster than AES-GCM on mobile CPUs (no AES hardware instruction needed) and slightly slower on modern x86 servers (where AES-NI exists), which is the right tradeoff for a service whose users are 70%+ on mobile.
Key exchange uses Curve25519, the same elliptic curve used by Signal and the modern TLS stack. Forward secrecy is automatic — each session derives a fresh symmetric key.
Layer 2 — Infrastructure: RAM-only servers
Every GhostShield server runs from a remote-attested OS image loaded directly into a tmpfs RAM file system. There is no persistent block device mounted in the production data path. WireGuard runs from RAM, the network stack runs from RAM, the SSH-less management plane runs from RAM, and the access logs (such as they are) are written to RAM ring buffers that flush on reboot.
This matters because of what it means in adversarial scenarios. A subpoena delivered to a colo provider for “all data on the server” finds nothing, because nothing is on the server when the server is not running. A physical seizure of a powered-off server finds an OS image that contains no user data. The no-logs claim becomes provable rather than promised.
The remote attestation step is what prevents a malicious provider from booting our hardware into a different OS that does retain logs. The OS image is signed and the boot process verifies the signature against a hash that we publish on this site.
Layer 3 — Filter: AI threat detection
At the VPN exit, GhostShield runs a transformer-based packet classifier trained on labelled malware, phishing, intrusion, and command-and-control traffic. The classifier sees the traffic only as it leaves the tunnel to the public internet — it never sees the contents of HTTPS traffic, only the metadata (destination, packet size, timing pattern, DNS lookup).
When the classifier flags a destination as malicious with high confidence (current threshold: 92%), the connection is dropped before the response can reach the user's device. The user receives a notification in the app. Where the confidence is medium, the destination is logged to the user's session inbox (visible to the user only) for review.
The classifier model is updated weekly from continuously-collected threat intelligence and the false-positive rate is published in our quarterly transparency report. Current false-positive rate: 0.3% of dropped connections (i.e., 3 in every 1,000 dropped connections were actually benign).
What we explicitly do not do
- We do not decrypt or inspect the contents of HTTPS traffic. The AI classifier sees only metadata.
- We do not store the contents of any traffic, encrypted or unencrypted.
- We do not log which destinations a user visited. The AI classifier is stateless per packet and produces no per-user log.
- We do not run server-side ad blocking. Ad blocking happens client-side via DNS resolution to a curated blocklist; users can disable it.
- We do not run a tracker for “app analytics” or “crash reporting” in the VPN apps. Crash reports require user consent on first launch.
Protocol comparison
Why WireGuard rather than the alternatives:
- vs OpenVPN — WireGuard is ~25× smaller in code, significantly faster (typical 90% line speed vs 60-70% for OpenVPN), and uses modern crypto by default. OpenVPN's configuration surface allows many footgun choices; WireGuard's allows almost none.
- vs IKEv2/IPSec — IPSec is the protocol most often blocked in restrictive networks (it uses fixed UDP ports). WireGuard runs over UDP/51820 by default but is straightforward to relocate. IPSec has more failure modes around NAT traversal.
- vs L2TP/PPTP — These are deprecated. PPTP is broken; L2TP without IPSec is unencrypted. We do not offer either.
- vs proprietary protocols (NordVPN's NordLynx, ExpressVPN's Lightway, Mullvad's WireGuard-based stack) — most of these are WireGuard with custom plumbing. Our position is that vanilla WireGuard, audited and well-understood, beats proprietary modifications.
For a full comparison, see our WireGuard vs OpenVPN guide.
Kill switch behaviour
On Windows and Android, GhostShield installs a firewall rule on first connection that blocks all outbound traffic except via the WireGuard tunnel. When the VPN drops — either because the user disconnects, the network changes, or the upstream server becomes unreachable — the firewall continues to block until either the tunnel reconnects or the user explicitly disables it. There is no “briefly leak then notice” window.
On Windows, the rule is implemented via Windows Filtering Platform (WFP) callouts. On Android, it uses the VpnService's “allowed applications” allowlist plus a route that drops non-tunnel traffic to a sinkhole address.
DNS handling
GhostShield runs its own DNS resolvers in the same data centres as its VPN exits. Resolvers run on the same RAM-only infrastructure as the VPN servers. We do not log DNS queries. We do not sell DNS data. We support DNS-over-HTTPS for the small minority of users who want to bypass our resolvers entirely.
Post-quantum migration
ChaCha20 is not vulnerable to known quantum attacks (Grover's algorithm reduces brute-force time but does not break the cipher entirely). The key-exchange step (Curve25519) is theoretically breakable by a sufficiently large quantum computer, although no such computer exists today.
We will migrate to post-quantum key exchange (CRYSTALS-Kyber, currently being standardised by NIST as FIPS 203) once it is supported by the upstream WireGuard implementation in a way that maintains forward secrecy and audited interoperability. Target: 2027.
Verifying these claims
The strongest way to verify everything on this page is the audit programme on /audits. The next-strongest way is to read the third-party WireGuard and ChaCha20 audit literature directly:
- Formal Verification of WireGuard's Key Exchange — Donenfeld & Milner, 2018.
- A Cryptographic Analysis of the WireGuard Protocol — Dowling & Paterson, 2018.
- RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols.
FAQ
Why ChaCha20 rather than AES?
On mobile CPUs without AES hardware instructions, ChaCha20 is significantly faster (typically 3× on ARMv7 cores). On modern x86 servers, AES-GCM is faster — but in a VPN deployment the bottleneck is the client's CPU, not the server's. ChaCha20 is also a software-only cipher, which removes a class of side-channel risks tied to hardware AES instructions.
How can I verify the OS image running on a GhostShield server?
We publish the SHA-256 hashes of every production OS image on this site. The image is built from a public source repo. Anyone can clone the repo, rebuild the image, and confirm the hash matches what we run. The remote-attestation process during boot verifies the running image against this hash before WireGuard starts.
What happens if the AI threat detection makes a mistake?
Users can override blocked connections via the app. Where a domain is consistently mis-classified, users can email the classifier feedback address and the domain gets added to a manual allow-list within 48 hours. Our quarterly transparency report publishes the count of overrides and the false-positive rate for the period.
Why does not GhostShield publish a real-time bandwidth dashboard?
Real-time per-server bandwidth dashboards leak information about which user is on which server. We publish aggregated bandwidth and load monthly, but we do not publish per-second per-server data because doing so creates a fingerprinting risk.
Does GhostShield use third-party services that could see user traffic?
The VPN data path uses no third-party services. The website (this site) uses Google Tag Manager + GA4 for marketing analytics, and Ahrefs Analytics for SEO measurement. Neither sees VPN traffic; both see only website visits. The website analytics is documented on the privacy policy.