APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

crc checksums data integrity

What is this stuff?

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: rja.carnegie@excite.com (Robert Carnegie)
Subject: Re: CRC and Data Integrity
Date: 28 Dec 2001 03:57:16 -0800
References: <3c2be6fd.2515527@news.earthlink.net> 

ddinaz@hotmail.com (Dave Dickerson) wrote in message news:<3c2be6fd.2515527@news.earthlink.net>...
> 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 http://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_

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> crc checksums data integrity ––>Re: CRC and DataIntegrity

Increase ad revenue 50-250% with Ezoic

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

FORTRAN—the "infantile disorder"—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use. (Edsger W. Dijkstra)

This post tagged: