One-way encryption is an informal name for cryptographic hashing. A hash function accepts input of arbitrary length and produces a fixed-length value called a hash, digest, or fingerprint. It has no decryption key. A secure hash is designed so that finding an input for a chosen digest, or finding two different inputs with the same digest, is computationally infeasible.
The word “encryption” can be misleading here. Encryption is intentionally reversible for someone who has the correct key. Hashing is designed for comparison and integrity, not for recovering the original content.
Hashing, encryption, encoding, and HMAC
| Operation | Reversible? | Typical purpose |
|---|---|---|
| Cryptographic hashing | No practical reverse operation | Integrity, fingerprints, signature workflows |
| Encryption | Yes, with the correct key | Confidentiality for data that must later be read |
| Encoding | Yes, without a secret | Represent data in a compatible format, such as Base64 |
| HMAC | Not reversed; requires a secret key to reproduce | Integrity and authenticity between parties sharing a key |
| Password hashing or KDF | Verified by testing guesses | Store password verifiers with deliberate cost |
Encoding is not security. Anyone who knows the encoding can decode it. A plain hash also does not prove who created a message; an attacker can alter a file and calculate a new unkeyed hash. Authenticity requires a trusted hash source, HMAC, or digital signature.
Security properties of a cryptographic hash
- Preimage resistance: given a digest, finding any input that produces it should be impractical.
- Second-preimage resistance: given one message, finding a different message with the same digest should be impractical.
- Collision resistance: deliberately finding any two distinct inputs with the same digest should be impractical.
- Avalanche behavior: a small input change should produce a substantially different-looking digest.
“One-way” does not mean mathematically impossible to guess. An attacker can hash likely inputs and compare the results. Low-entropy data such as common passwords, short PINs, and predictable identifiers remain vulnerable to guessing.
How password hashing should work
Passwords should not be stored with reversible encryption or a fast general-purpose hash alone. A service stores a verifier produced by a dedicated, deliberately expensive password-hashing function. During login, it applies the same parameters to the submitted password and compares the result.
- Use a modern function such as Argon2id; use scrypt or an appropriately configured alternative when required by the platform or compliance rules.
- Generate a unique random salt for every password. Salts are not secret; they prevent reuse of precomputed tables and identical hashes for identical passwords.
- Tune memory and work cost for the deployment and increase it over time.
- Optionally use a pepper stored separately in a secrets vault or HSM as defense in depth.
- Use constant-time comparison and a mature library rather than custom cryptography.
Fast hashes such as MD5, SHA-1, and unsalted SHA-256 are unsuitable for password storage because attackers can test guesses rapidly. See why SHA-1 is obsolete for collision-sensitive uses.
Common uses and limits
- Download verification: compare a file’s SHA-256 digest with one obtained through a trusted publisher channel.
- Digital signatures: systems commonly sign a digest rather than the entire message directly.
- Content addressing and deduplication: use hashes to identify content, while considering collision and privacy requirements.
- Password verification: use a password-specific function, salt, and cost—not a bare file hash.
A matching download hash confirms that two byte sequences match; it does not make an untrusted publisher trustworthy. If an attacker controls both the file and the web page displaying its hash, the comparison offers little protection.
Frequently asked questions
Can a hash be decrypted?
No decryption key exists. Attackers instead guess possible inputs, hash them, and look for a match. Strong input and an appropriate password-hashing cost make that process harder.
When should I use encryption instead?
Use encryption when an authorized recipient must recover the original data, such as stored documents or an encrypted file transfer. Protect and rotate the keys separately from the encrypted data.