Reference vector
- Input
- 123456789
- Expected output
- cbf43926
The vector cited in the CRC-32/ISO-HDLC specification, the same polynomial used by ZIP and Ethernet, used to check whether an implementation matches the standard.
crc32 generator
CRC32 returns a 32-bit checksum as 8 hexadecimal characters and is not a cryptographic hash: it is an error-detection code built on polynomial division. Here you calculate the value and see where it is actually used, far from any security promise.
The vector cited in the CRC-32/ISO-HDLC specification, the same polynomial used by ZIP and Ethernet, used to check whether an implementation matches the standard.
The mechanism is the same one that writes the 4-byte CRC-32 field into the local header of every file inside a real .zip, except there it runs over the uncompressed bytes, not the file's name.
A classic pangram used in technical documentation to compare CRC32 implementations across different libraries.
Yes. Text, files and HMAC secrets are processed directly in the browser without any upload.
No. It is a linear error-detection code, built to catch accidental corruption, not to resist an attacker. An attacker can compute extra bytes that force any desired CRC32 without brute-forcing anything.
Because both formats were built in the 1990s to catch disk or network corruption, not to defend against tampering. A 32-bit checksum is cheap to compute on any hardware from that era, and it has stayed that way for backward compatibility ever since.
Yes. The hash generator calculates CRC32 for files as well as text, so you can compare the value against the checksum recorded in a .zip or provided by another source.
—Checksum clássico para integridade acidental, não criptográfica.
Text, files and secrets are processed locally. Nothing is sent to the server.