If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):
From: email@example.com (Robert Carnegie) Subject: Re: CRC and Data Integrity Date: 28 Dec 2001 03:57:16 -0800 References: <firstname.lastname@example.org> email@example.com (Dave Dickerson) wrote in message news:<firstname.lastname@example.org>... > I'm trying to convince some technically-challenged management types > that the Oracle database files on our OpenServer 5.0.5 systems need > more protection than the scheme in current use by the application > developer. The current scheme is to calculate CRC's on the database > files, tar the files and CRC values to tape, and when/if a restore is > necessary, tar the files from tape to the hard drive, recalculate the > CRC's on the files and compare the new CRC values to those stored on > the tape. > > The major weakness of the current scheme is obvious but I'd also like > to know if anyone has had experience with, or knows of cases where, > CRC values appeared correct but the data was corrupt, or even worse, > the CRC's and data appeared good but values had actually changed (CRC > values were fooled?). In oher words, how strong (or weak) of a data > protection mechanism are CRC values? CRC is reasonably good at picking up corruption of data, because it's out of step with how your data is probably stored - that's what it's _for_. 16-bit CRC will detect ~ 65,535 out of 65,536 accidentally damaged files. 32-bit CRC is also available.
The computationally simple mathematics of CRC is informatively discussed at https://www.rad.com/networks/1994/err_con/crc.htm - I barely understand a word of it ;-) Obviously as described CRC is no use at all against someone tampering with your data, because they can simply generate their own CRC to match their version of your file. You'd want either some kind of private key signature system, or at least to keep the CRCs on disk instead of on the backup tape. If the CRC of the tape file doesn't match the CRC that you logged when you wrote the backup, you're in trouble. To put this into proportion: what are your precautions against a backup tape (and all of your commercially sensitive data) being stolen? Or: Do you still use telnet? I've no great idea how hard it is to forge a CRC maliciously if you can't actually change the CRC, but MD5 wouldn't exist for Bill to bring up if there wasn't a perceived problem with CRC. I note that SCO UNIX "sum" doesn't distinguish between "Robert Carnegie" and "eigenraC treboR" (deliberately little/big-endian agnostic?), and "sum -r" of a file that's all null bytes is all zeroes. So there are worse things than CRC ;-) (Suppose you used "sum" and then some accident zeroed out both the stored data file and the stored checksum, they'd still match*; aiui CRC wouldn't.) (*except that using "sum", you'd probably store "0", ASCII code 48, and not \000; _that's_ different.)
Got something to add? Send me email.