End-to-End Encryption Explained: How Konfidant Keeps Your Data Safe

You upload a confidential document. The service promises it's "encrypted." But here's the question most people never ask: who holds the keys?

If the company can decrypt your files — to scan them, to comply with a warrant, or because an employee goes rogue — then you're trusting them with your plaintext data. That's not end-to-end encryption. That's server-side encryption with extra steps.

True end-to-end encryption (E2EE) means only you and your intended recipient can read the data. The service provider, their employees, law enforcement, hackers — none of them can decrypt your files, even if they wanted to.

This guide explains how end-to-end encryption actually works, the difference between real E2EE and marketing claims, and how Konfidant implements zero-knowledge architecture to ensure your data stays yours.

What is End-to-End Encryption?

End-to-end encryption (E2EE) is a security model where data is encrypted on the sender's device and only decrypted on the recipient's device. No intermediary — not the server, not the company, not anyone — can read the plaintext.

The Core Principle

In E2EE systems:

1. Encryption happens client-side (in your browser or app)
2. The server stores only ciphertext (encrypted, unreadable data)
3. Decryption happens client-side (on the recipient's device)
4. The encryption keys never leave the endpoints (sender and recipient)

The service provider sees only scrambled data. Even with full access to their servers, they cannot decrypt your files.

End-to-End Encryption vs. Encryption in Transit

Many services claim encryption but only protect data in transit (HTTPS). Here's the difference:

Example:

• Dropbox, Google Drive: Encrypt in transit, but Google/Dropbox employees can access your files
• Signal, ProtonMail, Konfidant: End-to-end encrypted — the company cannot read your messages/files

HTTPS protects against eavesdropping during transmission. E2EE protects against everyone, including the service provider.

How End-to-End Encryption Works: The Technical Flow

Let's walk through how E2EE actually operates under the hood.

Step 1: Client-Side Encryption (Sender)

When you upload a file to an E2EE system:

1. Generate a Data Encryption Key (DEK) Your browser generates a random AES-256 key. This key is unique to this file and never reused.

DEK = randomBytes(32)  // 256-bit AES key

2. Encrypt the file The file is encrypted using AES-256-GCM (Advanced Encryption Standard, Galois/Counter Mode).

Ciphertext = AES-GCM-Encrypt(Plaintext, DEK)

The plaintext file never touches the network. Only the encrypted ciphertext is uploaded.

3. Wrap the encryption key The DEK itself is encrypted using a Key Encryption Key (KEK). In zero-knowledge systems, this KEK is derived from:

• A randomly generated token (stored in the share link)
• Server-side secrets the user never sees

WrappedDEK = Encrypt(DEK, KEK)

4. Upload ciphertext and wrapped key The system uploads:

• The encrypted file (ciphertext)
• The wrapped DEK (encrypted key)

The server stores both but can decrypt neither. It lacks the KEK to unwrap the DEK.

Step 2: Secure Link Generation

You receive a URL like:

https://share.konfidant.app/d/abc123xyz456...

This link contains:

• A unique token that encodes or references the KEK
• Metadata (expiration time, access controls)

Critical security property: The link is the only way to decrypt the file. Lose the link = lose access to the data forever.

Step 3: Client-Side Decryption (Recipient)

When the recipient opens the link:

1. Extract the KEK from the token The browser parses the URL token to derive the KEK.

2. Fetch the ciphertext and wrapped DEK The browser requests the encrypted file and wrapped DEK from the server.

3. Unwrap the DEK Using the KEK from the token, the browser decrypts the wrapped DEK:

DEK = Decrypt(WrappedDEK, KEK)

4. Decrypt the file The browser decrypts the ciphertext using the DEK:

Plaintext = AES-GCM-Decrypt(Ciphertext, DEK)

5. Display or download The decrypted file is shown to the user or downloaded. The plaintext never touches the server.

What the Server Sees

At every point, the server only sees:

• Encrypted ciphertext (unreadable binary)
• Wrapped DEK (encrypted key material)
• Metadata (file size, upload timestamp, expiration time)

The server cannot:

• Decrypt the file (lacks the KEK)
• Read the plaintext (never transmitted)
• Unwrap the DEK (would need the KEK from the URL token)

This is zero-knowledge architecture: the server has zero knowledge of your plaintext data.

Zero-Knowledge Architecture: What It Means for Security

Zero-knowledge encryption takes E2EE one step further: the service provider cannot access your data even if compelled.

The Trust Model

Traditional cloud storage:

"We promise not to look at your files."

Zero-knowledge systems:

"We can't look at your files, even if we wanted to."

This shifts the security model from trust-based to cryptographically enforced.

Protection Against Insider Threats

Scenario: A rogue employee at the service provider tries to access customer files.

Traditional encryption (server-side keys):

• Employee uses admin access to decrypt files
• No technical barrier, only policy/auditing

Zero-knowledge E2EE:

• Employee sees only ciphertext
• Keys stored client-side or split across endpoints
• No admin access can decrypt files

Protection Against Government Requests

Scenario: Law enforcement requests access to a user's files.

Traditional encryption:

• Company decrypts and hands over plaintext
• Gag orders may prevent user notification

Zero-knowledge E2EE:

• Company has only ciphertext (useless without keys)
• Even court orders cannot compel decryption of data the company cannot access

Legal precedent: ProtonMail, Signal, and other zero-knowledge services have successfully argued they cannot comply with decryption requests because they technically cannot decrypt user data.

Protection Against Server Breaches

Scenario: Hackers breach the server and steal the database.

Traditional encryption:

• Attackers steal ciphertext + keys
• Decryption is trivial if keys are stored server-side

Zero-knowledge E2EE:

• Attackers steal ciphertext + wrapped keys
• Without the KEK (embedded in share links), decryption is impossible

How Konfidant Implements End-to-End Encryption

Konfidant's security architecture is built on zero-knowledge E2EE. Here's how we protect your files:

1. Client-Side Encryption Before Upload

When you upload a file to Konfidant:

Your browser:

• Generates a random AES-256 key
• Encrypts the file locally (JavaScript Web Crypto API)
• Uploads only the ciphertext

Our server:

• Receives encrypted data
• Stores it in encrypted cloud storage (R2)
• Never sees the plaintext

No one at Konfidant — no engineer, no admin, no support staff — can read your files.

2. Encryption Keys in the Share Link

The encryption key is embedded in the share URL fragment:

https://share.konfidant.app/d/token#keyMaterial

The #keyMaterial portion is the URL fragment. Critically:

• Fragments are never sent to the server (browser-only)
• The server sees only the token, not the key material
• Even server logs cannot capture the decryption key

This design ensures true zero-knowledge: we never have access to the keys.

3. Burn-on-Read Deletion

After the recipient downloads the file:

• The ciphertext is deleted from storage
• The token is invalidated
• The link becomes permanently inaccessible

Even if someone later obtains the share link, there's nothing left to decrypt.

4. No Metadata Leakage

We minimize metadata collection:

• File names are not stored server-side (encrypted as part of the file)
• Upload timestamps are not tied to user identity (anonymous shares)
• Access logs are optional (disabled by default for non-verified-burn shares)

The less metadata we collect, the less we can be compelled to hand over.

5. Open-Source Cryptography

We use industry-standard, peer-reviewed encryption algorithms:

• AES-256-GCM: Symmetric encryption (NIST-approved, used by Signal, WhatsApp)
• Web Crypto API: Browser-native cryptography (audited by browser vendors)

No proprietary crypto, no security through obscurity. Our approach is transparent and auditable.

Common End-to-End Encryption Misconceptions

Myth 1: "Encrypted" Means End-to-End Encrypted

Reality: Many services encrypt data at rest (on disk) and in transit (HTTPS) but hold the decryption keys server-side.

Examples:

• Dropbox: Encrypts files at rest, but Dropbox employees can access them
• Google Drive: Encrypted, but Google scans files for policy violations

Look for "client-side encryption" or "zero-knowledge" in the security documentation.

Myth 2: End-to-End Encryption Prevents Screenshots

Reality: E2EE protects data in transit and at rest. It cannot prevent the recipient from:

• Taking screenshots
• Copying text
• Saving the file locally

E2EE ensures controlled delivery, not digital rights management (DRM).

Myth 3: The Company Can Recover Your Encrypted Data

Reality: In zero-knowledge E2EE systems, password recovery is impossible without key escrow.

True zero-knowledge:

• Lose your password/link = lose your data permanently
• The company cannot reset or recover access

Key escrow (optional in some systems):

• Backup keys stored encrypted with a recovery key
• Weakens zero-knowledge guarantees but allows recovery

Konfidant uses ephemeral sharing, so recovery isn't relevant — files self-destruct after delivery.

Myth 4: End-to-End Encryption is Slow

Reality: Modern AES-256 encryption is hardware-accelerated on all major platforms.

Performance:

• Encryption/decryption happens at gigabytes per second on modern CPUs
• Client-side encryption adds milliseconds to upload/download times

The bottleneck is network bandwidth, not encryption.

Evaluating End-to-End Encryption Claims

When a service claims E2EE, verify these properties:

1. Where Does Encryption Happen?

Red flags:

• "Data is encrypted before storage" (could be server-side)
• "We use HTTPS/TLS" (only encrypts transmission)
• "Bank-level encryption" (marketing term, meaningless)

Green flags:

• "Client-side encryption" or "browser-based encryption"
• "Zero-knowledge architecture"
• "We cannot access your plaintext data"

2. Who Holds the Keys?

Red flags:

• No mention of key management
• "Encrypted with your password" (could be server-side key derivation)
• Password reset via email (implies server-side keys)

Green flags:

• "Encryption keys never leave your device"
• "Keys embedded in share links"
• "Zero-knowledge key management"

3. Can the Company Access Your Data?

Red flags:

• "Encrypted for privacy" (vague)
• No mention of employee access controls
• Privacy policy allows data access for unspecified purposes

Green flags:

• "We cannot access your files"
• "Zero-knowledge: we don't have your keys"
• Audited security whitepaper

4. Is the Encryption Auditable?

Red flags:

• Proprietary encryption algorithm
• No security whitepaper or documentation
• "Military-grade encryption" (marketing fluff)

Green flags:

• Uses standard algorithms (AES-256, ChaCha20)
• Open-source client code
• Third-party security audits

End-to-End Encryption for Different Use Cases

File Sharing: Konfidant, Tresorit, Sync.com

Use case: Send confidential files with E2EE.

What to look for:

• Client-side encryption before upload
• Share links with embedded keys
• Automatic expiration (ephemeral sharing)

Konfidant's approach:

• Zero-knowledge E2EE
• Burn-on-read deletion
• No file metadata stored server-side

Messaging: Signal, WhatsApp, iMessage

Use case: Private conversations with E2EE.

What to look for:

• End-to-end encrypted by default
• Forward secrecy (keys rotate per session)
• No message backups on servers

Note: iMessage is E2EE, but iCloud backups are not — Apple can access iCloud data.

Email: ProtonMail, Tutanota

Use case: Encrypted email.

What to look for:

• Zero-knowledge email storage
• PGP or similar encryption
• Metadata protection (subject lines, sender/recipient)

Limitation: E2EE only works for emails between users on the same platform (ProtonMail to ProtonMail). Emails to Gmail are encrypted in transit but readable by Google.

Cloud Storage: Tresorit, MEGA, Sync.com

Use case: Long-term file storage with E2EE.

What to look for:

• Client-side encryption before sync
• Zero-knowledge architecture
• Key management (password-based or key files)

Trade-off: E2EE cloud storage is slower than Dropbox/Google Drive because encryption happens client-side.

The Limits of End-to-End Encryption

E2EE is powerful but not a silver bullet. It cannot protect against:

1. Compromised Endpoints

If the sender's or recipient's device is compromised (malware, keylogger), E2EE is useless. The attacker can steal the plaintext before encryption or after decryption.

Mitigation: Keep devices updated, use antivirus, avoid phishing links.

2. Malicious Code Injection

If the service provider serves malicious JavaScript to your browser, they can steal keys before encryption.

Mitigation: Use browser extensions, verify code signatures, or use native apps (harder to update maliciously).

3. User Error

If you share the decryption link publicly or with the wrong person, E2EE doesn't help. The link is the key.

Mitigation: Use passphrases, SMS verification, or expiration policies.

4. Metadata Analysis

E2EE encrypts content, not metadata. Even zero-knowledge systems may reveal:

• When a file was uploaded
• File size
• Sender and recipient IP addresses (in logs)

Mitigation: Use ephemeral sharing (auto-delete), disable audit logs, or use Tor/VPN.

Why Zero-Knowledge E2EE Matters for Konfidant

At Konfidant, we built our platform on a simple principle: we don't want access to your data.

Not because we don't trust ourselves, but because:

• You shouldn't have to trust us
• We can't leak what we don't have
• We can't be compelled to hand over what we can't decrypt

Zero-knowledge E2EE ensures that even if:

• Our servers are breached
• An employee goes rogue
• We receive a government request

…your data remains encrypted. We store only ciphertext, and the keys live in the share links you control.

This is the foundation of secure ephemeral file sharing: client-side encryption, zero-knowledge architecture, and burn-on-read deletion.

Frequently Asked Questions

How is E2EE different from HTTPS?

HTTPS encrypts data in transit (between you and the server). The server can still decrypt and read your data.

E2EE encrypts data end-to-end (from sender to recipient). The server never sees plaintext.

Can Konfidant employees read my files?

No. Files are encrypted client-side before upload. We store only ciphertext, and the decryption keys are embedded in share links (which we never see).

What if I lose the share link?

In zero-knowledge systems, the link is the key. If you lose it, the data is permanently inaccessible — even to us.

For critical files, save the link securely (password manager, encrypted notes).

Is AES-256 encryption secure?

Yes. AES-256 is the industry standard for symmetric encryption, used by:

• The U.S. government (classified data)
• Signal, WhatsApp (E2EE messaging)
• Banks and financial institutions

There are no known practical attacks against AES-256.

Can quantum computers break E2EE?

Short answer: Not yet.

Long answer: Quantum computers threaten asymmetric encryption (RSA, ECC) but not symmetric encryption (AES-256). AES-256 remains secure against quantum attacks.

Future-proofing: post-quantum cryptography standards (NIST, 2024) address this.

Does E2EE protect against phishing?

No. If you're tricked into entering your password or share link on a fake site, E2EE can't help. Always verify URLs before entering credentials.

The Bottom Line

End-to-end encryption is the difference between trusting a promise and enforcing a guarantee.

When a service says "we encrypt your data," ask:

• Who holds the keys?
• Can employees access my plaintext?
• Is encryption client-side or server-side?

True E2EE means:

• Keys stay on your device
• The server sees only ciphertext
• No one — not even the company — can decrypt your files

At Konfidant, zero-knowledge E2EE is non-negotiable. We built a system where we can't access your data, even if we wanted to. Because the best way to protect your secrets is to never have them in the first place.

---

Ready to share files with zero-knowledge security? Try Konfidant's E2EE file sharing →