CRC-64 (Cyclic Redundancy Check 64-bit) is a high-precision error-detection algorithm that produces a 64-bit (16 hexadecimal character) checksum used to verify data integrity in file systems, databases, and archival formats. Unlike CRC-32 which produces 32-bit checksums, CRC-64 provides significantly better error detection for large datasets with a collision probability of 1 in 2^64 (approximately 1 in 18 quintillion) compared to CRC-32's 1 in 2^32 (about 1 in 4 billion). CRC-64 is used in the XFS file system, ZFS checksumming, Go programming language's hash/crc64 package, and various scientific data archival systems. Like CRC-32, it uses polynomial division mathematics to detect accidental data corruption from transmission errors, disk failures, or memory glitches. Standard variants include CRC-64/ECMA-182 (polynomial 0x42F0E1EBA9EA3693) and CRC-64/ISO-3309 used in different applications. CRC-64 is NOT cryptographically secure and should never be used for passwords, digital signatures, or security applications—it is designed purely for detecting accidental corruption, not malicious tampering. The larger 64-bit output makes it ideal for applications requiring very low collision probability when verifying large datasets or long-term archival data.

How does CRC-64 differ from CRC-32?

The primary difference is output size and collision probability. CRC-64 produces 64-bit (16 hex character) checksums with collision probability of 1 in 2^64, while CRC-32 produces 32-bit (8 hex character) checksums with collision probability of 1 in 2^32. This means CRC-64 is approximately 4 billion times less likely to produce false matches, making it far better for large datasets. For a dataset with 1 million files, CRC-32 has significant collision risk while CRC-64 collision probability remains negligible. CRC-64 uses a larger generator polynomial (64-bit vs 32-bit), requiring more computation per byte but providing stronger error detection. Performance-wise, CRC-64 is slightly slower than CRC-32 due to larger register operations, but still very fast compared to cryptographic hashes. CRC-32 is ubiquitous in ZIP files, Ethernet, PNG images where legacy compatibility and maximum speed matter. CRC-64 is used in modern systems like XFS/ZFS file systems, scientific data archival, and Go language where better error detection justifies the minimal performance cost. Both are non-cryptographic and vulnerable to intentional collision attacks. Choose CRC-32 for legacy compatibility and maximum speed with smaller datasets. Choose CRC-64 for large datasets, long-term archival, or systems requiring very low collision probability.

Where is CRC-64 used?

CRC-64 is primarily used in systems managing large datasets where CRC-32's collision probability becomes unacceptable. The XFS file system (default in Red Hat Enterprise Linux) uses CRC-64 for metadata verification to detect disk corruption. ZFS file system uses CRC-64 (along with SHA-256 for critical data) for block checksumming. The Go programming language includes CRC-64 in its standard library (hash/crc64 package) with both ECMA and ISO polynomial variants. Scientific data archival systems use CRC-64 for long-term data integrity verification where collision probability must be minimized over decades. Large databases use CRC-64 for table checksums and data verification. Network protocols requiring better error detection than CRC-32 for large transfers implement CRC-64. Storage systems managing petabyte-scale data use CRC-64 to avoid false positives in corruption detection. Some backup and archival software uses CRC-64 for verifying large file collections. Bioinformatics applications use CRC-64 for verifying genomic data integrity. While less ubiquitous than CRC-32, CRC-64 is the standard choice in modern systems where data size or longevity makes CRC-32's collision probability unacceptable. The performance overhead versus CRC-32 is minimal on modern hardware, making CRC-64 increasingly preferred for new implementations requiring non-cryptographic checksums.

Why use CRC-64 over CRC-32?

Use CRC-64 when collision probability matters more than legacy compatibility. For large file collections (millions of files), CRC-32 has significant collision risk while CRC-64 remains negligible. When checksumming large individual files (gigabytes or terabytes), CRC-64 provides better error detection with lower false negative probability. For long-term data archival spanning years or decades, CRC-64's lower collision rate reduces the chance of undetected corruption over time. In database systems managing billions of records, CRC-64 provides more reliable integrity verification. For deduplication systems that rely on checksums to identify unique data, CRC-64 reduces false positives that could cause data loss. Modern file systems like XFS and ZFS choose CRC-64 because the performance difference versus CRC-32 is negligible on modern CPUs, but the reliability improvement is substantial. When designing new systems without legacy compatibility requirements, CRC-64 is often the better default choice. However, stick with CRC-32 when you need compatibility with ZIP files, PNG images, Ethernet protocols, or existing systems. CRC-32 is also slightly faster for small data where collision probability is not a concern. For security-critical applications, skip both CRC-32 and CRC-64 in favor of cryptographic hashes like SHA-256 or BLAKE3 which prevent intentional collisions.

