# Encryption vs Hashing

> Encryption protects confidentiality while allowing authorized recovery of the original data; cryptographic hashing produces a one-way digest for comparison or verification. Choose encryption when you must read the data later, and choose hashing when you only need to verify it, using a dedicated password-hashing algorithm for passwords.

Source: https://sysround.com/compare/encryption-vs-hashing
Updated: 2026-11-05


## Side by side

| | Encryption | Hashing |
|---|---|---|
| Primary purpose | Keep recoverable data confidential | Produce a digest for comparison or verification |
| Recover original input | Yes, with the appropriate decryption key | No decryption operation; guesses can still be tested |
| Keys and secrets | Requires encryption and decryption key management | Ordinary hashes are unkeyed; HMAC uses a secret |
| Output | Ciphertext plus scheme-specific metadata | Fixed-size digest for a chosen hash algorithm |
| Repeated inputs | Secure randomized schemes avoid revealing equality | Same input produces the same digest |
| Typical choices | AES-GCM or ChaCha20-Poly1305 for payloads | SHA-256 for content; Argon2id for passwords |
| Integrity guarantees | Authenticated encryption detects tampering | A bare hash needs a trusted reference digest |
| Main operational concern | Key access, rotation, availability, and nonce safety | Input encoding, guessing attacks, and collision handling |

## The differences that matter

Start with whether the system needs the original value. A shipping service must recover a delivery address, so encrypting it can protect stored data while preserving that capability. A login service should verify a password without recovering it, so store a salted password hash instead. Hashing does not make predictable inputs secret: attackers can enumerate likely phone numbers or email addresses and compare digests.

Encryption adds a key-management dependency. Explain who can decrypt, where keys live, how services obtain access, and what happens during a key-service outage. Envelope encryption lets a data key encrypt the payload while a key-management service protects that data key. Key rotation must distinguish rewrapping data keys from re-encrypting payloads; neither should be assumed to happen automatically.

General-purpose cryptographic hashes and password hashes solve different problems. SHA-256 is designed to process data efficiently, which is useful for file verification but also makes password guessing efficient. Argon2id uses configurable memory and computation to make each password guess more expensive. Store a unique random salt and algorithm parameters with each password hash, and size login capacity around the chosen cost.

Integrity requires a trust boundary, not just a digest. An attacker who can replace both a file and its stored hash can make the comparison pass. Use a trusted digest, an HMAC with a shared secret, or a digital signature, depending on who must verify the data. For encrypted payloads, authenticated encryption protects both confidentiality and integrity; encryption without authentication is not enough.

## Choose Encryption when

- The application must recover private information later, such as delivery addresses, documents, or credentials for an external integration.
- You need to protect data crossing a network. Use TLS rather than designing a custom transport-encryption protocol.
- You need end-to-end encrypted messages that only participating clients can decrypt, accepting the resulting constraints on server-side search and recovery.
- You need confidentiality for database records, objects, replicas, or backups, with explicit rules for who can access decryption keys.

## Choose Hashing when

- You must verify user passwords without storing a recoverable password. Use a dedicated password-hashing algorithm such as Argon2id.
- You need to verify downloaded files or transferred chunks against cryptographic digests obtained through a trusted channel.
- You need content fingerprints for deduplication or content-addressed storage, with a collision policy appropriate to the correctness requirement.
- You need efficient comparisons of large datasets, such as Merkle-tree-based synchronization, without comparing every byte on every check.

## Worked example: A file-sync service needs both

Suppose a file-sync service stores 10 million objects and transfers files in 4 MiB chunks. It needs to recover every stored file, so hashing cannot replace encryption. Encrypt objects with authenticated encryption and protect their data keys through a key-management service. Separately, compute SHA-256 digests of plaintext chunks to detect unchanged content and verify transfers against trusted metadata. Computing fingerprints over randomized ciphertext would usually miss identical plaintext uploaded twice. Plaintext fingerprints also reveal equality, so scope deduplication to an appropriate tenant boundary. If the system requires exact equality before sharing storage, compare bytes after a digest match rather than treating the digest as mathematical proof.

## In the interview

- State the threat model before naming an algorithm: are you protecting against stolen disks, a database dump, network interception, or a compromised application? Storage encryption does not prevent a compromised service from reading data it is authorized to decrypt.
- Describe the full data path. Identify where plaintext exists, which services can decrypt it, whether caches and logs contain sensitive values, and how backups are protected. Expect probes about key rotation, recovery, and access auditing.
- For login, explain salts, password-hash cost, and capacity together. Expensive verification also consumes resources during attacks, so discuss rate limiting, bounded concurrency, and upgrading hash parameters after successful authentication.
- For file verification or deduplication, explain where the expected digest comes from and what happens on a match. Expect follow-ups about untrusted uploaders, cross-tenant equality leakage, and whether exact byte comparison is required before merging objects.

## Common mistakes

- Calling hashing encryption or claiming a hash can be decrypted. Hashes have no decryption key, but low-entropy inputs can still be discovered through guessing.
- Storing passwords with reversible encryption or a single fast SHA-256 operation. Password storage needs a salted, deliberately expensive password-hashing function.
- Treating a bare digest as proof of authenticity. If an attacker can replace the data and digest, use a trusted reference, HMAC, or signature to establish trust.
- Assuming encryption removes the need for authorization, or that hashing personal data makes it anonymous. Authorized plaintext access still needs controls, and predictable values remain guessable.

## Interview questions where it comes up

- [Design a login and authentication system](https://sysround.com/questions/design-authentication-system): Password hashing, encrypted recoverable secrets, and verification cost are central to secure login and account recovery.
- [Design a chat app like WhatsApp](https://sysround.com/questions/design-whatsapp): End-to-end encryption changes key distribution, message recovery, and the server's ability to inspect or search messages.
- [Design Dropbox or Google Drive](https://sysround.com/questions/design-dropbox): Encrypted file storage and content hashes serve separate roles in confidentiality, chunk deduplication, and transfer verification.
- [Design BitTorrent](https://sysround.com/questions/design-bittorrent): Peers need trusted content digests to verify chunks received from untrusted participants, independently of transport encryption.
- [Design a large data migration to the cloud](https://sysround.com/questions/design-cloud-data-migration): Encryption protects data in transit while independently computed digests help verify that the destination received the intended bytes.

## FAQ

### Is hashing more secure than encryption?

Neither is universally more secure because they provide different properties. Encryption protects recoverable data from readers without the key, while hashing supports comparison without a decryption operation. An unkeyed hash is not a confidentiality mechanism for predictable inputs.

### Should passwords be encrypted or hashed?

Store passwords using a salted password-hashing algorithm such as Argon2id, not reversible encryption. Store the salt and cost parameters alongside the hash, and tune the cost for your infrastructure and latency budget. A separately protected pepper can add defense in depth, but it does not replace salts or password hashing.

### What is the difference between hashing, encryption, and encoding?

Encryption requires a key to recover plaintext, while cryptographic hashing produces a one-way digest. Encoding, such as Base64, changes representation and can be reversed without a secret. Base64 does not protect sensitive data, and a signed JWT is not necessarily encrypted.

## Related concepts

- [TLS and HTTPS](https://sysround.com/concepts/tls)
- [End-to-end encryption](https://sysround.com/concepts/end-to-end-encryption)
- [Access control and RBAC](https://sysround.com/concepts/access-control)
- [Data deduplication and chunking](https://sysround.com/concepts/data-deduplication)
- [Merkle trees](https://sysround.com/concepts/merkle-tree)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.