Cryptography › Module 2 › Lesson 1
Symmetric Encryption (AES)
How AES uses one shared key for fast encryption—and how keys must stay secret
Opening
One shared secret locks the file. The same secret unlocks it. If that secret leaks, the lock was never a lock.
AES — Advanced Encryption Standard — is the workhorse under disks, VPNs, TLS bulk data, and messaging apps. It is symmetric: Encrypt(plaintext, K) yields ciphertext; Decrypt(ciphertext, K) yields plaintext. Same key K both ways. That is why it is fast enough for a movie file and why a leaked key is a total confidentiality failure, not a “maybe they can guess.” Module 1 hashed. Hashing is one-way. Encryption is two-way on purpose — but only for someone who holds K. This lesson stays in $HOME/cyberlium-lab on a toy file YOU create. The passphrase you type into openssl is a lab string. It is never your bank password, never your email, never reused on a real account. You will not invent a homebrew cipher. You will not encrypt other people’s files. You will not “break AES.” Next lesson is RSA: how two keys can carry this one AES key across a network you do not already share a secret on.
1. The symmetric contract: one key encrypts, the same key decrypts
Alice and Bob agree on a secret K. Alice runs AES with K over her bytes and sends only ciphertext. Bob runs AES in reverse with the same K. An eavesdropper without K should learn nothing useful — that is confidentiality, not a hash, not “the file looks messy.” Symmetric crypto does not care who is authorized; it cares who possesses K. Logging K, hardcoding K, or emailing K next to the .enc file collapses the model. The algorithm can be perfect and the operation still fails.
2. AES-128 and AES-256: a standard block cipher, not a notebook formula
AES is a block cipher: it works on 128-bit (16-byte) blocks. The number in AES-128 versus AES-256 is the key size in bits, not the block size. AES-128 uses a 128-bit key; AES-256 uses a 256-bit key. Both are NIST-standardized. For this course, treat AES-256 as the lab default because openssl enc -aes-256-cbc is easy to type and the extra key bits are cheap on a laptop. Do not build a “stronger” cipher from XOR, a word-shift, or a Python loop you invented. Homebrew ciphers fail in boring ways that look clever until someone who took this module actually looks.
A block cipher still needs a mode for long messages. Authenticated encryption (AES-GCM, or ChaCha20-Poly1305) is the app default: hide content and detect tampering. openssl enc AES-256-CBC is allowed here as a beginner decrypt of YOUR file, with a warning: CBC without a MAC does not give integrity by itself. Do not pick a mode from a random blog acronym.
3. Confidentiality is not integrity: GCM versus “it decrypted, so it is fine”
Confidentiality means Mallory cannot read the plaintext. Integrity means Mallory cannot flip bits in the ciphertext and have Bob accept a mutated message as genuine. AES in a raw encryption-only mode can hide bytes and still allow undetected tampering depending on how it is used. Authenticated encryption (AEAD) — AES-GCM is the usual example — binds a tag to the ciphertext (and often to extra associated data). Decrypt-and-verify fails closed if the tag does not match. “It decrypted into something that looks like English” is not a verify step.
Real apps should call a library that implements AES-256-GCM (or another AEAD) with a unique nonce per message. Some OpenSSL builds expose openssl enc -aes-256-gcm. Treat that as optional literacy, not as a portable recipe: enc’s AEAD handling of the tag is easy to get wrong compared with a proper API. This lab uses AES-256-CBC with -salt and -pbkdf2 because it is the documented beginner openssl enc path. The warning travels with it: password-based enc is not a password manager; CBC-in-openssl is not how you ship a product; never reuse this lab passphrase as a real password.
Three properties people mash together. AES without extra machinery only promised the first.
Confidentiality
Without K, the ciphertext should not reveal the toy note. That is AES’s job when used correctly.
Integrity
Detect that ciphertext was altered. Needs a MAC or AEAD (AES-GCM). Bare CBC does not gift this.
Authenticity
“This came from the key holder.” Signatures (lesson 4) and AEAD tags are different tools. Do not confuse them.
4. The key distribution problem: speed does not deliver K to Bob
AES is fast. The hard part is not the math on a laptop. The hard part is: how do Alice and Bob share K without Mallory copying it? If they already have a secure channel, they did not need a new K. If they do not, mailing the key in plaintext next to the .enc file is theater. Instant-message paste, screenshot, world-readable gist — same failure. This is the key distribution problem. Module 2’s answer, starting next lesson, is asymmetric crypto: a public key anyone can use to wrap a fresh AES session key, plus (in Module 3) TLS doing that handshake for HTTPS.
Until then: store K like a secret — not in the filename, not in git, not in the chat that attaches the .enc. Rotate when exposed. Delete lab material when the exercise ends. A hardcoded AES key in a “student app” is how that string leaks into production.
5. IV and nonce uniqueness: never reuse the extra random that makes two encryptions differ
Almost every AES mode needs extra public randomness besides K. CBC calls it an IV (initialization vector). GCM calls it a nonce. The rule is the same and it is not optional: do not reuse that value with the same key. Reusing an IV in CBC can leak patterns about plaintext. Reusing a nonce in GCM is worse — it can break authenticity and leak key material. “I set the IV to all zeros so the lab is reproducible” is how people copy a vulnerability into a tutorial.
openssl enc -salt mixes a salt into password-based key derivation so two runs with the same passphrase do not automatically clone the same key/IV pair the way a naive script might. That helps beginners. It does not make enc a library. In application code you ask the API for a fresh random nonce, store it next to the ciphertext (it is not the secret), and never replay it with that key. pbkdf2 exists because a human passphrase is not 256 random bits — it is a stretch. A lab passphrase is still not a real password. Stretching does not license reuse on your email account.
6. Wrong vs right: homebrew locks and reused passphrases vs openssl on YOUR toy file
Worked failure — treating AES as a puzzle to invent, a password to recycle, or a weapon against someone else’s disk.
Wrong
XOR a file with a word you like and call it encryption. Reuse your bank password as the openssl passphrase. Email the key in the same thread as the .enc. Copy a fixed IV into every message. Encrypt a classmate’s folder “to demonstrate ransomware.” Commit toy-secret.enc and the passphrase to a public repo. Try to “break AES” or factor a site’s keys. Homebrew ciphers and attacks on other people’s data are out of scope and, aimed outward, can be criminal.
Right
Create $HOME/cyberlium-lab. Write a toy note YOU authored. openssl enc -aes-256-cbc -salt -pbkdf2 (or AES-256-GCM if your docs make the tag handling obvious). Invent a lab-only passphrase you will never use as a real password. Decrypt on the same machine. Confirm the round-trip. Note that confidentiality ≠ integrity and that IVs/nonces must be unique. Delete the ciphertext and the note when done. Next — RSA — is how K can travel without a prior secret.
7. Practical: encrypt and decrypt YOUR toy file with openssl in cyberlium-lab
On a computer you own, create the lab folder, write a short fictional note, and let openssl prompt for a passphrase. Do not put a live password on the command line. Do not point -in at anyone else’s files. Git Bash, WSL, macOS, and Linux all speak this. Native Windows PowerShell can run openssl if it is on PATH; chmod 600 becomes “restrict to your user” in the profile. After you read the decrypt, delete the lab passphrase from your head as a real-world secret — it never was one.
Command guide
DEFENSIVE AES lab — YOUR file, $HOME/cyberlium-lab, lab passphrase only
DEFENSIVE. Encrypt a toy file YOU created. NEVER other people's files. NEVER reuse the openssl passphrase as a real password. NEVER invent a homebrew cipher. NEVER "break AES" or attack a site.
Command — copy this
mkdir -p "$HOME/cyberlium-lab" cd "$HOME/cyberlium-lab"
Command — copy this
echo "fictional lab note — delete after class" > toy-aes-note.txt
Beginner openssl enc path: AES-256-CBC + salt + PBKDF2.
Optional command
openssl will PROMPT for a passphrase — invent a LAB-ONLY string.
WARNING: CBC hides content; it does not by itself prove the file was not tweaked. WARNING: never reuse IVs/nonces with the same key in real application code. Prefer AES-256-GCM (AEAD) in libraries. openssl enc -aes-256-gcm exists on some builds; tag handling is easy to get wrong — treat CBC here as a teaching decrypt.
Command — copy this
openssl enc -aes-256-cbc -salt -pbkdf2 \ -in toy-aes-note.txt -out toy-aes-note.enc
Command — copy this
openssl enc -d -aes-256-cbc -pbkdf2 \ -in toy-aes-note.enc -out toy-aes-note.out
Unix: cat Windows cmd: type
Command — copy this
cat toy-aes-note.out
Confirm the text matches what you wrote.
Command — copy this
chmod 600 toy-aes-note.txt toy-aes-note.enc toy-aes-note.out 2>/dev/null || true
Windows without chmod: restrict these files to your user in the profile.
Notes — method only, NEVER the passphrase:
Command — copy this
{
echo "=== AES LAB NOTES (no passphrase) ==="
echo "model: same key K encrypts and decrypts"
echo "algo: AES-256-CBC via openssl enc -salt -pbkdf2"
echo "prefer_in_apps: AES-256-GCM AEAD with unique nonce"
echo "confidentiality: yes (if K stays secret)"
echo "integrity_alone: no — CBC is not a signature and not GCM"
echo "iv_nonce: never reuse with the same key"
echo "ethics: lab passphrase never a real password; MY file only"
} > aes-lab-notes.txt
chmod 600 aes-lab-notes.txt 2>/dev/null || trueOptional cleanup after you confirm the round-trip:
Optional command
rm -f toy-aes-note.txt toy-aes-note.enc toy-aes-note.out
NEVER: openssl enc on /etc/shadow, mail, or a classmate's disk NEVER: -pass pass:YourRealPassword on the command line NEVER: email K next to the .enc file
Mission: AES round-trip on YOUR toy file (passphrase never reused)
1) In $HOME/cyberlium-lab, write a toy note YOU authored and encrypt it with openssl enc -aes-256-cbc -salt -pbkdf2 (AES-256-GCM only if you understand your build’s tag handling). 2) Decrypt and confirm the bytes match. Write aes-lab-notes.txt covering same-key model, AES-128/256, confidentiality ≠ integrity, key distribution, and IV/nonce uniqueness — not the passphrase. 3) chmod 600 (or restrict to your user). Never reuse the lab passphrase as a real password. Never encrypt other people’s files.
Stuck? Ask Cyberlium AI Mentor
If “AES is just a hash with a key” or “I should invent my own cipher” still blurs, ask for a hint — not a cracker. Try: "Hint only: why Encrypt and Decrypt share K, why AES-GCM adds integrity that CBC-in-openssl does not, why IVs must not repeat, and why my lab passphrase must never be a real password?" You still run the round-trip on YOUR file. No homebrew. No other people’s disks. No “break AES.”
You now treat AES as fast symmetric confidentiality with a secret that must stay secret: AES-128/256, not a notebook XOR; GCM (in real apps) when you also need tamper detection; unique IVs/nonces; lab openssl on a file you own. The unsolved piece is how K reaches Bob. Next — Asymmetric Encryption (RSA) — public/private pairs, wrapping keys instead of bulk video, a toy openssl genrsa you delete, and a preview of hybrid TLS. Still $HOME/cyberlium-lab. Still no attacks on sites or other people’s keys.
Knowledge Check
APPLY: A teammate wants to “AES-encrypt” backups with a Python XOR loop they wrote, reuse their email password as the openssl passphrase, and email that passphrase in the same thread as the .enc. What is AES actually, and what do you do?
Multiple choice
Knowledge Check
APPLY: You encrypted toy-aes-note.txt with AES-256-CBC. A friend flips one byte of the .enc and says “if it still decrypts into something, integrity held.” They also want to reuse the same IV for every file “for reproducibility.” What did AES give you, and what is forbidden?
Multiple choice
Knowledge Check
APPLY: True or False: Because AES is fast, Alice can just publish K on a homepage so Bob can decrypt, and openssl lab passphrases should be the same as production logins so students “build muscle memory.”
True or False