Re: Thinking aloud.

Martin Schläffer <[email protected]> Fri, 26 Oct 2012 10:24:49 +0200
Newsgroups gmane.linux.swsusp.devel
Message-ID <[email protected]>
> Thanks for your response - I'm no cryptography guru, so it's good to
> hear from people who obviously know more than I do. I guess the way to
> go then is to build a table of hashes that have been seen and compare
> the actual content if/when you get a collision? I suppose that would
> also help in seeing whether/how often pages have the same content.

Yes. If you see a collision in SHA1 hashes, you can be sure that the
pages are the same. You do *not* need to compare the actual content
since you won't see a collision (see below).

If you do a fast checksum first, you only save the time to compute the
(more expensive) SHA1 checksum, if the fast checksum detects that the
pages are different.

> Also, may I ask?: How does checksumming a page compare to using SHA1
> hashes for git blobs? I've read that Linus isn't concerned about
> collisions there, but don't fully understand why it's not an issue
> there, but is here.

I am a cryptographer. Believe me, just ignoring that a SHA1 collision my
happen is a lot saver than reading data from disk and comparing it (see
e.g. [1]).

Compared to bugs in software, a SHA1 collision is *really* insanely
unlikely. The probability to find a collision in SHA1 by coincidence is
2^-80. That means, you need to hash about 2^80 SHA1 blocks, or

1.000.000.000.000 TeraBytes of data

to find a collision. Just make sure that you can easily switch to a
different hash (like SHA-256), if SHA1 gets broken in practice some day.

Martin


[1]
http://www.itnews.com.au/News/320709,stable-linux-kernels-hit-by-serious-file-system-bug.aspx