What is Zero-Knowledge Architecture?

TL;DR: In a zero-knowledge architecture, the system that knows your identity never sees your actions, and the system that sees your actions never knows your identity. No single part, except you/your device, not even the service provider, can link who you are to what you do.

The suggestion box

Imagine a college campus with a suggestion box in the student union. Any student can drop in a suggestion. The box itself has no cameras and no sign-in sheet. On the surface, it appears perfectly anonymous.

Your student ID lets you into the building, so the front desk knows who entered. The suggestion box only sees what was written. The front desk and the suggestion box never communicate. This separation captures the core idea of zero-knowledge: the system that checks your identity is fully separate from the system that handles your activity.

But what if someone wanted to find out?

This is where many so-called “anonymous” systems fail. Even if the suggestion box has no sign-in sheet, someone determined could:

• Timestamp correlation: Note what time a student swiped their ID at the front desk, then note when a new suggestion appeared. If a student enters at 2:14 PM and a suggestion is timestamped 2:16 PM, that’s a strong signal.
• Handwriting analysis: Cross-reference the suggestion’s handwriting with essays and assignments on file. The student never signed their name, but their writing style is a fingerprint.
• Entry and exit tracking: Security cameras, door logs, and Wi-Fi connection records allow the building to know exactly who was inside when each suggestion was dropped.
• Pattern analysis: Over time, correlating when certain students are in the building with when certain types of suggestions appear. The more data points, the stronger the link.
• Combined signals: By combining all of the above, someone could build a profile strong enough to link an anonymous suggestion to a specific student, even without a sign-in sheet for the suggestion box.

This breakdown isn’t unique to suggestion boxes. It also happens with most apps labeled as “anonymous” or “private.” While they may not request your name, they gather side-channel signals such as timestamps, device identifiers, IP addresses, and behavioral patterns that can be used to infer your identity. Essentially, the suggestion box analogy shows how infrastructure leaks can undermine true anonymity.

How zero-knowledge prevents this

A zero-knowledge system addresses every way your identity could be linked to your activity in the suggestion box analogy, mapping each risk directly to a specific technical approach.

In the analogy, timestamp correlation lets someone match a student’s entry time with the drop time of their suggestion. The zero-knowledge approach uses randomized timing: instead of sending data at once, the system delays and mixes submissions so suggestions can’t be easily linked to the time someone entered the building.

Handwriting analysis, in the context of the analogy, means identifying students based on their writing style. Likewise, in zero-knowledge architecture, on-device processing sanitizes submissions by removing potentially identifying details—much like erasing handwriting—so nothing personal leaves the device.

Entry and exit tracking in the analogy involves knowing exactly who was in the building and when. Zero-knowledge systems counter this by using an encrypted relay: just as you would hand your suggestion to someone who passes it along, the relay removes the origin (like your IP) before delivering it to the backend, preventing direct identity linkage.

With pattern analysis, the analogy shows how behavioral data over time could reveal connections between identities and activities. Zero-knowledge systems address this with identity-activity partitioning: the group that checks who you are is completely isolated from the group that handles what you do, so data cannot be joined, even if someone tried.

The result is that no single system, not even the service provider, can connect your identity to your activity.

The technical building blocks

Zero-knowledge architecture isn’t a single technology. It’s a design philosophy enforced through multiple complementary techniques:

On-device processing

The best privacy is data that stays on your device. Zero-knowledge aims to process information locally. Data leaves the device only when absolutely necessary, and even then, only with the protections below.

Oblivious HTTP (OHTTP)

Oblivious HTTP (RFC 9458 (opens in a new tab)) prevents servers from linking requests to users.

1. Your device encrypts each request so only the backend can read it. Intermediaries cannot access its content.
2. A third-party relay strips your IP address and forwards the encrypted request. It sees your IP, but not the content.
3. The backend decrypts and processes the request. It does not receive an IP address, device identifier, or user token, so it cannot identify you.

If this sounds familiar, it’s the same idea behind Tor. Tor uses three nodes: the first knows who you are, the last knows what you access, and the middle knows neither. OHTTP uses a similar separation for each request: the relay knows your IP but not the content; the backend knows the content but not your IP.

The relay and backend are separate entities—different companies and infrastructure. Neither alone can reconstruct the full picture.

Identity-activity partitioning

In traditional systems, one server handles both authentication (who you are) and functionality (what you do). This means a single system, with a single database, a single breach, or a single subpoena, can reveal everything.

