Hashing vs Encryption (CEH Recap)

A cryptographic hash function takes input of any size — a password string, a 4 KB notes file, an installer — and produces a fixed-length digest. SHA-256 always yields 256 bits, usually printed as 64 hexadecimal characters. The input can be one byte or a gigabyte; the digest width does not grow. Deterministic means the same input always yields the same digest on every honest implementation. That is why comparing your local hex to a published hex is a real integrity check — provided you obtained the published hex from a channel you already trust, not from a forum next to a cracked download. Matching hex means the bytes you hashed now equal the bytes that were hashed then. It does not mean the file is safe, signed, or from a vendor. Malware can be hashed too; the digest would just be stable. You already practiced this as a defender in Topic 7 and Topic 8: SHA-256 of a file you wrote, then the same file after an edit, then two hex strings that no longer matched. That was integrity. Same bytes, same digest. Change one character, and the digest looks unrelated — avalanche.

One-way (preimage resistance) means that given a digest, it should be computationally infeasible to find any input that produces it. You are not supposed to “decrypt” SHA-256. There is no inverse function with a key. For integrity of files you own, you never need to invert: you re-hash the file you have and compare. MD5 and SHA-1 left the security toolkit in Topic 8 because collisions became practical; SHA-256 is the family this lab uses. You hash contents, not the filename. Open files in binary mode ("rb") so a platform newline rewrite does not change the digest by accident. This course does not turn you into a cracking shop.

sudo apt install python3

brew install python3

python3 - << 'PY'
import hashlib
print(hashlib.sha256(b'cyberlium-lab-only').hexdigest())
print('one_way_fingerprint: cannot invert; refuse hashcat dumps')
PY

Encryption is two-way with a key. Encrypt(plaintext, K) → ciphertext. Decrypt(ciphertext, K) → plaintext. AES-GCM and ChaCha20-Poly1305 are the boring modern names for hiding bytes in transit or at rest when you have a key-management story. Anyone can hash; hashing is not a confidentiality control by itself. If you SHA-256 a file and email the digest, you did not hide the file. You produced a fingerprint others can recompute if they have the same bytes. If you SHA-256 a password and store only the hex, you hid the password from casual reading, but you did not encrypt it: there is no key to reverse the digest. Call it a stored verifier, not “encrypted password.” Confusing the two leads to bad designs and bad findings: people “encrypt” passwords with SHA-256 and think a stolen database is harmless, or they treat a hash as a secret that must never be published — while vendor checksums are supposed to be public so you can check a download. Use hashing when the job is verify or store-a-verifier. Use encryption when the job is hide bytes from someone who should not read them, and you can say where the key lives.

Asymmetric cryptography (RSA, ECDSA, TLS certificates in Lesson 2) is still a lockbox family: a public key may be published; a private key must not. This lesson does not re-teach AES modes or RSA math. It re-teaches the verbs so a student does not “graduate” into hashcat because a blog titled with a cert acronym said Module 20 is cryptanalysis. Authorized crypto work here is literacy plus YOUR bytes. Homebrew XOR, verify=False, and “broken ciphers to practice on classmates” stay refused. A CEH-shaped vocabulary does not create a cracking warrant.

In a report, “the application encrypts passwords with SHA-256” is a finding written by someone who failed this lesson. The accurate sentence is: the application stores a hash of the password — and raw SHA-256 without a unique salt and a slow KDF is a worse storage finding. Encryption would mean a key exists that turns ciphertext back into the password, which is a terrible way to store passwords. Password storage wants a slow salted hash (Argon2, bcrypt, scrypt — named in Topic 8). MFA is not a hash and not encryption: it is a second factor the surprise message or stolen table cannot complete. Skipping MFA because “we hashed the password” mixes three controls. Unique passwords kill stuffing. MFA survives a stolen password. None of those sentences is a hashcat lab.

