Encryption, hashing and HMAC all use cryptographic functions, but they solve different problems. Choosing between them starts with one question: what do you need to protect or verify?
- use encryption when information must remain confidential and later be recovered;
- use hashing to create a reproducible fingerprint;
- use HMAC to verify a message with a shared secret;
- use a key derivation function such as PBKDF2 when deriving a value from a password.
Encryption protects confidentiality
Encryption transforms readable data into ciphertext using a key. With the correct key and required parameters, the operation can be reversed.
AES is a symmetric encryption algorithm. The AES encrypt/decrypt tool lets you explore this model directly.
Encryption is appropriate when an application needs to recover the original value. A hash is not a replacement because it is not designed to be decrypted.
Hashing creates a fingerprint
A hash function turns an input into a fixed-size digest. The same input with the same algorithm produces the same result.
This makes hashes useful for comparing files or checking expected values. The hash generator and hash comparison tool cover these workflows.
Hashing alone does not prove that a digest was created by an authorized party. Someone able to replace both the data and its digest may calculate a new pair.
HMAC combines a hash with a secret
HMAC uses a hash function together with a secret key. Parties sharing that secret can calculate and verify a message authentication code.
The HMAC generator and verifier demonstrates the difference: knowing the message is not enough; the shared secret is also required.
HMAC does not hide the message. It addresses integrity and authenticity, not confidentiality.
PBKDF2 is more than a single password hash
General-purpose hash functions are intentionally fast. That property makes repeated password guessing inexpensive.
PBKDF2 repeatedly applies a pseudorandom function with a salt and an iteration count, increasing the work required for each attempt. The PBKDF2 password tool shows the role of the password, salt, iterations and output length.
A salt is not an extra password. It can be stored with the derived value and helps prevent identical passwords from systematically producing identical stored results.
Which mechanism should you use?
| Need |
Suitable mechanism |
Reversible? |
Secret required? |
| Hide data and recover it later |
AES encryption |
Yes |
Yes |
| Produce a fingerprint |
Hash |
No |
No |
| Verify a message with a shared secret |
HMAC |
No |
Yes |
| Derive a value from a password |
PBKDF2 |
No |
Password |
These mechanisms can coexist in one system. An application may encrypt confidential data, authenticate exchanges with HMAC and use an appropriate password derivation method for credentials.
Common mistakes
Encoding is not encryption. Base64 changes representation but provides no confidentiality.
Hashing is not encryption. A digest is not ciphertext waiting to be decrypted.
HMAC does not hide a message. It authenticates a value using a secret.
Passwords should not normally be stored as decryptable application data. When a service only needs to verify a password, it should use a password-storage mechanism designed for that purpose.
For the broader context, continue with Web security: essential protections.