Java Glossary : CRC

CMP home Java glossary home Menu no menu Last updated 2004-06-28 by Roedy Green ©1996-2004 Canadian Mind Products

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : C words : CRC.

CRC
Cyclic Redundancy Check. CRCs 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 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. CRC's are used to verify a message has been sent unmolested and for HashCodes. JDK 1.1 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 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 a even more simplified and speedy algorithm that produces almost as satisfactorily "random" a result. 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 calculation.

/**
 * Calc CRC with sun method
 *
 * @param b byte array to compute CRC on
 *
 * @return 16-bit CRC, signed
 */
public static short sunCRC (byte[] b)
   {
   // create a new CRC-calculating object
   CRC16 crc = new CRC16();
   // loop, calculating CRC for each byte of the string
   for ( int i=0; i<b.length; i++ )
      {
      crc.update( b[i] );
      }
   return(short)crc.value;
   }

Here is how you would write your own CRC polynomial. Its results are different from Sun's. I have not been able to figure out why. Many sources agree that my 16 bit scrambler table is generated correctly.


view

CRCs are used in CCITT 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 and SHA-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.


CMP logo
CMP_home
home
Canadian Mind Products CSS
HTML Checked!
ICRA ratings logo
mindprod.com IP:[24.87.56.253]
Your IP:[80.134.30.163]
You are visitor number 5522.
Please send errors, omissions and suggestions
to improve this page to Roedy Green.
You can get a fresh copy of this page from: or possibly from your local J: drive mirror:
http://mindprod.com/jgloss/crc.html J:\mindprod\jgloss\crc.html