Provider-Side Data Absence (PSDA)
An Optional Property Beyond ZKS Requirements
Version: 1.0 Status: Position Paper Audience: Security Architects, CISOs, Compliance Officers
Executive Summary
Provider-Side Data Absence (PSDA) is an architectural property where service providers never store user ciphertext on their infrastructure. PSDA is not required for ZKS compliance but provides additional security benefits for implementations that achieve it.
| Property | ZKS Requirement | Security Benefit |
|---|---|---|
| Provider cannot decrypt | Required | Protects confidentiality |
| Provider never holds ciphertext | Optional (PSDA) | Eliminates data exposure entirely |
Key insight: ZKS ensures providers cannot decrypt. PSDA ensures providers never possess the encrypted data in the first place.
Definitions
Zero-Knowledge Sovereignty (ZKS)
ZKS requires that providers cannot reconstruct decryptability:
"No provider may control the components necessary to reconstruct decryptability - now or in the future."
A ZKS-compliant system may store ciphertext on provider infrastructure, provided the provider never controls key components.
Provider-Side Data Absence (PSDA)
PSDA requires that providers never store user ciphertext:
"No provider-operated service stores user ciphertext at rest. User data exists only on user-controlled endpoints and user-controlled storage substrates."
A PSDA-compliant system ensures ciphertext never resides on provider infrastructure.
The Orthogonal Relationship
ZKS and PSDA answer different questions:
| Property | Question | ZKS-Only System | ZKS + PSDA System |
|---|---|---|---|
| ZKS | "Who can ever decrypt?" | Only the user | Only the user |
| PSDA | "Who ever possesses the encrypted data?" | Provider holds ciphertext | Only user-controlled systems |
These properties are orthogonal - each can be achieved independently:
Why PSDA Matters
Threat Scenarios: ZKS-Only vs. ZKS + PSDA
| Threat | ZKS-Only Response | ZKS + PSDA Response |
|---|---|---|
| Subpoena for user data | Provider produces ciphertext (encrypted, but exposed) | Provider has nothing to produce |
| Provider infrastructure breach | Attacker exfiltrates ciphertext | No user data to exfiltrate |
| Insider threat | Insider can access ciphertext | No user data for insider to access |
| Long-term cryptographic risk | Ciphertext available for future attacks | No ciphertext accumulation |
| Data retention demands | Provider must retain ciphertext per regulation | Nothing to retain |
| Jurisdiction conflicts | Ciphertext subject to storage location laws | No data residency concerns |
The "Harvest Now, Decrypt Later" Problem
ZKS-Only:
Adversary strategy:
1. Breach provider infrastructure
2. Exfiltrate all ciphertext
3. Wait for cryptographic advances
4. Decrypt in the future
Provider status: ZKS-compliant (cannot decrypt today)
Adversary status: Patient (may decrypt tomorrow)
User risk: Non-zero (ciphertext exposed)
ZKS + PSDA:
Adversary strategy:
1. Breach provider infrastructure
2. Find no ciphertext to exfiltrate
3. No "harvest" possible
Provider status: ZKS-compliant + PSDA-compliant
Adversary status: Unable to harvest
User risk: Zero (no ciphertext on provider)
PSDA Architecture
Data Flow: ZKS-Only (Common Pattern)
Data Flow: ZKS + PSDA
PSDA Criteria
A system satisfies PSDA if and only if:
Criterion 1: No Ciphertext at Rest
No service operated by the provider stores user ciphertext at rest.
| Compliant | Non-Compliant |
|---|---|
| Provider stores only metadata | Provider stores encrypted files |
| Provider stores only wrapped keys | Provider stores encrypted messages |
| Provider stores only coordination data | Provider stores encrypted database |
Criterion 2: No Ciphertext Caching
No service operated by the provider caches user ciphertext beyond immediate delivery.
| Compliant | Non-Compliant |
|---|---|
| Fire-and-forget message relay | Message queue with persistence |
| Stateless data relay | CDN caching of ciphertext |
| Ephemeral transport only | Temporary storage for delivery |
Criterion 3: User-Controlled Data Flow
User ciphertext flows only between user-controlled endpoints and user-controlled storage.
| Compliant | Non-Compliant |
|---|---|
| Device-to-device P2P | Device-to-server-to-device |
| Device-to-user's-cloud-storage | Device-to-provider-storage |
| Relay without inspection or storage | Store-and-forward with persistence |
Criterion 4: Provider Role Limited to Coordination
The provider's role is limited to coordination, key delivery, and transport facilitation - not data storage.
| Provider May Do | Provider May Not Do |
|---|---|
| Route messages (ephemeral) | Store messages |
| Deliver wrapped keys (TTL) | Store ciphertext |
| Coordinate sync events | Cache user data |
| Facilitate P2P connections | Persist user content |
Benefits of PSDA
Legal Benefits
| Scenario | ZKS-Only Position | ZKS + PSDA Position |
|---|---|---|
| Subpoena for data | "Here's ciphertext; we can't decrypt" | "We have no user data" |
| Data preservation order | Must preserve ciphertext | Nothing to preserve |
| Discovery request | Produce ciphertext | Produce nothing |
| Data residency compliance | Must ensure ciphertext location | No data location concerns |
Operational Benefits
| Aspect | ZKS-Only | ZKS + PSDA |
|---|---|---|
| Storage costs | Provider bears storage costs | User bears storage costs |
| Scaling | Provider scales storage | User storage scales naturally |
| Backup responsibility | Provider must backup ciphertext | User controls backups |
| Data lifecycle | Provider manages retention | User manages retention |
Security Benefits
| Threat | ZKS-Only Exposure | ZKS + PSDA Exposure |
|---|---|---|
| Breach | Ciphertext exfiltrated | Nothing to exfiltrate |
| Insider | Ciphertext accessible | No data to access |
| Future crypto breaks | Historical ciphertext vulnerable | No historical ciphertext |
| Metadata correlation | Storage patterns visible | No storage patterns |
Implementation Patterns
Pattern 1: Peer-to-Peer with Coordination
Provider role: Signaling, presence, key delivery
Data flow: Direct between user devices
Storage: None on provider
Example: Briar, P2P messaging systems
Pattern 2: User-Controlled Storage Substrate
Provider role: API layer to user's cloud storage
Data flow: User device → User's cloud account
Storage: User's cloud storage (not provider's)
Example: Apps using user's Dropbox/OneDrive/GDrive accounts
Pattern 3: Relay Without Persistence
Provider role: Message relay (fire-and-forget)
Data flow: Through provider but not stored
Storage: Ephemeral only (seconds, not retained)
Example: TURN relays, fire-and-forget messaging
PSDA and ZKS Profiles
PSDA is not required for any ZKS profile, but it can be documented as an additional property:
| Profile | ZKS Requirements | PSDA |
|---|---|---|
| ZKS-Core | A1–A8, common invariants | Optional |
| ZKS-Enhanced | ZKS-Core + metadata + transparency | Optional |
| ZKS-Enterprise | ZKS-Enhanced + delegation + split | Optional |
| ZKS-Core + PSDA | ZKS-Core + no provider ciphertext | Documented |
Documenting PSDA
In compliance assessments, PSDA can be documented as:
## Additional Properties
### Provider-Side Data Absence (PSDA)
This implementation satisfies PSDA criteria:
1. No ciphertext at rest on provider infrastructure
2. No ciphertext caching beyond immediate delivery
3. User data flows only to user-controlled storage
4. Provider role limited to coordination
Provider-operated services handle:
- [Key delivery service] - wrapped keys only, TTL-based
- [Coordination service] - metadata only
- [Relay service] - fire-and-forget, no persistence
Provider-operated services never store:
- User ciphertext
- User plaintext
- User files or content
Limitations
PSDA Does Not Eliminate All Metadata
Even with PSDA, providers may see:
- Connection metadata (who connects when)
- Sync patterns (when users are active)
- Key delivery events (when keys are exchanged)
- Message relay timing (when messages flow)
PSDA eliminates data exposure, not metadata exposure. A7 (Metadata Minimization) addresses metadata separately.
PSDA Requires User-Controlled Storage
PSDA shifts storage responsibility to users. This requires:
- Users have cloud storage accounts or other user-controlled storage
- Users manage storage capacity
- Users handle backup and redundancy
This may not suit all use cases or users.
PSDA May Increase Complexity
P2P architectures and user-controlled storage introduce complexity:
- NAT traversal (TURN/STUN)
- Offline delivery challenges
- Sync conflict resolution
- User storage management
ZKS-only architectures with provider ciphertext storage may be simpler to implement.
Case Study: QuodArca
QuodArca is a ZKS-conformant system that also satisfies PSDA:
Architecture
| Component | Function | Data Stored |
|---|---|---|
| QKEYS | Key delivery | Wrapped keys (TTL ≤ 1 week) |
| QBEND | Sync coordination | Device/item UUIDs |
| QMSVC | Message relay | None (fire-and-forget) |
| QP2P | P2P transport | None (relay only) |
| CLinks | User storage | Ciphertext (user's accounts) |
PSDA Verification
| Criterion | QuodArca Implementation |
|---|---|
| No ciphertext at rest | Ciphertext only on CLinks (user-controlled) |
| No ciphertext caching | QMSVC is fire-and-forget |
| User-controlled data flow | Device → CLink → Device |
| Provider role limited | Coordination only |
Security Properties
| Property | Status |
|---|---|
| ZKS-Core | ✅ Conforms |
| PSDA | Satisfied |
Result: QuodArca combines ZKS compliance with PSDA, achieving both decryptability control and data absence.
Conclusion
Provider-Side Data Absence (PSDA) is an optional property that provides security benefits beyond ZKS:
| Benefit | ZKS | PSDA |
|---|---|---|
| Provider cannot decrypt | ✅ | ✅ |
| Provider cannot be compelled to produce ciphertext | Policy-dependent | ✅ (nothing to produce) |
| No "harvest now, decrypt later" risk | Ciphertext exposed | No ciphertext to harvest |
| No data residency concerns | Ciphertext location matters | No data on provider |
For maximum security: Implement both ZKS (decryptability control) and PSDA (data absence).
For ZKS compliance: PSDA is not required, but its presence can be documented as an additional security property.
References
- ZKS-1.0: Zero-Knowledge Sovereignty Standard
- QuodArca ZKS Compliance Assessment
- "Data Minimization in Security Architecture" (forthcoming)