What is Encryption

Encryption works by running your data through a reversible mathematical transformation that is cheap to compute if you hold a secret key and computationally infeasible to reverse if you do not — so the same bits look like uniform random noise to everyone except the key holder. Three nouns carry the whole idea: plaintext (the readable input), the key (the secret parameter), and ciphertext (the scrambled output). The algorithm itself is public; the key is the only thing that must stay secret. This is Kerckhoffs's principle — a cipher whose security depends on the algorithm staying hidden is already broken.

The cleanest way to see a key actually transform data is a stream cipher (how AES-CTR, AES-GCM, and ChaCha20 all work under the hood): the key seeds a pseudorandom keystream of bytes, and each plaintext byte is XORed with a keystream byte. XOR is its own inverse, so XORing again with the identical keystream recovers the plaintext.

Worked example: encrypt "HI" byte by byte

Take the two-byte plaintext "HI" and a keystream 2A C3 derived from a shared secret. Encryption is one XOR per byte; decryption is the same XOR again.

Ciphertext on the wire is 62 8A — no visible trace of "HI". To decrypt, XOR each ciphertext byte with the same keystream: 0x62 XOR 0x2A = 0x48 ('H') and 0x8A XOR 0xC3 = 0x49 ('I'). The key did all the work; the algorithm was public the whole time.

Why the naive "encryption gives integrity" claim is wrong

The original page said encryption helps verify data was not altered. It does not. Watch an attacker who never sees the key: they intercept C = 62 8A and flip the low bit of the first byte, 0x62 -> 0x63. The receiver decrypts as usual: 0x63 XOR 0x2A = 0100 1001 = 0x49 = 'I'. The message "HI" silently arrives as "II", and nothing in plain XOR/CTR/CBC ciphertext reveals the tampering. Because the transform is bit-for-bit linear, controlled edits to ciphertext become controlled edits to plaintext.

Integrity and authenticity come from a separate primitive: a MAC (message authentication code, e.g. HMAC) or, better, an AEAD cipher such as AES-256-GCM or ChaCha20-Poly1305 that produces an authentication tag over the ciphertext. The receiver recomputes the tag and rejects the message on any mismatch. Rule of thumb: encrypt-then-MAC, or just use an AEAD so you cannot get the composition wrong.

Symmetric vs. asymmetric — and a real asymmetric trace

Symmetric encryption (the XOR example above scaled up to AES) uses one shared key for both directions. It is fast — AES with hardware AES-NI runs at gigabytes per second — but both parties must already share the secret, which is the hard part on an open network.

Asymmetric encryption uses a public key to encrypt and a mathematically linked private key to decrypt, so the public key can be published freely. Toy RSA with key n=33, public e=3, private d=7: encrypt message m=4 as c = 4^3 mod 33 = 64 mod 33 = 31. Decrypt with the private exponent: 31^7 mod 33 = 4, recovering m. The security rests on factoring n being hard — trivial here, infeasible at real 2048–4096-bit sizes (and real RSA adds OAEP padding and can only encrypt payloads smaller than the key).

Encryption, hashing, and signatures — three different tools

These three primitives are often conflated, but they solve different problems:

• Encryption is reversible with a key. Use it when authorized parties need to read the data later (data in transit, files at rest).
• Hashing is one-way. Use it when you need to verify something without storing the original — passwords, content addresses, integrity checks. A good hash is deliberately irreversible, which is why you hash passwords but encrypt credit-card numbers you must retrieve.
• Digital signatures use asymmetric keys in reverse: the signer uses a private key to sign a hash of a message, and anyone with the corresponding public key can verify it. Signing does not hide the message (it is not encryption); it proves who sent it and that it was not altered. Toy trace: Alice hashes message M to get h = SHA-256(M), raises h to her private exponent s modulo n to produce signature σ, and sends (M, σ). Bob verifies by computing h from M, raising σ to Alice's public exponent v modulo n, and checking the results match. Real signatures use ECDSA/RSA-PSS/Ed25519, but the pattern is identical: private key signs, public key verifies.

This is why TLS needs both: the handshake uses asymmetric key agreement and signed certificates to establish identity, then symmetric AEAD encrypts the bulk data.

When to use which

Real systems almost never pick one — they go hybrid, which is exactly what TLS does: use asymmetric crypto once to agree on a fresh symmetric session key, then use fast symmetric AEAD for all the bulk traffic.

• Choose symmetric (AES-256-GCM, ChaCha20-Poly1305) when the endpoints can already share a secret and you are moving real volume — disk/database encryption at rest, an established session, a service holding its own key. Gain: speed and small keys. Cost: you must solve key distribution out of band.
• Prefer asymmetric (RSA-OAEP, ECDH/ECC) when you cannot pre-share a secret, or you need identity and signatures — bootstrapping a connection to a stranger, verifying a software update, issuing certificates. Gain: public key can be published; enables authentication. Cost: orders of magnitude slower, payload smaller than the key, so you never bulk-encrypt with it directly.
• Choose hybrid when it is a network protocol between parties that have not met — the default for anything over the internet. ECDH agrees a key, AES-GCM carries the data.

Pitfalls

