2.1.4. Encryption and Hashing
💡 First Principle: Encryption and hashing both make data unreadable to an outsider, but they solve different problems — encryption is reversible (you can get the original data back with the right key), which protects confidentiality of data you still need to use, while hashing is one-way (you can never get the original back), which protects integrity or stores secrets like passwords without ever storing the actual value.
| Property | Encryption | Hashing |
|---|---|---|
| Reversible? | Yes, with the correct key | No, one-way by design |
| Primary goal | Confidentiality | Integrity verification / secret storage |
| Typical use | Protecting data at rest or in transit | Storing passwords, verifying file integrity |
| Example | AES (symmetric), RSA (asymmetric) | SHA-256 |
| Key involved? | Yes — same key (symmetric) or key pair (asymmetric) | No key; same input always produces same output |
Symmetric encryption uses one shared key for both encrypting and decrypting — fast, but the key must be distributed securely. Asymmetric encryption uses a mathematically linked key pair — a public key anyone can use to encrypt, and a private key only the owner holds to decrypt — solving the key-distribution problem at the cost of speed, which is why real systems often use asymmetric encryption just to securely exchange a symmetric key.
⚠️ Exam Trap: You cannot "decrypt" a hash. If a scenario describes recovering an original password from a stored value, that value was encrypted (or, worse, stored in plain text) — not properly hashed.
Reflection Question: A website needs to verify a user's password at login without ever being able to leak the actual password if the database is stolen. Should it store the password encrypted or hashed, and why?
