Re: Thinking aloud.
Nigel Cunningham <[email protected]> Fri, 26 Oct 2012 21:01:39 +1100
| Newsgroups | gmane.linux.swsusp.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi. On 10/26/2012 07:24 PM, Martin Schläffer wrote: >> 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. Thanks Martin. Making sure you can easily switch is done - the name of the algo is a sysfs entry. Regards, Nigel