🔐 Encryption

Encryption:
  "Hello, World!" → 🔐 → "xK9$#mPq2&..."
  (Plaintext)           (Ciphertext)

Decryption:
  "xK9$#mPq2&..." → 🔓 → "Hello, World!"
  (Ciphertext)           (Plaintext)

Without the key, ciphertext should look like random data.
In practice, the goal is that it’s computationally infeasible to recover the original plaintext.

One key does both:
  Encrypt: plaintext + key → ciphertext
  Decrypt: ciphertext + key → plaintext

Like a door lock:
  Same key locks and unlocks.

✓ Fast, efficient
✓ Good for large data
✓ File encryption
✓ Database encryption
✓ Disk encryption

Challenge: How do you share the key safely?

Key pair: Public key + Private key

Anyone can encrypt with PUBLIC key.
The private-key holder can decrypt with the PRIVATE key.

Like a mailbox:
  Anyone can drop mail in (public slot).
  The key-holder can take mail out (your key).

Alice wants to send secret message to Bob:

1. Bob shares his PUBLIC key (anyone can have it)
2. Alice encrypts with Bob's public key
3. Alice sends encrypted message
4. Bob decrypts with his PRIVATE key (kept private by Bob)

Anyone can encrypt TO Bob.
Bob can decrypt (with his private key).

✓ Key exchange
✓ Digital signatures
✓ Protected communication setup
✗ Slow for large data

Often used together:
  Asymmetric to exchange symmetric key.
  Symmetric for the actual data.

1. Use asymmetric to exchange a symmetric key
2. Use symmetric key for actual data

TLS typically works like this:
  Handshake (uses asymmetric crypto) → shared session keys
  Session keys encrypt most application data (symmetric)

Encrypted when stored:
  - Full disk encryption (BitLocker, FileVault)
  - Database encryption
  - Encrypted files/backups

Even if device stolen, data unreadable.

This is strongest when the device is locked and the encryption keys aren’t available to the attacker (for example, the device is powered off and the passcode isn’t known).

Encrypted when moving:
  - HTTPS (TLS)
  - VPNs
  - Encrypted messaging

Network attackers can't read your data.

Assuming the connection is set up correctly (and certificates are validated), it’s designed to prevent passive eavesdroppers from reading your data and to make tampering detectable.

In end-to-end encryption, the sender and recipient hold the keys to read messages:
  - Signal, WhatsApp
  - iMessage

In many end-to-end designs, the service provider can’t decrypt message *contents* because only the endpoints hold the keys.
In practice, metadata and backups can change what’s protected.

All else equal, larger keys raise the cost of brute-force guessing.

But real-world security also depends on the algorithm, mode (how it’s used), and implementation.

Key leaked = Data can be compromised

Store keys:
  - Hardware Security Modules (HSMs)
  - Key management services (AWS KMS)
  - Encrypted key storage

Avoid hardcoding keys in code.

Change keys periodically:
  - Limits damage if key compromised
  - Compliance requirement
  - Often done via “envelope encryption” (re-wrapping data keys) instead of decrypting and re-encrypting all data

Making up your own encryption algorithm is risky
"I'll just XOR with a secret word"

Use established, audited algorithms (AES, RSA).

Reusing an IV/nonce with the same key can leak patterns
Use a unique IV/nonce for each encryption.
Many schemes use a random IV/nonce; some require uniqueness but not randomness.

Encryption alone doesn't necessarily detect tampering.
Use authenticated encryption (for example, AES-GCM or ChaCha20-Poly1305).

Encrypted database + key in the same place often defeats the point

Keep keys separate from encrypted data when possible.