What's the collision probability of CRC-64?

CRC-64 has a collision probability of approximately 1 in 2^64, or roughly 1 in 18.4 quintillion (18,446,744,073,709,551,616). This means if you randomly generate two different pieces of data, the probability they produce the same CRC-64 checksum is astronomically small. Using the birthday paradox, you would need to compute CRC-64 for approximately 5 billion different inputs before having a 50% chance of finding a single collision. For practical applications, this collision probability is effectively zero for accidental data corruption scenarios. If you have a file system with 1 million files, the probability of any two files having the same CRC-64 purely by chance is negligible. Even with 100 million files, collision probability remains extremely low. Compare this to CRC-32 where collision becomes likely with just 77,000 random inputs. However, these statistics only apply to random data and accidental collisions—attackers can still trivially create intentional CRC-64 collisions because it lacks cryptographic properties. For security purposes, collision probability is irrelevant since CRC-64 provides zero protection against malicious data modification. The low collision probability makes CRC-64 excellent for detecting accidental corruption, identifying duplicate files, or verifying data integrity in non-adversarial environments where its 64-bit output provides a much stronger guarantee than CRC-32's 32-bit output.

Is CRC-64 slower than CRC-32?

Yes, CRC-64 is slightly slower than CRC-32 due to operating on 64-bit values instead of 32-bit, but the difference is often negligible on modern 64-bit processors. On 64-bit CPUs, CRC-64 operations are native and the performance gap is minimal—perhaps 10-20% slower in practice. On 32-bit processors, CRC-64 requires emulating 64-bit operations with multiple 32-bit instructions, making it noticeably slower. Both algorithms can use lookup table optimizations to achieve gigabyte-per-second throughput. Typical CRC-64 implementations achieve 500 MB/s to 2 GB/s on modern CPUs, while CRC-32 might reach 1-4 GB/s. The performance difference is much smaller than the gap between CRC algorithms and cryptographic hashes—SHA-256 typically runs at 200-400 MB/s, making both CRC-32 and CRC-64 significantly faster for non-cryptographic use cases. For most applications, CRC-64's performance is more than adequate, and the bottleneck is usually disk or network I/O rather than checksum calculation. Hardware acceleration exists for CRC-32 in some processors but is rarer for CRC-64. When processing large files, the improved collision probability of CRC-64 often justifies the small performance cost. Only in extremely performance-sensitive applications where every CPU cycle matters and collision probability is acceptable should you choose CRC-32 purely for speed. Modern systems like XFS file system use CRC-64 precisely because the reliability gain outweighs the minimal performance cost.

Can CRC-64 detect all errors?

CRC-64 provides excellent error detection but cannot catch all possible errors. It detects all single-bit errors, all double-bit errors, any odd number of bit errors, all burst errors of 64 bits or less, and most longer burst errors with extremely high probability (1 - 2^-64). For random corruption patterns typical of transmission errors, disk failures, or memory glitches, CRC-64 detection rate is 99.9999999999999999% (eighteen nines). However, specific error patterns involving 64+ bits in precise positions could theoretically evade detection. The larger 64-bit checksum makes undetected errors exponentially less likely than with CRC-32. CRC-64 completely fails for intentional corruption—attackers can craft malicious data with identical CRC-64 values using polynomial mathematics or brute force, making it useless for security. Multiple bit flips in carefully calculated positions can bypass detection. For critical data where even one in 18 quintillion undetected errors is unacceptable, use cryptographic hashes like SHA-256 or multiple redundant checksums. For practical non-adversarial scenarios involving accidental corruption, CRC-64 provides industry-leading reliability. Its error detection properties are mathematically well-defined and superior to CRC-32, Adler-32, or other non-cryptographic checksums. Use CRC-64 when you need better error detection than CRC-32 but do not require cryptographic security. For security-critical applications, CRC-64 is completely inadequate—use SHA-256 or stronger cryptographic hashes instead.

Is CRC-64 secure for passwords?

