Cybersecurity › Module 4 › Lesson 1
Basics of Encryption
Plaintext, ciphertext, algorithms, and keys
Opening
Secrets that travel through hostile space
Module 3 controlled who may enter — identity and authorization. Module 4 protects what they carry once the channel or the disk is untrusted. Encryption turns readable data into gibberish for anyone without the key. It is the main technical tool behind Confidentiality when you cannot trust every router, café Wi-Fi peer, courier, or thief who might touch a laptop. Caesar shifted letters by hand; today AES and friends do it with public math at machine speed. Before algorithms, learn the contract: encryption hides content from unauthorized readers. It does not automatically prove who sent the message, stop ransomware from locking files you can decrypt, or make a website honest. Know what it solves — and what it does not.
1. Plaintext vs ciphertext
Plaintext is the readable original: Hello World, a PDF contract, a card number, a chat message. Ciphertext is the scrambled output after encryption — bytes that should be useless to an observer who lacks the correct key. Good ciphertext looks random. That randomness is intentional; patterns are cracks waiting to happen.
Decryption reverses the transform when the right key (and algorithm mode) is supplied. Wrong key → garbage or hard failure. That absolute dependence on the key is why "we encrypted it" is only half a sentence. The other half is always: who can get the key, and how is the key stored?
Plaintext
Readable original data: Hello World, a PDF, a card number, a private note.
Ciphertext
Scrambled output after encryption — useless without the correct key (and proper mode).
2. Algorithm + key = the lock and the cut
The algorithm is the public, battle-tested math — the lock design. AES, ChaCha20, and modern authenticated modes are published so experts can attack them for years. Security does not come from hiding which standard you use. Security comes from key secrecy, key length, correct implementation, and refusing homemade ciphers.
The key is the secret variable — the unique cut of the key. Same algorithm, wrong key → failure. Lose the only copy of the key → data may be gone forever, by design. That is not a bug in strong encryption; it is the point. Professionals therefore treat key management (generation, storage, rotation, recovery, destruction) as half of cryptography — often the harder half.
Algorithm
Public rules for scrambling/unscrambling (e.g. AES-GCM). Experts attack these for decades before you should trust them in production.
Key
Secret input. Protect it like the data — or more carefully. Length matters; secrecy matters more.
Library / mode
Use vetted libraries and authenticated encryption modes. "I XOR'd with my birthday" is not a mode.
3. What encryption solves vs what it does not
Encryption solves Confidentiality against observers who lack the key: café Wi-Fi sniffers see TLS ciphertext; a stolen powered-off laptop with full-disk encryption yields unreadable sectors; an encrypted backup dump is not a gift-wrapped plaintext archive.
Encryption does not, by itself: stop you from sending secrets to the wrong person; prove the website is trustworthy (HTTPS encrypts the path; phishing sites can also use HTTPS); prevent an attacker who already has your logged-in session from acting as you; replace backups; or fix authorization bugs. Integrity and authenticity often need additional constructions (MACs, signatures, authenticated modes) — you will meet hashing and TLS deeper in this module.
4. At rest vs in transit
Defenders split data by where it lives. Data at rest sits on disks, phones, USB sticks, and backups. Full-disk encryption, encrypted volumes, and encrypted database fields protect stored bytes when the media is stolen or imaged. Data in transit moves across Wi-Fi, cellular, and the internet. HTTPS/TLS tunnels turn path snooping into ciphertext watching.
You often need both. A file can be encrypted on disk and still be sent through a secure channel — or carelessly emailed as an unlocked attachment over a cleartext protocol. Ask two questions for every sensitive asset: How is it protected while stored? How is it protected while moving?
Data at rest
Disks, backups, USB sticks, phone storage. Full-disk encryption protects a stolen laptop's files.
Data in transit
Packets crossing networks. HTTPS/TLS encrypts the path between browser and server (when configured correctly).
5. Wrong vs right: inventing your own crypto
Worked failure mode — "clever" homemade cipher shipped to production:
Wrong
A developer XORs messages with a birthday, reverses strings, or invents a "military grade" shuffle and calls it encryption. Attackers reverse it in minutes. Hiding the algorithm (security through obscurity) fails the moment the app is reverse-engineered. Obscurity ≠ cryptography.
Right
Use vetted libraries and standard algorithms (AES-GCM and friends), manage keys carefully in a password manager / OS keychain / KMS, never ship plaintext secrets in source or tickets, and prefer authenticated encryption. Professionals say: never roll your own crypto. Publish the algorithm; protect the key.
6. Practical: name the pieces
Vocabulary drills build instinct before you touch openssl labs later. No attacking systems — only labeling concepts and observing HTTPS on sites you already use.
Command guide
Encryption vocabulary drill (no attacking systems)
Label each line: plaintext / ciphertext / algorithm / key
Command — copy this
1. "Transfer $500 to account 22" → __________ 2. a8f3...c91e (looks random) → __________ 3. AES-256-GCM → __________ 4. the secret bitstring used to lock #1 → __________
At rest vs in transit (circle one)
Command — copy this
A) Stolen laptop with FileVault/BitLocker on → at rest / in transit B) Browser padlock on https://bank.example → at rest / in transit C) Encrypted phone backup sitting in cloud → at rest / in transit D) VPN tunnel while you browse on café Wi-Fi → at rest / in transit
What encryption does NOT promise
Command — copy this
[ ] Website is honest / not a phish [ ] Authorization bugs are fixed [ ] You chose the correct recipient [ ] Backups exist if you lose the key
Safe observation later this module: Padlock on https:// = encryption in transit (TLS) Not a promise the website is ethical — only that the path is encrypted. Do NOT click through certificate warnings on banking or email.
Command guide
Terminal practice (Linux / Kali / macOS — YOUR machine only)
First contact with openssl — OWN lab files only Linux / Kali / macOS
Command — copy this
mkdir -p "$HOME/cyberlium-lab" cd "$HOME/cyberlium-lab" echo "practice plaintext — not a real secret" > vocab.txt openssl dgst -sha256 vocab.txt
Hashing ≠ encryption: you cannot "decrypt" a digest back to vocab.txt
Windows PowerShell (OpenSSL in PATH, or use Get-FileHash)
Command — copy this
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\cyberlium-lab" | Out-Null Set-Location "$env:USERPROFILE\cyberlium-lab" "practice plaintext — not a real secret" | Out-File -Encoding ascii vocab.txt Get-FileHash .\vocab.txt -Algorithm SHA256
Optional command
openssl dgst -sha256 vocab.txt
NEVER: encrypt/decrypt other people's files or crack ciphertext dumps
Mission: find one encrypted path
Open your bank or email in a browser. Confirm https:// and the padlock. Write one sentence: "This protects data in transit between my browser and ___." Optionally confirm your phone or laptop reports device encryption / screen lock ON. Do not ignore certificate warnings.
Stuck? Ask Cyberlium AI Mentor
If algorithm vs key, or at-rest vs in-transit, feels abstract, ask Cyberlium AI Mentor for a hint — not a homemade cipher design. Try: "Hint only: lock design vs unique key cut — which is the algorithm?" Or: "Hint only: stolen laptop disk vs café Wi-Fi sniff — at rest or in transit?"
You can name plaintext, ciphertext, algorithm, and key; you know encryption hides content but does not fix every trust problem; and you can separate at-rest from in-transit protection. Next — Symmetric vs. Asymmetric — how many keys you need and how strangers exchange secrets safely on the open internet.
Knowledge Check
APPLY: A snooper on café Wi-Fi captures your HTTPS banking session. What do they primarily see on the wire?
Multiple choice
Knowledge Check
APPLY: Why do professionals say "never roll your own crypto"?
Multiple choice
Knowledge Check
APPLY: True or False: Encrypting a stolen laptop's drive is an example of protecting data at rest.
True or False