Overview
Two operations sit at the heart of almost every cryptography challenge: encryption and hashing. They look similar — both turn readable data into scrambled-looking output — but they solve opposite problems. Encryption is reversible: with the right key you get the original data back. Hashing is one-way: you cannot recover the input from the output by design. Confusing the two is one of the most common mistakes in both CTFs and real software, so this lesson draws a clear, accurate line between them.
Learning objectives
- Define encryption and hashing and state the goal of each.
- Explain why encryption is reversible and hashing is not.
- Distinguish both from encoding, which provides no security at all.
- Recognize which tool fits confidentiality versus integrity/verification.
Core concept
Encryption transforms plaintext into ciphertext using an algorithm and a key. The transformation is designed to be reversible: whoever holds the correct key can run decryption and recover the exact original plaintext. Its purpose is confidentiality — keeping data readable only to those with the key.
Hashing runs input through a one-way function that produces a fixed-length digest. It is deterministic (the same input always yields the same digest) but not reversible: there is no key and no decrypt step that turns a digest back into its input. A secure cryptographic hash is also collision-resistant (hard to find two inputs with the same digest) and preimage-resistant (given a digest, hard to find any input that produces it). Its purpose is integrity and verification — proving data has not changed, or checking a secret without storing it in the clear.
A third thing is often mistaken for these: encoding (such as Base64 or hex). Encoding just re-represents data in another alphabet. It uses no key, hides nothing, and is trivially reversible by anyone. Encoding is not a security mechanism.
How it works
- Encryption takes
(plaintext, key)and outputs ciphertext. Decryption takes(ciphertext, key)and returns the plaintext. Change the key and the output changes; without the key, recovering the plaintext should be infeasible. Examples of encryption algorithms include AES (symmetric) and RSA (asymmetric). - Hashing takes
(input)and outputs a fixed-size digest — for example, a SHA-256 digest is always 256 bits regardless of input length. There is no key parameter and no inverse function. You verify data by hashing it again and comparing digests. - Encoding takes
(data)and outputs a re-encoded form using a fixed, public scheme; anyone can decode it with no secret.
A quick way to tell them apart: if there is a key and you can get the original back, it is encryption. If the output is fixed-length and there is no way back, it is a hash. If it just looks like a different alphabet and reverses instantly, it is encoding.
Practical example
Consider how a well-built application stores user passwords. It does not encrypt them, because encryption is reversible — anyone who steals the database and the key could recover every password. Instead it hashes each password with a slow, salted password-hashing function (such as bcrypt or Argon2) and stores only the digest. At login, the app hashes the entered password the same way and compares digests. The plaintext password is never stored and cannot be recovered from the digest.
Now consider sending a confidential file to a teammate. Hashing would be useless here — the teammate needs to read the file, so the transformation must be reversible. The right tool is encryption: encrypt the file with a key you share securely, and the teammate decrypts it with that key.
In an isolated CTF crypto challenge you might be handed a string and asked to recover a flag. Recognizing whether you are looking at a hash (crack it by hashing candidate inputs and comparing), ciphertext (find or derive the key and decrypt), or mere encoding (just decode it) determines your entire approach.
Cybersecurity relevance
Choosing encryption versus hashing correctly is a real-world security decision with real consequences. Passwords, API tokens, and file checksums rely on hashing; confidential data at rest and in transit relies on encryption. Getting it backwards — encrypting passwords so they can be decrypted, or "hashing" data you actually need to read back — creates serious vulnerabilities. In CTFs, the crypto category constantly tests whether you can identify what a blob of data really is: a digest, a ciphertext, or just Base64. That identification skill maps directly to analyzing real systems, where knowing whether a value can be reversed tells you how sensitive it is and how it must be protected.
Common mistakes
- Treating encoding as security. Base64 or hex "hides" nothing; anyone can decode it instantly.
- Encrypting passwords instead of hashing them, leaving them recoverable if the key leaks.
- Using a fast general-purpose hash (MD5, SHA-1, plain SHA-256) for passwords — these are built for speed, which helps attackers guess billions of candidates; use a slow, salted password hash (bcrypt, scrypt, Argon2).
- Assuming a hash can be "decrypted." It cannot; cracking a hash means guessing inputs and comparing digests, not reversing a function.
- Confusing a digest with a key or a ciphertext when analyzing an unknown value.
Key takeaways
- Encryption is reversible with a key and provides confidentiality; hashing is one-way and provides integrity/verification.
- A secure hash is deterministic, fixed-length, collision-resistant, and preimage-resistant, and has no decrypt operation.
- Encoding (Base64, hex) is not security — it has no key and reverses trivially.
- Store passwords as salted, slow hashes; use encryption only for data you must be able to read back.
Check your understanding
- Why can a hash never be "decrypted," while ciphertext can be decrypted?
- A developer says they "encrypted" passwords so they can email them to users who forget them. What is wrong with this, and what should they have done instead?