How to design, build, and audit software systems where you literally have no user data to hand over — featuring real-world examples from the engineering behind WrapVPN.

In traditional software engineering, data is king. We are taught to capture logs, track session states, store user profiles, and record usage patterns to optimize performance, debug bugs, and build features.

But when you are engineering privacy-focused applications — like a VPN, secure messaging client, or password manager — the paradigm flips completely. Here, data is a liability.

The ultimate goal of privacy engineering is Zero-Knowledge Architecture (ZKA). A zero-knowledge system is designed so that the service provider has no way to access, decrypt, or log a user’s private data or activities. Even if a government agency issues a subpoena or a hacker breaches the production servers, there is simply nothing to retrieve.

Building a zero-knowledge system is not just about using HTTPS or writing a strict privacy policy. It requires a fundamental shift in how we design database schemas, handle authentication, and route application traffic.

At WrapVPN, this architecture is at the core of everything we build. Here is a breakdown of the core architectural patterns used to engineer zero-knowledge systems, and how we implement them in our clients and servers.

1. Decoupling Identity from Activity

In a standard web app, a single database row typically links a user’s billing information, email address, active sessions, and usage metrics together.

In a zero-knowledge architecture, we must enforce a strict cryptographic partition between Identity (who paid for the service) and Activity (what they are doing).

Figure 1: WrapVPN’s decoupled authentication flow. The Identity Service verifies the user’s billing/account status and issues a cryptographic blind token, allowing the VPN node to route traffic without accessing the user’s personal identity.

The WrapVPN Implementation: Blind Token Authentication

To separate who you are from what you do on our network, WrapVPN uses blind cryptographic token handshakes:

  1. Authentication: A user logs in to our identity system, which validates their subscription credentials securely via their App Store or Google Play receipt.
  2. Token Generation: Instead of generating a persistent session ID linked to an email, our identity service generates a short-lived, cryptographically signed token (containing only a tier validity flag and an expiration timestamp).
  3. Usage: When the WrapVPN app establishes a connection to a VPN node, it presents only this blind token. The VPN server verifies the signature using our public key. Because the token contains no user email, account ID, or billing details, the VPN node routes the user’s traffic completely anonymously.

2. Stateless Operations and Volatile Logging

A zero-knowledge system must avoid writing persistent logs. If a log file is written to a disk, it can be compromised.

How It’s Done at WrapVPN: RAM-Only Sessions

  • No Disk Logs: WrapVPN resource nodes are configured with logging levels completely muted, routing raw terminal outputs and connection handshakes directly to /dev/null at the system kernel level.
  • RAM-Only Sessions: Active session tables are kept strictly in volatile memory (tmpfs). The moment a user disconnects or a node restarts, the session traces disappear forever.
  • Aggregated Stats: If we need to monitor server capacity or latency, we collect only high-level aggregates (such as total network load on a specific region). Individual user IPs are never recorded alongside timestamps or data transfer metrics.

3. Client-Side Encryption (Zero-Knowledge Storage)

If your app must store user data (such as server configurations, bookmarks, or settings) in the cloud, you must ensure it is encrypted before it leaves the user’s device.

The WrapVPN Implementation: CryptoKit Backups

When WrapVPN back up custom user configurations or user preferences, the data is encrypted on-device before it is ever sent to our servers:

  1. Derive the Key Locally: We derive an encryption key from the user’s master credentials using a key derivation function (like Argon2 or standard key derivation functions) entirely on the client side.
  2. Local Encryption: The app encrypts the server lists or custom settings using symmetric encryption (AES-GCM-256 or ChaCha20-Poly1305 via Swift's native CryptoKit framework).
  3. Store the Ciphertext: Only this encrypted ciphertext is uploaded to our servers. Because we do not hold the derivation key, we host the bytes but cannot read the content inside them.
swift
// Example: How WrapVPN performs on-device AES-GCM encryption in Swift
import CryptoKit
func encryptDataLocally(plainText: String, keyDerivationSalt: Data) throws -> Data {
let password = "user-strong-password"
// Derive a symmetric key locally
let passwordData = password.data(using: .utf8)!
let derivedKey = SymmetricKey(size: .bits256) // In production, use Argon2 with the salt
// Encrypt locally
let plainData = plainText.data(using: .utf8)!
let sealedBox = try AES.GCM.seal(plainData, using: derivedKey)
return sealedBox.combined! // Safe to upload to backup servers
}

4. Ephemeral Cryptographic Handshakes

When transmitting data between a client and a server, relying solely on static keys is a vulnerability. If a static private key is ever leaked or stolen, a passive observer who recorded past encrypted traffic could retroactively decrypt everything.

To prevent this, zero-knowledge systems enforce Perfect Forward Secrecy (PFS).

How It’s Done at WrapVPN: The WireGuard Protocol

WrapVPN is built on top of the modern WireGuard® protocol. Every connection session begins with a dynamic Noise Protocol handshake (using Curve25519) to negotiate unique, ephemeral session keys.

These keys are renegotiated every few minutes. Once a session ends, the keys are completely destroyed from the device and server RAM. Even if a server’s primary key is compromised in the future, past traffic remains completely undecryptable because the session keys no longer exist.

The Engineering Mindset: Design for Audibility

Building a zero-knowledge architecture requires shifting your engineering KPIs. You are no longer measuring success by how much data you can capture and analyze. Instead, your success is measured by how little you know.

When designing a feature, the WrapVPN engineering team always asks:

  1. Can we build this without collecting this data point?
  2. If we must collect it, can it be hashed, blinded, or stored purely on the client’s local disk?
  3. If we must store it in the cloud, can we encrypt it so that we don’t hold the decryption key?

By design, zero-knowledge architectures are self-limiting. They require creative engineering to solve features like multi-device sync or abuse prevention. But the payoff is absolute: complete security for your users, and total peace of mind for your team.

Enjoyed this article? Follow the WrapVPN Engineering Publication for more deep dives into privacy-first software engineering, networking, and cryptography.

The Zero-Knowledge Architecture: Engineering Apps for Ultimate User Privacy was originally published in WrapVPN Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.