Developer tools · SHA hash calculator
Cryptographic Hash vs Checksum: What CRC32 and xxHash Can't Promise
· Background
sha-256 cryptography security
CRC32, FNV and xxHash are hashes too, but they make no promise against an adversary. This post explains what separates cryptographic hashes from checksums and how to pick per use case.
Which hash for which job? — the choice between speed and adversarial safety
Hash functions come in three categories: checksums for detecting accidental errors, non-cryptographic hashes for distribution and performance, and cryptographic hashes for security. Each category has different guarantees and different trade-offs in speed and digest size. A checksum like CRC32 is fast and short (4 bytes, 8 hex characters) but offers no protection against intentional modification. A non-cryptographic hash like xxHash or MurmurHash is also fast and is useful for hash tables and data distribution, but offers no protection against an adversary who wants to cause a collision. A cryptographic hash like SHA-256 is slower and produces a longer digest (32 bytes, 64 hex characters), but it offers preimage resistance and collision resistance—security properties that protect against an adversary.
Choosing the wrong hash function for your use case is a common security mistake. Using CRC32 to verify file downloads from an untrusted source is ineffective; an attacker can easily modify the file and recompute the CRC32. Using SHA-256 as a fast hash function in a high-frequency hash table is wasteful; CRC32 or a fast non-cryptographic hash is sufficient and cheaper.
Checksums for accidental errors — CRC's design for detecting bit flips in transmission
Checksums are designed for error detection during transmission or storage, where errors are assumed to be random and accidental. CRC (Cyclic Redundancy Check) was originally designed for detecting bit flips in communication. A CRC32 produces a 32-bit digest. If a frame is corrupted by random bit flips during transmission, the CRC32 will almost certainly change, alerting the receiver to request retransmission. CRC can detect up to a certain number of bit errors depending on the polynomial; for most common use cases, a single bit flip or a burst of a few bit flips is detected reliably.
CRC is deterministic but not cryptographic. Given a file and its CRC32, an attacker can modify the file and recompute the CRC32 to match the expected value. For an adversary with knowledge of the CRC polynomial, manufacturing a collision is straightforward. CRC was never intended to resist intentional modification; it is purely for accidental error detection. Historical systems like ZIP files and JPEG files use CRC for this purpose. Modern protocols use CRC for fast error detection within encrypted or authenticated channels, not as a standalone integrity check.
Non-cryptographic hashes for distribution — FNV, MurmurHash and xxHash in hash tables and partitioning
Non-cryptographic hashes like FNV-1a, MurmurHash and xxHash are designed for speed and uniformity in hash tables and data partitioning. They have very low latency and are used in situations where you need to partition data across servers or buckets without caring about security properties. If you are building a cache and need to map a key to a bucket number, a fast hash is appropriate. MurmurHash was designed explicitly for hash table use and is faster than SHA on most hardware. xxHash is newer and optimizes for modern CPUs with large caches and vectorization.
These hashes are not cryptographic because they do not resist preimage attacks (finding an input that produces a specific digest) or collision attacks (finding two different inputs that produce the same digest). An attacker can compute the hash algorithm and find inputs that collide or that produce a target output. Within a trusted environment (a cluster where all nodes are under your control), that is acceptable. If an untrusted user can control the input, a non-cryptographic hash is vulnerable to collision attacks that degrade performance (hash table worst case is linear search when all keys collide) or produce other side effects.
What cryptographic hashes add — preimage and collision resistance against a deliberate attacker
Cryptographic hashes like SHA-256, SHA-384 and SHA-512 provide preimage resistance: given a digest, it is computationally infeasible to find any input that produces that digest. They also provide collision resistance: it is computationally infeasible to find two different inputs that produce the same digest. These properties protect against an adversary who wants to forge a download, create a fake certificate or tamper with a message. The cost is speed: SHA-256 is slower than CRC32 and slower than xxHash on most hardware.
SHA-1 is cryptographically broken (collisions are practical) and should not be used for new security purposes, but it is still computed for legacy compatibility. SHA-256, SHA-384 and SHA-512 remain strong and are the standard choices for cryptographic hashing. The "2" in SHA-2 indicates the second family of SHA algorithms (the first being the original SHA-1; SHA-3 is a newer family but is rarely used for this purpose).
Cryptographic hashes add adversarial properties; this article avoids unsupported relative-speed claims
Matching five scenarios to the right hash family: First, network frames transmitted over a reliable channel encrypted with AES: CRC32 is appropriate. The encryption protects against modification, and the CRC detects accidental corruption. Second, hash tables or consistent hashing for load balancing: a non-cryptographic hash like xxHash is appropriate. Speed matters, and the environment is trusted. Third, verifying download integrity from an untrusted source: SHA-256 is required. An attacker could modify the file and the checksum, but not the cryptographic hash without breaking SHA-256.
Fourth, digital signatures and certificates: SHA-256 is required and is combined with an asymmetric algorithm like RSA or ECDSA. The signature proves the hash was not modified after signing. Fifth, deduplicating user-uploaded files: SHA-256 is required because users could deliberately upload files designed to collide with existing files in a non-cryptographic hash. If deduplication is based on xxHash, an attacker can upload a file with the same hash as another file but different content, causing the system to discard the upload incorrectly.
Worked example — matching five scenarios (network frames, hash maps, download verification, signatures, deduplication of user uploads) to the right family
The cost of choosing a cryptographic hash for every use case is performance overhead. SHA-256 is slower than CRC and slower than xxHash. In a hot loop—a piece of code that executes millions of times per second—that overhead is noticeable. In a setup phase or in a batch operation, it is negligible. The decision framework is: does an adversary have an incentive to cause a collision? If yes, use SHA-256. If no, and if speed is important, use a faster hash. If security is more important than speed, use SHA-256 regardless.
A common mistake is using MD5, an older cryptographic hash that is now broken. MD5 was designed in 1992 and collisions were demonstrated in 2004. Using MD5 for any security purpose is unsafe. It is sometimes seen in legacy systems and in situations where speed is prioritized, but there is no scenario where MD5 is the right choice today: if you need speed, use xxHash; if you need security, use SHA-256. Never use MD5.
Scenario mapping stays qualitative because throughput and collision behavior need implementation-specific evidence
Password hashing is a fourth category, distinct from both checksums and general-purpose cryptographic hashes. Do not use SHA-256 to hash passwords. Instead, use a password hashing function like bcrypt, scrypt or Argon2, which are deliberately slow and include a salt. A fast cryptographic hash like SHA-256 makes password guessing cheap: an attacker can try millions of guesses per second. A password hashing function is designed to make each guess expensive in CPU and memory, so guessing a strong password still takes longer than any attacker can wait. Password hashing is a specialized use case with its own requirements.
The ToolAcre SHA hash calculator does not support password hashing and deliberately offers no MD5, no custom parameters and no fast hashes. It is a tool for computing standard SHA digests for verification and integrity checking, not for authentication or password storage.
Takeaway: adversary or no adversary — reach for the ToolAcre SHA hash calculator when someone might tamper with the data
The hash algorithm choice is a fundamental decision that affects both performance and security throughout a system. A digest is only as trustworthy as the algorithm that produced it. If you choose CRC32 for file verification, the digest provides no protection against intentional modification. If you choose SHA-256 for a hash table, you are wasting resources. Knowing the properties and trade-offs of each category allows you to choose correctly.
The ToolAcre SHA hash calculator provides SHA-1 through SHA-512, covering the cryptographic hashes that matter for most use cases. It does not offer CRC32, xxHash or MD5 because each of those is the right choice in specific contexts (CRC for error detection in a trusted channel, xxHash for performance in a controlled environment, nothing for MD5), and offering them without emphasizing when to use each would encourage mistakes. The calculator is for computing standard cryptographic digests. Use the command line with `crc32`, `xxh64` or equivalent tools if you need those hashes. For download verification, certificate fingerprints, git commits and similar use cases where an adversary might tamper with the data, reach for SHA-256 via the ToolAcre SHA hash calculator.