Encryption Explained Simply (for Non-Devs)
Symmetric, asymmetric, keys, hashing... Encryption demystified. Why 'military-grade' means nothing and what actually matters for your security.
"AES 256 military-grade encryption." You don't understand that phrase? That's normal -- it's marketing. Let me explain encryption in plain English, with real examples and what actually matters.
You see "AES 256-bit military-grade encryption" on an app and think "super secure!" Spoiler: that phrase means nothing. Or rather, it carefully avoids telling you what actually matters.
After integrating ChaCha20-Poly1305 via CryptoKit into Inner Gallery, let me demystify encryption without the technical jargon.
Encryption is turning a secret into gibberish
Imagine you write "I love you" and lock it in a safe. Encryption is transforming that message into "K w'dnph" using a secret key. Without the key, there's no way to recover the original message.
In computing, it's the same. Your photos in Inner Gallery become incomprehensible gibberish. Only your private key can transform them back into images.
Unencrypted data: "Hey Lucas, meet at 3 PM at the park"
Encrypted data: "xK2mP9$qZr#8nWcL@4tYuI6oAsD3fGhJ1bNmV7sE"
Without the key, the second message is useless. That's encryption.
Symmetric vs asymmetric: same key or not?
Symmetric encryption: a single key to encrypt AND decrypt. Like a padlock with the same key to lock and unlock.
You encrypt with key ABC123, you decrypt with ABC123. Simple, fast, efficient for your personal data. Inner Gallery uses symmetric encryption: your private key encrypts and decrypts your photos.
Asymmetric encryption: two linked but different keys. A public key (anyone can know it) and a private key (only you have it).
I encrypt a message with your public key, and only your private key can decrypt it. Useful for sending secrets to strangers. This is the principle behind Signal, WhatsApp, and encrypted emails.
Symmetric = one key, fast, for your data. Asymmetric = two keys, slow, for communicating with others.
AES, ChaCha20, RSA: the algorithms demystified
AES (Advanced Encryption Standard): the current standard, approved by all governments. Solid, battle-tested, but somewhat dated (2001).
ChaCha20: more recent (2013), designed by cryptographer Daniel Bernstein. Faster on mobile, more resistant to certain attacks.
RSA: asymmetric, for exchanging keys or signing. Slow, unsuitable for encrypting large volumes.
For Inner Gallery, I chose ChaCha20-Poly1305. Why not AES? Better performance on iPhone, simpler code to audit, excellent resistance to attacks. RFC 8439 details the algorithm if you want to dig deeper.
Hashing: the digital fingerprint of data
Hashing is different from encryption. You cannot "decrypt" a hash. It's a unique, irreversible fingerprint.
Data: "password123"
SHA-256 hash: "ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f"
Change one character, and the hash changes completely. It's impossible to recover "password123" from the hash. This is perfect for storing passwords: the server compares hashes, never the actual passwords.
Encryption = reversible with the key. Hash = irreversible fingerprint. Two different concepts, two different uses.
"Military-grade": pure marketing
"Military-grade encryption" means nothing technically. AES is used by the US military? Yes. By Gmail, Facebook, and your bank too? Also yes.
What matters isn't the algorithm (AES and ChaCha20 are both excellent), it's:
Who holds the keys? If the app keeps your keys on its servers, your encryption is worthless. The company can read your data whenever it wants.
Where is the data stored? Encrypted locally or in plaintext on a server? Huge difference.
Is the implementation secure? Even AES can be poorly implemented and vulnerable.
What really matters: who controls the keys
In Inner Gallery, YOU hold the encryption key. It's generated on your iPhone, never leaves your device, and isn't stored anywhere else. Apple can't read your photos, and neither can I.
Contrast this with a typical cloud app:
- Your data is encrypted on their servers
- But THEY hold the keys
- So THEY can decrypt everything
- You either trust them or you don't
The EFF (Electronic Frontier Foundation) explains this distinction well: having encrypted data is useless if someone else has the key.
The real questions to ask
When facing an app that claims to encrypt your data:
- Who generates the keys? You locally = good. The app on its servers = questionable.
- Where are the keys stored? On your device = good. On their servers = they can see everything.
- Can the app access your decrypted data? No = privacy. Yes = they can analyze/resell everything.
- Is the code auditable? Open source = transparent. Black box = trust them.
ChaCha20-Poly1305: why this choice for Inner Gallery
ChaCha20 for symmetric encryption + Poly1305 for authentication = a winning combo.
Advantages:
- Faster than AES on ARM (iPhone processors)
- Resistant to side-channel attacks
- Simple code, fewer potential bugs
- IETF standard, no patents
Disadvantages:
- Less well-known than AES
- Less widespread than AES in the industry (but natively supported by Apple via CryptoKit)
For an app handling ultra-sensitive photos, the extra security and performance are worth the custom implementation effort.
The future: post-quantum encryption
Quantum computers (when they exist at scale) will break RSA and other current asymmetric algorithms. NIST is working on post-quantum standards that are resistant to them.
For symmetric encryption (AES, ChaCha20), quantum computers just require longer keys. AES-256 remains secure even against quantum attacks.
Also worth reading
- iOS Permissions: What Each App Really Knows About You
- Local-First Apps: Why I Believe in Them for Certain Products
- Zero Third-Party Dependencies: When It's Worth It (and When It's Not)
Encryption isn't magic. It's math applied to data protection. What matters is who controls the keys and where your information is stored.
Your next password manager: check who holds the decryption keys. Your privacy depends on it.