Dumps, /etc/shadow, HaveIBeenPwned pastes, and “just a small wordlist against this hex I found” are out of this course the same way café nmap was out of Module 3. Skill does not create consent. A public breach dump is still other people’s secrets. Hashcat, John the Ripper, Hydra, and rainbow tables are named here so you can refuse them, not so you can install them. Topic 8’s optional “tiny list you wrote of a toy word you chose” was a feeling for why unsalted fast hashes of short words are guessable — your word, your list, your notes. It was never a license to attack a dump. Module 20 does not reopen that door. If a teammate pastes a shadow line into Discord as “CEH crypto,” you treat it like a secret in a report (Lesson 3): do not amplify, do not crack, lock your own notes without the stolen verifier.

The defender habit is: obtain expected SHA-256 from a trusted channel, hash the bytes you have, compare as strings. Mismatch → do not run the installer. Match → the bytes equal the published bytes, not “this is malware-free.” Inside an authorized test, the same primitive labels evidence you collected from systems in scope: a config export YOU were allowed to copy, a log snippet from YOUR lab listener, a file you authored for the lab. Hash the copy you stored under cyberlium-lab so you can later prove the bytes did not drift. That is chain-of-custody literacy, not a trophy of other people’s home directories. You may hash every file in cyberlium-lab because you created that tree. You may not hash a coworker’s laptop “to see.” You may not hash /etc/shadow “because it is a file.” Empty notes fail. Notes that contain other people’s hashes, shadow lines, or a paste from a breach dump fail ethics even if SHA-256 ran.

Carry Topic 7’s engineering: chunked update so large files fit in RAM, open(path, "rb"), hexdigest() or openssl dgst -sha256, notes in $HOME/cyberlium-lab, chmod 600. Do not hash the filename and call it file integrity. Do not “encrypt” a file by hashing it. Do not “hash” a file by running AES. Keep the verbs separate in notes you will actually reread when you write Lesson 3’s report hygiene. A useful feeling: the lesson is “too small” because you did not recover a plaintext from a hex. That feeling is how people leave literacy and enter unauthorized cracking. The skill is stopping. Lesson 4 will let you re-hash a file YOU created and recheck example.com certificate fields — still integrity and public documentation, still not hashcat.

A hash-versus-encrypt note is boring on purpose. Date (UTC). Hashing means one-way fixed-size fingerprint: deterministic, avalanche, no key, no decrypt. Encryption means lockbox: ciphertext returns to plaintext with the key. Password storage is a slow salted hash, not “encrypted SHA-256,” and MFA is a second factor — not a digest. Ethics: NEVER hashcat, NEVER John, NEVER Hydra, NEVER rainbow tables, NEVER /etc/shadow, NEVER HaveIBeenPwned, NEVER a classmate’s files. Legal line: original Cyberlium teaching mapped to the CEH v13 cryptography domain — not official EC-Council training, not a cert, not exam dumps. Notes path: $HOME/cyberlium-lab/hash-vs-encrypt-notes.txt, chmod 600. Empty files fail. Files that list dumped hashes fail even if you “only planned.” World-readable 777 fails.

Write two hexes you actually produced: SHA-256 of a known string you typed, and SHA-256 of a tiny file you authored. After a one-character edit, write the new file hex and MATCH/DIFFER. That is enough avalanche. Do not add a password list to make it “more crypto.” Do not paste a production key. Next lesson inspects TLS on the wire during a test — still no MITM. A cert acronym in a blog title is not a warrant to crack or intercept.

On a computer you own, create cyberlium-lab if needed, write a tiny text file you authored, print SHA-256 of a known string and of that file’s bytes. Change one character in the file, hash again, confirm the digest moved. Fill hash-vs-encrypt-notes.txt with both hexes, the avalanche observation, hashing ≠ encryption, the MFA/password-storage sentence, and the refuse line. Do not add a dump. Do not hash /etc/passwd “because it is a file.” chmod 600 the script, the demo file, and the notes. Windows: WSL, Git Bash, or py plus a restricted ACL on the notes.

You now treat hashing as a one-way fingerprint of bytes you own and encryption as a lockbox that needs a key. Password storage is a slow salted hash, not “encrypted SHA-256.” MFA is a second factor, not a digest. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 cryptography domain — not official EC-Council training, not a cert, not exam dumps. Next — TLS on the Wire During a Test — the padlock is not “the site is safe.” You inspect certificates on hosts in scope. example.com public cert literacy is allowed. MITM and fake CAs against others are not.