CRC : Java Glossary


CRC (Cyclic Redundancy Check). CRCs (Cyclic Redundancy Checks) are a popular method for determining if transmissions have been garbled. Roughly speaking the sender treats the message like a giant binary number. It divides it by a magic number using a special kind of division where you use XOR (exclusive OR) instead of subtraction (division by a polynomial for the mathematically inclined). Then it tacks the computed remainder on the end of the message. Why? The receiver repeats the calculation. If any of the bits of the message have been garbled, a different remainder will pop out of the calculation and the receiver will know to request a new copy of the message. If all arrived intact, the calculated remainder will the same as the appended checksum.
CRCs Scratch 16-bit CRC
Collaboration Learning More
32-bit CRC Links
Sun 16-bit CRC


More generally CRCs are a technique for creating a signature from a string of bytes. If any of the bytes changes, then most likely the calculated signature would change too. CRC ’s are used to verify a message has been sent unmolested and for HashCodes. Java version 1.6 or later offers the interface and CRC32 and Adler32 classes that implement it. CRC32 produces a classic 32-bit result using native code for speed. The CRC calculation can be thought of as polynomial division, with the individual bits as coefficients, or as XOR division that ignores carries. It works much like treating the message as a giant binary number and dividing it by some prime number and taking the remainder as the signature, except the calculation is easier for computers. Adler32 uses an even more simplified and speedy algorithm that produces almost as satisfactorily random a result.

CRCs are used in CCITT (Comité Consultatif International Téléphonique et Télégraphique) protocols. Adlerian checksums are faster to compute. For even greater speed you can use a simple XOR addition of all longs in the file/message. MD5 (Message Digest algorithm 5) and SHA-1 (Secure Hash Algorithm 1) digests are cryptographic strength. Which you should use depends on the degree of damage you want to protect against and whether that damage is intentional. CRCs won’t protect you against intentional damage because the hacker can recompute the embedded checksum or fairly easily fiddle the file to make the checksum come out the same. Making a doctored file come out to the same checksum is very difficult do with MD5 or SHA-1. To prevent doctoring and computing the checksum, you must use digital signing. Applet signing schemes use cryptographic digests to ensure the Applet is unmodified and truly written by the author advertised.

Some C++ code for computing CRC-16s is part of the CDDTest program part of the EIDEFLAW detecting package.


CRC (Class-Responsibly-Collaboration) is a way of designing programs with index cards where you put the outline of what each class does on card, and then lay them out before you like Tarot cards to contemplate.

Calculating 32-bit CRC


Calculating 16-bit CRC With Oracle’s Unofficial Method

Here is how to use the undocumented 16-bit CRC built into Java 1.0.2. It uses a native method to do the bulk of the

Calculating 16-bit CRC From Scratch

Here is how you would write your own CRC-16 polynomial. Earlier versions computed a signed CRC, but not the official CCITT CRC. This one should be the usual one used in datacommunications. There are variants, so you should check this code is generating what you want. If this does not give what you want, try starting want off at 0 instead

Learning More

Oracle’s Javadoc on CRC32 class : available:

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number