[Digikam-users] backup and data integrity

[Gerhard Kulzer]

Am Wednesday 23 January 2008 schrieb Jakob Østergaard Hegelund:
> On Tuesday 22 January 2008, Arnd Baecker wrote:
> > On Mon, 21 Jan 2008, Gerhard Kulzer wrote:
> >
> > [...]
> >
> > > Arnd, can you send me the script? I'd like to try too.
> >
> > Done (off-list, it is really not ment for general consumption ... ;-)
> >
> > > I just read that strigi is exactly doing what we want, comparing
> > > files with sha1. Maybe sha1 is faster than md5?
> >
> > No idea. Maybe we should do a speed test at some point ;-)
>
> Both sha1 and md5 are designed to make it difficult to create a file
> with a specific checksum.  This is necessary for applications like
> digital signatures, but it usually comes at a significant performance
> (and complexity) premium.
>
> CRCs, on the other hand, were meant to catch what you're trying to
> catch, and will usually be a lot faster.
>
> A CRC64 should be more than sufficient to catch any of the mismatches
> you're looking for (CRC32, such as reported by the cksum command, would
> probably be good enough for most purposes as well). And it will
> definitely be much much faster than the cryptographically secure
> hashes.
Reading the FAQ 
(http://oss.oracle.com/projects/data-integrity/dist/documentation/faq.html)
I have to halfway backtrack:

Q: The TCP/IP checksum algorithm is notoriously bad at detecting single-bit 
errors. Why didn't you pick a stronger algorithm? 
A: Other options were contemplated, including Fletcher and XOR. The IP 
checksum was chosen because it was already implemented. 
 Also, the purpose of the checksum isn't necessarily to detect bit errors. 
Server-class systems feature error checking and correcting memory and buses. 
The main intent of the checksum is to allow verification that the data buffer 
matches the integrity metadata. And the IP checksum handles that fine.

Gerhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20080123/3deb56f4/attachment.sig>