What "we can't read your data" actually means
When a service says "end-to-end encrypted," they're making a specific architectural claim: the server that stores and transmits the data cannot decrypt it. The plaintext exists only on the sender's device and the recipient's device. The server sees ciphertext — noise — and has no key that can turn it back into meaningful data.
When a service says "zero-knowledge," they're going further: the server not only can't read your data, it doesn't know what it is. It can't infer content from metadata. It can't search through your data. It can't respond to a subpoena with your plaintext because it doesn't have it — not "won't give it up," literally doesn't possess the capability to produce it.
These are strong claims. They require specific cryptographic architectures that fundamentally change how your app works. You can't bolt E2E encryption onto a traditional client-server app — it reshapes the entire data flow.
This post walks through both architectures in the context of Flutter mobile apps: what they require, how to implement them, what you gain, and what you give up.
The trust model shift
In a traditional app, the trust model is simple:
User → (TLS) → Server → (TLS) → Other User
↑
Server has plaintext
Server enforces access control
Server can search, index, processThe server is a trusted intermediary. It sees everything. Your security depends on the server being well-defended and the operators being trustworthy.
In an E2E encrypted app, the trust model changes:
User → (TLS) → Server → (TLS) → Other User
↑ ↑
Encrypts with Decrypts with
recipient's public key their private key
↑
Server has ciphertext only
Server routes but cannot read
Server cannot search or index contentThe server is an untrusted relay. Even if the server is compromised — by an attacker, by a rogue employee, by a government order — the data remains encrypted. The keys never leave the users' devices.
This is a fundamental architectural decision, not a feature flag. It affects every part of your app that touches user data.
Symmetric vs asymmetric: when each one applies
The Dart FFI libsodium post covered symmetric encryption — one key, used for both encryption and decryption. That works when the same entity encrypts and decrypts (encrypting local storage, encrypting data before backup).
E2E encryption between two parties requires asymmetric encryption — or more precisely, a key exchange protocol that establishes a shared symmetric key between two parties who've never communicated before.
Here's the fundamental problem: Alice wants to send Bob an encrypted message. They've never met. They can't exchange a key in person. The only channel between them is the server — which we don't trust. How do they agree on a shared secret?
The answer: Diffie-Hellman key exchange, specifically its modern elliptic-curve variant, X25519.
X25519 key exchange: establishing a shared secret
Each user generates a key pair: a private key (kept on device, never transmitted) and a public key (shared freely, published to the server).
// Conceptual key generation — using libsodium bindings
// (See the Dart FFI series for how to set up libsodium in Flutter)
class KeyPair {
final Uint8List publicKey; // 32 bytes — shared with anyone
final Uint8List privateKey; // 32 bytes — NEVER leaves this device
KeyPair({required this.publicKey, required this.privateKey});
}
class CryptoService {
/// Generate a new X25519 key pair.
/// The private key stays on this device forever.
/// The public key is uploaded to the server.
KeyPair generateKeyPair() {
return using((arena) {
final pk = arena<Uint8>(32);
final sk = arena<Uint8>(32);
_sodium.crypto_box_keypair(pk, sk);
return KeyPair(
publicKey: Uint8List.fromList(pk.asTypedList(32)),
privateKey: Uint8List.fromList(sk.asTypedList(32)),
);
});
}
/// Compute a shared secret from our private key and their public key.
/// Alice computes: shared = X25519(alice_private, bob_public)
/// Bob computes: shared = X25519(bob_private, alice_public)
/// Both get the SAME shared secret — without ever transmitting it.
Uint8List computeSharedSecret(Uint8List ourPrivateKey, Uint8List theirPublicKey) {
return using((arena) {
final shared = arena<Uint8>(32);
final sk = arena<Uint8>(32);
final pk = arena<Uint8>(32);
sk.asTypedList(32).setAll(0, ourPrivateKey);
pk.asTypedList(32).setAll(0, theirPublicKey);
final result = _sodium.crypto_scalarmult(shared, sk, pk);
if (result != 0) {
throw CryptoException('Key exchange failed');
}
return Uint8List.fromList(shared.asTypedList(32));
});
}
}The math behind X25519 is elegant: both parties perform the same operation with their own private key and the other's public key, and arrive at the same shared secret. An attacker who knows both public keys but neither private key cannot compute the shared secret — this is the discrete logarithm problem on elliptic curves, which has no known efficient solution.
Once both parties have the shared secret, they use it as a symmetric key for crypto_secretbox (the authenticated encryption from the FFI series). The expensive asymmetric operation happens once; all subsequent messages use fast symmetric encryption.
The message flow: from plaintext to delivered ciphertext
Here's how an E2E encrypted message actually flows through the system:
Alice's device:
1. Compose message: "Meeting at 3pm"
2. Look up Bob's public key (from server or local cache)
3. Compute shared secret: X25519(alice_private, bob_public)
4. Derive message key from shared secret + message nonce (HKDF)
5. Encrypt: SecretBox.encrypt(plaintext, derived_key, nonce)
6. Send to server: { recipient: "bob", ciphertext: "...", nonce: "..." }
Server:
7. Store ciphertext envelope
8. Deliver to Bob when online
(Server CANNOT decrypt — it has neither private key)
Bob's device:
9. Receive: { sender: "alice", ciphertext: "...", nonce: "..." }
10. Look up Alice's public key
11. Compute shared secret: X25519(bob_private, alice_public)
12. Derive same message key from shared secret + message nonce
13. Decrypt: SecretBox.decrypt(ciphertext, derived_key, nonce)
14. Display: "Meeting at 3pm"Step 4 is important — you don't use the raw shared secret directly as an encryption key. You derive a unique key for each message using a Key Derivation Function (HKDF). This provides key separation: even if one message's key is compromised, it doesn't reveal the key for other messages.
/// Derive a per-message encryption key from the shared secret.
/// Uses HKDF (HMAC-based Key Derivation Function) to produce
/// a unique key for each message.
Uint8List deriveMessageKey(Uint8List sharedSecret, Uint8List messageNonce) {
return using((arena) {
// libsodium's crypto_kdf_derive_from_key provides HKDF-like derivation
final subkey = arena<Uint8>(32);
final key = arena<Uint8>(32);
final ctx = arena<Uint8>(8); // 8-byte context string
key.asTypedList(32).setAll(0, sharedSecret);
// Use the nonce as the subkey ID — each message gets a unique derived key
// Context distinguishes this key derivation from others in the app
final contextBytes = utf8.encode('msg_enc\0'); // exactly 8 bytes
ctx.asTypedList(8).setAll(0, contextBytes);
// subkey_id derived from nonce ensures unique key per message
final subkeyId = _nonceToSubkeyId(messageNonce);
_sodium.crypto_kdf_derive_from_key(subkey, 32, subkeyId, ctx, key);
return Uint8List.fromList(subkey.asTypedList(32));
});
}Forward secrecy: protecting past messages
The basic X25519 scheme has a vulnerability: if Alice's long-term private key is ever compromised (her device is seized, the key is extracted from storage), an attacker who recorded past ciphertext can compute the shared secret and decrypt every historical message.
Forward secrecy (also called perfect forward secrecy) solves this by using ephemeral keys — temporary key pairs generated for each session or even each message, then deleted.
The Signal Protocol, used by Signal, WhatsApp, and Facebook Messenger's encrypted mode, implements forward secrecy through the Double Ratchet Algorithm:
Alice and Bob's conversation:
Message 1: Alice → Bob
Key: derived from (alice_ephemeral_1, bob_signed_prekey)
After sending: Alice deletes alice_ephemeral_1's private key
Message 2: Bob → Alice
Key: derived from (bob_ephemeral_1, alice_signed_prekey)
After sending: Bob deletes bob_ephemeral_1's private key
Message 3: Alice → Bob
Key: derived from (alice_ephemeral_2, bob_ephemeral_1's public)
After sending: Alice deletes alice_ephemeral_2's private key
... each message uses a fresh ephemeral key pairThe "ratchet" means the key material moves forward with each message exchange. Once a key is used and deleted, there's no way to go back. Even if an attacker compromises a device today, messages from last week used keys that no longer exist.
Implementing the full Double Ratchet from scratch is a significant engineering effort and a security risk — the protocol has subtle edge cases around out-of-order message delivery, lost messages, and multi-device synchronization. For production use, there are two pragmatic approaches:
Option 1: Use a vetted library. libsignal-protocol-dart wraps the Signal Protocol's reference implementation. It handles the ratchet state machine, prekey management, and session negotiation. You provide storage and transport.
Option 2: Simplified forward secrecy. If you don't need per-message forward secrecy (the full Signal Protocol), you can implement per-session forward secrecy — generate ephemeral keys per session, delete them when the session ends. This is simpler and appropriate for apps where "session" is a meaningful unit (e.g., a video call, a temporary chat room).
/// Simplified per-session forward secrecy.
/// Each session generates ephemeral keys. When the session ends,
/// the keys are deleted and past messages become undecryptable.
class EphemeralSession {
final KeyPair _ephemeralKeys;
final Uint8List _sessionKey;
int _messageCounter = 0;
EphemeralSession._({
required KeyPair ephemeralKeys,
required Uint8List sessionKey,
}) : _ephemeralKeys = ephemeralKeys,
_sessionKey = sessionKey;
/// Create a new session with a peer.
/// Generates ephemeral keys for this session only.
static Future<EphemeralSession> create(
CryptoService crypto,
Uint8List peerPublicKey,
) async {
final ephemeralKeys = crypto.generateKeyPair();
final sessionKey = crypto.computeSharedSecret(
ephemeralKeys.privateKey,
peerPublicKey,
);
return EphemeralSession._(
ephemeralKeys: ephemeralKeys,
sessionKey: sessionKey,
);
}
/// Encrypt a message within this session.
Uint8List encrypt(Uint8List plaintext) {
final nonce = SecretBox.generateNonce();
_messageCounter++;
return SecretBox.encrypt(plaintext, _sessionKey, nonce);
}
/// The ephemeral public key to send to the peer so they can
/// compute the same session key.
Uint8List get publicKey => _ephemeralKeys.publicKey;
/// Destroy the session — delete all key material.
/// After this, messages from this session cannot be decrypted
/// by anyone, including us.
void destroy() {
// Zero out the key material before releasing
_ephemeralKeys.privateKey.fillRange(0, 32, 0);
_sessionKey.fillRange(0, 32, 0);
}
}Zero-knowledge architecture: the server knows nothing
E2E encryption means the server can't read message content. Zero-knowledge goes further: the server can't derive meaningful information from anything it stores.
Consider a typical E2E encrypted note-taking app. Even with encryption, the server might know:
- How many notes the user has
- When each note was created and modified
- The size of each note (which reveals rough content length)
- Which folders notes are organized into (if folder names are plaintext)
- The user's email and account details
A zero-knowledge architecture encrypts all of this:
/// Zero-knowledge note storage.
/// The server stores only encrypted blobs — it cannot determine
/// note count, titles, organization, or content.
class ZeroKnowledgeNoteVault {
final Uint8List _vaultKey; // derived from user's master password
ZeroKnowledgeNoteVault(this._vaultKey);
/// The vault is a single encrypted blob containing all notes.
/// The server sees one opaque blob per user — it cannot determine
/// how many notes exist, their titles, or their organization.
Future<void> syncToServer(List<Note> notes) async {
// Serialize ALL notes into a single structure
final vault = VaultContents(
notes: notes,
folders: _getFolders(notes),
metadata: VaultMetadata(
lastModified: DateTime.now().toUtc(),
noteCount: notes.length, // this stays encrypted
),
);
final plaintext = utf8.encode(jsonEncode(vault.toJson()));
final nonce = SecretBox.generateNonce();
final ciphertext = SecretBox.encrypt(
Uint8List.fromList(plaintext),
_vaultKey,
nonce,
);
// Server receives one opaque blob — no structure visible
await _api.put('/api/vault', body: {
'nonce': base64Encode(nonce),
'data': base64Encode(ciphertext),
});
}
/// Decrypt the entire vault from the server.
Future<List<Note>> loadFromServer() async {
final response = await _api.get('/api/vault');
final nonce = base64Decode(response['nonce']);
final ciphertext = base64Decode(response['data']);
final plaintext = SecretBox.decrypt(
ciphertext,
_vaultKey,
Uint8List.fromList(nonce),
);
final vault = VaultContents.fromJson(
jsonDecode(utf8.decode(plaintext)),
);
return vault.notes;
}
}The trade-off is immediately visible: you can't do server-side search, server-side sorting, or incremental sync. The server stores a blob. Any operation that requires understanding the data's structure must happen client-side.
Key derivation from passwords: the zero-knowledge entry point
In a zero-knowledge system, the server never sees the user's master password. Instead, the password is used to derive two things on the client:
- An authentication key — sent to the server to prove identity
- An encryption key — used to encrypt/decrypt the vault, never sent to the server
/// Derive separate authentication and encryption keys from the master password.
/// Uses Argon2id — the recommended password hashing function for this purpose.
class MasterKeyDerivation {
/// Argon2id parameters — these should be tuned to take ~500ms on target devices
static const int opsLimit = 3; // computation passes
static const int memLimit = 67108864; // 64 MB memory requirement
static const int keyLength = 64; // derive 64 bytes: 32 for auth + 32 for encryption
/// Derive keys from master password + server-provided salt.
/// The server stores the salt (not secret) and the auth key hash.
/// The encryption key NEVER leaves the device.
static DerivedKeys derive(String masterPassword, Uint8List salt) {
return using((arena) {
final passwordBytes = utf8.encode(masterPassword);
final passwordPtr = arena<Uint8>(passwordBytes.length);
final saltPtr = arena<Uint8>(salt.length);
final outputPtr = arena<Uint8>(keyLength);
passwordPtr.asTypedList(passwordBytes.length).setAll(0, passwordBytes);
saltPtr.asTypedList(salt.length).setAll(0, salt);
final result = _sodium.crypto_pwhash(
outputPtr,
keyLength,
passwordPtr.cast(),
passwordBytes.length,
saltPtr,
opsLimit,
memLimit,
2, // crypto_pwhash_ALG_ARGON2ID13
);
if (result != 0) {
throw CryptoException('Key derivation failed — possibly out of memory');
}
final derived = Uint8List.fromList(outputPtr.asTypedList(keyLength));
return DerivedKeys(
authKey: Uint8List.sublistView(derived, 0, 32), // first 32 bytes
encryptionKey: Uint8List.sublistView(derived, 32, 64), // last 32 bytes
);
});
}
}
class DerivedKeys {
final Uint8List authKey; // sent to server for authentication
final Uint8List encryptionKey; // stays on device, used for vault encryption
DerivedKeys({required this.authKey, required this.encryptionKey});
}The registration flow:
User creates account:
1. User enters email + master password
2. Client generates random salt (16 bytes)
3. Client derives auth_key + encryption_key from (password, salt)
4. Client sends to server: { email, salt, auth_key_hash: hash(auth_key) }
5. Server stores: email, salt, auth_key_hash
6. Client stores encryption_key in Keychain/Keystore
(Server NEVER sees the master password or encryption_key)The login flow:
User logs in:
1. Client sends email to server
2. Server returns salt for that email
3. Client derives auth_key + encryption_key from (password, salt)
4. Client sends auth_key to server
5. Server verifies hash(auth_key) matches stored hash
6. Server returns encrypted vault
7. Client decrypts vault with encryption_keyIf the server is breached, the attacker gets: email addresses, salts, and auth_key hashes. They do NOT get encryption keys or vault contents. To crack a single vault, they'd need to brute-force the master password through Argon2id — which, with the parameters above, costs ~500ms per guess per user. At that rate, a random 20-character password would take longer than the heat death of the universe.
Multi-device sync in a zero-knowledge world
This is where zero-knowledge gets complicated. If the encryption key is derived from the master password and stored only on the device, how does a second device access the vault?
Option 1: Re-derive from password. The user enters their master password on the new device. The client fetches the salt from the server and derives the same keys. Simple, but requires the user to remember and type a strong master password.
Option 2: Device-to-device key transfer. The existing device transfers the encryption key to the new device directly — via QR code, Bluetooth, or a temporary encrypted channel. This is what Signal and WhatsApp use for device linking.
/// Device linking via QR code.
/// The existing device displays a QR code containing a temporary
/// key exchange invitation. The new device scans it to establish
/// a secure channel for key transfer.
class DeviceLinking {
/// On the existing device: generate a linking invitation.
static LinkingInvitation createInvitation() {
final ephemeralKeys = CryptoService().generateKeyPair();
final linkingId = base64Encode(SecretBox.generateNonce()); // random ID
return LinkingInvitation(
linkingId: linkingId,
ephemeralPublicKey: ephemeralKeys.publicKey,
ephemeralPrivateKey: ephemeralKeys.privateKey, // kept in memory only
);
}
/// QR code contains: linkingId + ephemeral public key
/// (NOT the vault encryption key — that's transferred after handshake)
static String toQrPayload(LinkingInvitation invitation) {
return jsonEncode({
'id': invitation.linkingId,
'pk': base64Encode(invitation.ephemeralPublicKey),
});
}
/// On the new device: scan QR, compute shared secret, request key transfer.
static Future<Uint8List> completeHandshake(
String qrPayload,
CryptoService crypto,
) async {
final data = jsonDecode(qrPayload);
final peerPublicKey = base64Decode(data['pk']);
final linkingId = data['id'];
// Generate our own ephemeral keys
final ourKeys = crypto.generateKeyPair();
// Compute shared secret
final sharedSecret = crypto.computeSharedSecret(
ourKeys.privateKey,
Uint8List.fromList(peerPublicKey),
);
// Send our public key to the existing device via the server
// (the server relays but cannot decrypt — it doesn't have either private key)
await _api.post('/api/device-link/$linkingId', body: {
'public_key': base64Encode(ourKeys.publicKey),
});
// Existing device computes the same shared secret,
// encrypts the vault key with it, and sends it back via the server
final response = await _api.get('/api/device-link/$linkingId/key');
final encryptedVaultKey = base64Decode(response['encrypted_key']);
final nonce = base64Decode(response['nonce']);
// Decrypt the vault key using the shared secret
final vaultKey = SecretBox.decrypt(
encryptedVaultKey,
sharedSecret,
Uint8List.fromList(nonce),
);
return vaultKey;
}
}The server facilitates the relay but never sees the vault key. The ephemeral key exchange ensures the channel is secure. The QR code provides an out-of-band verification that you're linking to the right device (not an attacker's device pretending to be yours).
What you lose with E2E encryption
Architectural trade-offs are real. E2E encryption and zero-knowledge aren't free:
No server-side search. If the server can't read the data, it can't index or search it. All search must happen client-side, which means downloading the entire dataset to the device. For small datasets (notes, passwords, contacts), this is fine. For large datasets (years of email, thousands of documents), this is a UX problem.
No server-side processing. Want to generate a summary? Detect spam? Apply machine learning? All of that requires access to plaintext — which the server doesn't have. Either the processing happens on-device (resource-constrained) or you break the zero-knowledge model.
Complex key management. Lost password = lost data. If the user forgets their master password and there's no recovery mechanism, their vault is gone. You can implement recovery mechanisms (recovery codes, trusted contacts, security questions), but each one is a potential weakness in the zero-knowledge model.
Multi-device complexity. Every device needs the encryption key. Revoking a device means re-encrypting the vault with a new key and distributing it to all remaining devices. Key rotation for a single user requires coordination across all their devices.
Larger app size and more battery usage. Client-side encryption, especially with forward secrecy, means more computation on the device. Argon2id key derivation is intentionally slow (to resist brute-force attacks). This affects login time and battery life.
Compliance complications. Some regulations (like certain financial regulations) require the ability to audit communications. E2E encryption makes server-side auditing impossible by design. You may need to implement client-side audit logging that's separate from the encrypted content.
When to use each architecture
Standard TLS + server-side encryption (server has keys):
- Social media apps
- E-commerce / marketplace apps
- Content platforms
- Apps where server-side processing (search, recommendations, moderation) is essential
E2E encryption (server relays ciphertext):
- Messaging apps
- Voice/video calls
- File sharing between known parties
- Any feature where the promise is "we can't read your messages"
Zero-knowledge architecture (server stores opaque blobs):
- Password managers
- Encrypted note-taking apps
- Health data vaults
- Financial data aggregators
- Apps where the promise is "we can't read any of your data, not even metadata"
The honest middle ground: Many enterprise apps implement selective E2E encryption — message content is E2E encrypted, but metadata (timestamps, sender/recipient, message sizes) is visible to the server. This preserves server-side functionality (notification delivery, spam detection, usage analytics) while protecting the sensitive content.
Implementation recommendations for Flutter
If you're building E2E encrypted features in Flutter:
Use libsodium for the cryptographic primitives. The Dart FFI series shows how to set this up. Don't use dart:convert's base64 or homebrew XOR — use a vetted library.
Store private keys in the platform secure enclave. The Secure Enclaves post in this series covers this in depth. Private keys in SharedPreferences or plain files defeat the entire architecture.
Do heavy crypto work off the main isolate. Argon2id key derivation, vault decryption, and batch encryption should run in Isolate.run() to keep the UI responsive.
Plan for key loss from day one. What happens when the user gets a new phone and doesn't have their master password? Design the recovery mechanism before you ship the encryption.
Don't roll your own protocol for messaging. Use the Signal Protocol (via libsignal-protocol-dart) for any message-exchange pattern. The protocol handles forward secrecy, out-of-order delivery, and multi-device in ways that took years to get right.
Test with known vectors. Cryptographic implementations must be verified against published test vectors. "It encrypts and decrypts" is not sufficient — it could be encrypting badly. Verify against the NaCl/libsodium test vectors.
The honest assessment
E2E encryption and zero-knowledge architecture are powerful tools for specific problems. They are not universally appropriate.
For a healthcare app that needs HIPAA compliance, server-side encryption with proper access controls is usually the right answer — HIPAA doesn't require zero-knowledge, and the server needs to process health data for care coordination.
For a fintech app that aggregates bank data, the aggregation inherently requires the server to see the data. E2E encrypt the storage, but the processing pipeline needs plaintext access.
For a messaging app where privacy is the core value proposition, E2E encryption is non-negotiable.
For a password manager, zero-knowledge is the only architecture that makes sense — the whole point is that breaching the server doesn't compromise passwords.
Match the architecture to the threat model and the product requirements. The strongest encryption in the world doesn't help if it makes the product unusable or doesn't address the actual risks.
This post builds on the Dart FFI libsodium integration and connects to Secure Enclaves for private key storage and Compliance Frameworks for the regulatory context around encryption requirements.