🛡️ Zero-Knowledge Architecture

A security design where SafeMonk servers never see your encryption keys or plaintext secrets. Your data is encrypted in your browser before it ever leaves your device.

What is Zero-Knowledge Architecture?

Zero-knowledge architecture means that SafeMonk's servers have zero knowledge about your secrets. All encryption and decryption operations happen in your browser, ensuring that only you can access your plaintext data.

Core Principles

• Client-side encryption only
• Keys never leave your browser
• Server stores only encrypted data
• No plaintext ever transmitted
• Complete privacy by design

What This Means

Even if SafeMonk's entire database was compromised, attackers would only find encrypted gibberish that's useless without the encryption keys that never touched our servers.

Traditional vs Zero-Knowledge

❌ Traditional Approach

1. Send plaintext to server
2. Server encrypts data
3. Server stores encrypted data
4. Server has access to keys
5. Server can decrypt anytime

✅ SafeMonk Zero-Knowledge

1. Encrypt data in your browser
2. Send encrypted data to server
3. Server stores encrypted data
4. Keys never leave your browser
5. Server cannot decrypt ever

How Zero-Knowledge Works in SafeMonk

Secret Creation Flow

Your Browser

Generate encryption key
Encrypt your secret
Key stays in browser

→

SafeMonk Server

Receive encrypted data
Store encrypted blob
Cannot decrypt

→

Share Link

Link contains key
Or use passphrase
You control access

Secret Retrieval Flow

Recipient Browser

Click reveal link
Extract key from URL
Key never sent to server

→

SafeMonk Server

Return encrypted data
Delete if burn-after-read
Still cannot decrypt

→

Recipient Browser

Decrypt with key
Display plaintext
Only recipient sees secret

Security Guarantees

Server Cannot Access Your Data

SafeMonk's servers receive only encrypted data. Without the encryption keys (which never leave your browser), the server cannot decrypt or read your secrets.

✅Even SafeMonk employees cannot access your plaintext secrets

Database Breach Protection

If attackers compromise SafeMonk's database, they only get encrypted data that's useless without the keys. The keys exist only in browsers and shared links.

🛡️Stolen encrypted data is worthless without encryption keys

Government Requests

Even under legal compulsion, SafeMonk cannot provide plaintext data because we don't have access to encryption keys. We can only provide encrypted data.

⚖️Legal requests can only access encrypted (useless) data

Insider Threats

SafeMonk employees, contractors, or malicious insiders cannot access your data because the architecture makes it technically impossible.

👤Zero-knowledge protects against internal bad actors

Technical Implementation

Key Management

Link-with-Key Mode

Encryption key is embedded in the URL fragment (after #) and never sent to the server.

https://www.safemonk.com/n/abc123#key_here

Passphrase Mode

Key is derived from passphrase using PBKDF2. Only the salt is stored on the server.

key = PBKDF2(passphrase + salt, 210000 iterations)

Data Flow

↑

Upload

Browser → Encrypted Data → Server

↓

Download

Server → Encrypted Data → Browser

🔑

Keys

Always stay in browser memory

⚠️ Critical Point

The server never sees plaintext data or encryption keys at any point in the process. This is enforced by the client-side architecture.

Comparison with Other Approaches

Approach	Server Access	Breach Impact	Government Requests	Insider Threats
Zero-Knowledge (SafeMonk)	❌ No access	✅ Encrypted only	✅ Can't comply	✅ Protected
Server-Side Encryption	✅ Full access	❌ Full exposure	❌ Must comply	❌ Vulnerable
Transport Encryption Only	✅ Plaintext	❌ Full exposure	❌ Must comply	❌ Vulnerable
Client-Side with Server Keys	⚠️ Via keys	⚠️ Keys exposed	❌ Must comply	❌ Vulnerable