CRC : Java Glossary
©1996-2017 Roedy Green of Canadian Mind Products
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.
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.
are used to verify a message has been sent unmolested and for HashCodes.
Java version 1.6 or later offers the java.util.zip.Checksum interface and CRC32
and Adler32 classes that implement it. CRC32 produces a
classic 32-bit result using native code for speed. The
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.
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
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.
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
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
Oracle’s Javadoc on CRC32
class : available: