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.
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.
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.
home |
Canadian Mind Products | |||
| 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 | |||