Absolutely not! Never use CRC-64 for passwords or any security-sensitive application. CRC-64 is not a cryptographic hash and provides zero security despite having a larger output than CRC-32. Attackers can instantly compute CRC-64 collisions—creating different inputs that produce identical checksums—making password verification trivial to bypass. CRC-64 is designed for error detection, not security, and has no resistance to preimage attacks (finding input matching a given CRC-64), collision attacks (finding two inputs with same CRC-64), or brute force attacks. The 64-bit output provides only 18 quintillion possible values, which sounds large but is trivial for attackers to search—modern GPUs can compute billions of CRC-64 hashes per second, making exhaustive search feasible. CRC-64 has no concept of salting, key stretching, or other security mechanisms needed for password hashing. For passwords, use specialized algorithms like bcrypt, Argon2, scrypt, or PBKDF2 which are designed to resist attacks through intentional computational slowness and memory requirements. For general cryptographic hashing, use SHA-256, SHA-3, or BLAKE3. CRC-64 should only be used for fast integrity verification in non-adversarial contexts like file systems, databases, or archival systems where you need to detect accidental corruption, not prevent malicious tampering. Using CRC-64 for security is a critical vulnerability that will be exploited immediately. The larger output versus CRC-32 provides no security benefit—both are equally vulnerable to attack.

Which CRC-64 variant is most common?

The two main CRC-64 variants are CRC-64/ECMA-182 and CRC-64/ISO-3309, each using different polynomials and producing different checksums for the same data. CRC-64/ECMA-182 (also called CRC-64/ECMA) uses polynomial 0x42F0E1EBA9EA3693 and is the most widely used variant, appearing in the Go programming language standard library, various scientific applications, and data archival systems. CRC-64/ISO-3309 uses polynomial 0x000000000000001B and is specified in the ISO 3309 standard. The XFS file system uses its own CRC-64 variant optimized for file system operations. When someone refers to CRC-64 without specifying a variant, they typically mean CRC-64/ECMA-182 which has become the de facto standard. Different variants produce completely different checksums—verifying a CRC-64 value requires using the exact same variant that generated it. Most CRC-64 calculator tools should specify which variant they implement, with ECMA-182 being the most common default. If you are implementing CRC-64 for a new system, use ECMA-182 unless you have specific compatibility requirements. Some implementations also vary in initialization value (typically 0xFFFFFFFFFFFFFFFF or 0x0000000000000000) and final XOR (typically 0xFFFFFFFFFFFFFFFF or none), so full specification includes polynomial, init value, and final XOR. Always document which CRC-64 variant you use to ensure interoperability.

CRC-64 vs SHA-256 for integrity?

CRC-64 and SHA-256 serve different purposes in integrity verification. CRC-64 is for fast error detection against accidental corruption—use it when verifying data against transmission errors, disk failures, or storage issues. SHA-256 is for security—use it when verifying data against malicious tampering or authenticating downloads. CRC-64 produces 64-bit (16 hex character) checksums and runs at hundreds of megabytes to gigabytes per second. SHA-256 produces 256-bit (64 hex character) hashes and runs at 200-400 MB/s. CRC-64 can be attacked easily—attackers create collisions trivially. SHA-256 provides strong collision resistance with no known practical attacks. CRC-64 is used in XFS/ZFS file systems, databases, and archival systems for speed. SHA-256 is used in SSL certificates, digital signatures, blockchain, and security-critical verification. For detecting bit rot in file systems or verifying database integrity, use CRC-64. For verifying software downloads, security updates, or detecting tampering, use SHA-256. Some systems use both—CRC-64 for fast continuous integrity checking and SHA-256 for security verification. ZFS uses both CRC-64 for regular blocks and SHA-256 for critical metadata. Never substitute CRC-64 for SHA-256 in security contexts—the larger output does not provide cryptographic security. Choose based on whether you need speed for accidental error detection (CRC-64) or security for intentional tampering detection (SHA-256). For new systems requiring both, use CRC-64 for performance-critical paths and SHA-256 for security-critical verification.

CRC-64 Checksum Generator

Generate CRC-64 checksums from text. CRC-64 is a 64-bit cyclic redundancy check providing better error detection than CRC-32 for large datasets. Used in XFS, ZFS file systems, databases, and archival formats. Not cryptographically secure but excellent for detecting accidental data corruption with lower collision probability.

TextFile

Input Text

Other checksum tools

File to CRC-64 CRC-32 Checksum Generator SHA256 Hash Generator File to SHA256