• Assuming confidentiality = integrity. The exact bug this page had. Plain CTR/CBC/XOR ciphertext is malleable; always authenticate with an AEAD or encrypt-then-MAC.
• Nonce / IV reuse. Reusing a nonce with the same key in CTR or GCM is catastrophic — and you can derive why in one line. CTR/GCM encrypt as C = P XOR KS(key, nonce): the keystream depends only on the key and nonce. Reuse the same (key, nonce) for two messages and both use the identical keystream KS, so C1 XOR C2 = (P1 XOR KS) XOR (P2 XOR KS) = P1 XOR P2 — the keystream cancels, and the attacker learns the XOR of the two plaintexts with zero key knowledge (with any crib or known plaintext, that recovers both). In GCM specifically, a nonce collision additionally lets an attacker solve for the GHASH authentication subkey, after which they can forge valid tags (Joux's "forbidden attack") — so authenticity collapses too, not just confidentiality. This is why the nonce/IV must be unique per key, without exception.
• ECB mode. Encrypting each block independently leaks structure — identical plaintext blocks produce identical ciphertext blocks (the famous "ECB penguin"). Never use ECB for real data.
• Rolling your own crypto or hardcoding keys. Use vetted libraries; keep keys in a KMS/HSM, not in source or config.
• Encrypting passwords instead of hashing them. Passwords must be salted and hashed with bcrypt/scrypt/Argon2 — encryption is reversible, which is precisely what you do NOT want for stored credentials.
• Key management underestimated. Lose the key and the data is gone; leak it and everything it protected is exposed. Plan rotation, escrow, and revocation up front.

Takeaways

• Encryption buys confidentiality only. For integrity and authenticity add a MAC, or just use an AEAD (AES-256-GCM / ChaCha20-Poly1305) and stop worrying about it.
• The key, not the algorithm, is the secret (Kerckhoffs). A key transforms data through reversible math — for stream ciphers, literally XOR against a keystream.
• Symmetric is fast but needs a pre-shared secret; asymmetric solves distribution but is slow and payload-limited — so production systems run hybrid (asymmetric key agreement, symmetric bulk).
• Never invent your own scheme, and never reuse a nonce; get key storage and rotation right from day one.
• Asymmetric keys can also sign: the private key signs a hash, the public key verifies it. That is how certificates prove identity.
• End-to-end encryption means only the endpoints hold the keys — intermediaries (servers, relays) see ciphertext, not plaintext. It is the strongest privacy model for messages and backups.

Re-authored and deepened for this guide. Sources: Ferguson, Schneier & Kohno, Cryptography Engineering; Katz & Lindell, Introduction to Modern Cryptography; NIST SP 800-38D (AES-GCM); NIST SP 800-38A (block cipher modes); RFC 8446 (TLS 1.3) for the hybrid handshake; and Kerckhoffs's principle. The XOR/keystream trace, the malleability demonstration, and the toy RSA are hand-worked for this page.

Why the toy RSA exponents are inverses

For n = 33 = 3 × 11, Euler's totient counts the integers below 33 that are coprime to 33:

φ(33) = φ(3) × φ(11) = (3-1) × (11-1) = 2 × 10 = 20

The public exponent e = 3 and private exponent d = 7 are chosen so that:

e × d = 3 × 7 = 21 ≡ 1 (mod 20)

Euler's theorem says that for any m coprime to n:

mφ(n) ≡ 1 (mod n)

Therefore:

med = m1 + k·φ(n) = m × (mφ(n))k ≡ m × 1k ≡ m (mod n)

Check the toy example: encrypt m = 4 as c = 43 mod 33 = 64 mod 33 = 31. Decrypt as 317 mod 33. Since 317 = (3120)? · 317, and 3120 ≡ 1 (mod 33), the result collapses back to 4. The exponents are inverses in the multiplicative group modulo φ(n), not modulo n; that is the heart of RSA.

Homomorphic encryption frontier

Homomorphic encryption lets a third party compute on ciphertext and produce a ciphertext result that decrypts to the correct answer. A realistic use case is privacy-preserving medical analytics: a hospital encrypts patient records, sends the ciphertext to a cloud provider that runs an aggregation model, and receives an encrypted result. The cloud never sees plaintext; only the hospital's key can decrypt.

The practicality limits are severe. Fully homomorphic schemes are orders of magnitude slower than plaintext and need large ciphertext expansion. They are currently viable only for narrow, high-value workloads such as private set intersection, secure genomic computation, or limited federated learning. For routine cloud computation, traditional encryption-at-rest plus access controls remains the practical choice.

Key-management lifecycle

Most cloud designs use envelope encryption: a data-encryption key (DEK) encrypts the payload, and a key-encryption key (KEK) protects the DEK. Rotating the KEK does not require re-encrypting petabytes of data — only the small DEK blobs are re-wrapped.

When NOT to roll your own crypto

• Never invent algorithms; use TLS 1.3, AES-GCM, libsodium/WebCrypto.
• When NOT encrypt-only without auth — need AEAD (integrity) or signatures.

Interviewer follow-ups & drills

1. At rest vs in transit? Disk/KMS envelopes vs TLS on the wire — both usually required.
2. Drill: why not ECB mode for files? Patterns leak; use GCM/CTR+MAC.