Zero-knowledge partitions these concerns:

• The Identity Gateway manages authentication and subscription status. It knows your identity but does not track your activities.
• The Processing Backend handles service logic. It processes your actions but has no access to your identity.

These systems cannot link information, as they do not share databases, user IDs, logs, or identifying tokens. Each data set remains isolated and cannot be joined.

So how do users access their own data? Users access their data through their devices, which know both their identities and their activities. No server or third party holds this connection. A breach or subpoena can’t reconstruct the link between identity and activity.

This isn’t access control or segmentation—there’s no identity database or join key. The separation is enforced by architecture, not rules.

Data sanitization

Even with relays and partitioning, data itself can contain identifying information. An email address embedded in a URL. A phone number in a contact card. A name in a file path. A home address in a map link.

On-device processing scans for personal information and replaces it with placeholders before data leaves the device. The backend processes sanitized content, which can’t identify users.

Encrypted local storage

Zero-knowledge systems use encrypted local databases with keys held in secure hardware modules, separate from the main processor. This means:

• Data at rest is protected even if the device is stolen.
• The encryption key stays in secure hardware and can’t be extracted by malware.
• Data can be explicitly excluded from backups and device transfers to prevent it from being replicated to less secure locations.

What zero-knowledge is NOT

It’s not just about encryption. Encryption protects data in transit and at rest, but if the same server holds both the encrypted data and the key, that’s a policy decision, not an architectural one. Zero-knowledge means the provider never has the key. Even when data must be processed by a server, a true zero-knowledge architecture ensures it can never be linked back to a specific identity.

It’s not just anonymization. Taking your name out of a dataset doesn’t make it anonymous if the remaining details, like timestamps, location, device type, or behavioral patterns, can be combined to identify you. This has been demonstrated repeatedly (opens in a new tab). For example, researchers at Imperial College London found that 99.98% of Americans can be re-identified in any dataset using just 15 demographic attributes.

It’s not just a privacy policy. A privacy policy is a promise: “We won’t look at your data.” Zero-knowledge is a limitation: “We can’t look at your data.” Promises can be broken by rogue employees, company changes, or government orders. Architectural constraints cannot be broken.

It’s not zero-knowledge proofs. Even though they share a name, zero-knowledge architecture is different from zero-knowledge proofs (ZKPs) in cryptography. ZKPs are a mathematical way to prove knowledge without revealing information. Zero-knowledge architecture is a broader design approach for building systems in which the provider cannot structurally access user data. Some zero-knowledge architectures use ZKPs, but the two ideas are not the same.

Why this matters

Data breaches affect only data that already exists. If a service provider doesn’t have your data, it can’t be:

• Stolen by hackers: there’s nothing to steal.
• Subpoenaed by governments: there’s nothing to hand over.
• Sold to advertisers: there’s nothing to monetize.
• Leaked through misconfiguration: there’s nothing to expose.

In 2024 alone, over 1 billion records were stolen (opens in a new tab) in data breaches across healthcare, telecom, and financial services. Every one of those breaches exploited data that the companies didn’t need to retain but did anyway. Zero-knowledge architecture eliminates the risk category entirely.

The engineering cost

This approach is much harder to build. Significantly harder.

On-device processing means optimizing algorithms for mobile hardware with limited CPU, memory, and battery. Setting up identity-activity partitioning requires running a separate infrastructure with no shared state, which doubles the operational complexity. Using encrypted relays adds a dependency on third-party infrastructure for core functions. Data sanitization also requires PII detection that works locally and in real time, without slowing down the user experience.

Every feature must be designed so that no single system can see the whole picture. Error reporting is harder when you can’t include user context. Caching is harder when you can’t link requests to users. Debugging is harder when you can’t reproduce a specific user’s experience.

We accept these trade-offs because we believe privacy should be an engineering requirement, not just a marketing claim. The alternative, collecting data and promising to protect it, has failed billions of people. The breach statistics prove it every year.

How we’re applying this

Every product we build at Sanctum Labs follows these principles. On-device processing first. Identity-activity partitioning for anything that touches a server. Encrypted relays to prevent correlation. Data sanitization before anything leaves the device.

We don’t build products that just promise not to look at your data. We build products that make it impossible for us to do so.

To understand what this philosophy means in practice—what we collect, what we don’t, and why—read What We Stand For: Privacy as an Engineering Constraint.