How File Encryption Works (No Math Required)

Encryption gets explained badly more often than not. The math is intimidating. The terminology is overloaded. The marketing on top makes everything murkier. Here's a clean version, without math, that should leave you knowing enough to ask better questions.

The lock-and-key analogy (and where it breaks)

Encryption is sometimes described as putting a file in a digital safe. You lock the safe with a key. Only someone with the same key can unlock it. That's basically right.

Where the analogy breaks: a physical safe is a one-of-a-kind thing. A digital "safe" is just a mathematical procedure applied to bytes. You can run the procedure as many times as you want on as many files as you want. The interesting question isn't "where's the safe?" but "where's the key, and who has it?"

Symmetric vs asymmetric — the one distinction worth knowing

Two flavors of encryption matter in practice:

Symmetric encryption

One key encrypts and decrypts. If you have the key, you can do both directions. AES (Advanced Encryption Standard) is the canonical example. AES-256-GCM is what Zippd uses for file contents.

Pros: fast, simple, well-understood.
Cons: how do you share the key? If you send it alongside the file, anyone who intercepts both wins.

Asymmetric encryption

Two keys: a public key (you can share it freely) and a private key (you keep secret). Anyone with your public key can encrypt a message that only your private key can decrypt. RSA and elliptic-curve crypto (ECC) are the canonical examples.

Pros: solves the key-sharing problem — no shared secret needed up front.
Cons: slow, complex, only practical for small data (or for exchanging symmetric keys).

How real systems combine them

Most modern systems use both: asymmetric crypto to securely exchange a symmetric key, then symmetric crypto for the bulk data. HTTPS does this. So does Signal. So does PGP. The slow asymmetric step happens once; the fast symmetric crypto handles the actual content.

Zippd skips the asymmetric step because the symmetric key gets transported in a different channel: the URL fragment, hand-delivered through whatever messaging app the sender uses. The recipient's browser reads the URL, extracts the key, decrypts. No public-key dance needed.

What happens when you "encrypt" a file

Step by step (using AES-256-GCM as the example):

1. A random key is generated. 256 bits of pure randomness. Not derived from a password — a real random key.
2. The file is split into manageable pieces. AES operates on 16-byte blocks at a time.
3. Each block is mixed with the key. Through a sequence of mathematical operations (substitution, permutation, repeated for 14 rounds in AES-256).
4. The output looks like random noise. Statistically indistinguishable from coin flips.
5. An authentication tag is added. 16 bytes that prove the ciphertext wasn't modified. GCM mode does this automatically.

Decryption is the same process in reverse. Same key, same procedure, plaintext comes out. Different key, garbage comes out (or the authentication fails).

Why "256 bits" is a comically large number

A 256-bit key has 2^256 possible values. That's roughly 10^77 — about the number of atoms in the observable universe.

To brute-force it, you'd have to try keys until one worked. Even if you could test a trillion keys per second on every computer ever built, the heat death of the universe would arrive long before you finished. AES-256 is, in practice, unbreakable by brute force. More on AES specifically.

Where encryption happens matters more than what runs

This is the most important practical takeaway: AES-256 is a strong algorithm regardless of who runs it. The strength of any encrypted system depends on where the algorithm runs and who holds the keys.

• If the server encrypts your file, the server holds the key. The server can decrypt at will. Strong algorithm, weak system.
• If your browser encrypts your file with a key the server never sees, only you and your recipient can decrypt. Same strong algorithm, strong system.

Browser-side encryption is what makes the system "zero-knowledge." The algorithm doesn't change. The architecture does.

The role of randomness

Encryption is only as good as the randomness of the key. If a "random" key is actually predictable, the encryption collapses.

Browsers expose crypto.getRandomValues(), which provides cryptographically-secure random bytes from the operating system. This is the right primitive. Anything that derives a key from a password without sufficient stretching (PBKDF2, scrypt, Argon2) is suspect.

What encryption doesn't protect

Even perfect encryption leaves things visible:

• Metadata. File size, upload timestamp, recipient. Encryption hides content, not metadata.
• Existence. An observer can tell that you uploaded something, even if they can't tell what.
• Endpoint compromise. If your laptop has malware, the encryption happens on a compromised device. Nothing the math can do.
• Coercion. If someone forces you to give up the key, encryption doesn't help.

FAQ

If encryption is so simple, why do people get it wrong?

The math is easy. The protocol design around it is hard. Most encryption failures come from how keys are generated, stored, or transported — not from the cipher itself.

Can quantum computers break AES?

For AES-256, no — Grover's algorithm only halves the effective key length, making it AES-128-equivalent, which is still unbreakable. Asymmetric crypto (RSA, ECC) is much more quantum-vulnerable.

Does encryption slow things down?

On modern hardware, no. AES-NI instructions run encryption at multiple gigabytes per second.

How do I know my service uses real encryption?

Check that the encryption happens in your browser (open DevTools, watch the Network tab — outgoing data should be random-looking ciphertext). Check that share URLs have a key fragment after #. Full guide here.

Try it

The homepage upload flow is a working demo of everything described here. Watch the bytes go random in DevTools.