You don't have to store all hash values: a. Just memorize the first one SHA256(0) b. start cointing c. bang: by the time you get to 2^256 you get at least a collision.
(do this using BOINC, you dont have to wait for the last hash to be calculated, I'm pretty sure a collision will occur sooner) 1. SHA256 produces a 256 bit hash 2. That means it produces a value on 256 bits, in other words a value between 0..2^256 - 1 3. If you start counting from 0 to 2^256 and for each number calculate the SHA256 you will get at least one hash collision (if the hash algortihm is prefectly distributed) 4. Counting from 0 to 2^256, is nothing else but reproducing all possible bit pattern on 32 bytes And nobody is trying to proove that SHA256 is bad, and I don't want to do compression either. But it's unrealistic to think that a SHA256 collision wont occur just because it would be impossible to find it via brute-force. On Wed, Jul 11, 2012 at 4:49 PM, Sašo Kiselkov <skiselkov...@gmail.com>wrote: > On 07/11/2012 04:39 PM, Ferenc-Levente Juhos wrote: > > As I said several times before, to produce hash collisions. Or to > calculate > > rainbow tables (as a previous user theorized it) you only need the > > following. > > > > You don't need to reproduce all possible blocks. > > 1. SHA256 produces a 256 bit hash > > 2. That means it produces a value on 256 bits, in other words a value > > between 0..2^256 - 1 > > 3. If you start counting from 0 to 2^256 and for each number calculate > the > > SHA256 you will get at least one hash collision (if the hash algortihm is > > prefectly distributed) > > 4. Counting from 0 to 2^256, is nothing else but reproducing all possible > > bit pattern on 32 bytes > > > > It's not about whether one computer is capable of producing the above > > hashes or not, or whether there are actually that many unique 32 byte bit > > patterns in the universe. > > A collision can happen. > > It's actually not that simple, because in hash collision attacks you're > not always afforded the luxury of being able to define your input block. > More often than not, you want to modify a previously hashed block in > such a fashion that it carries your intended modifications while hashing > to the same original value. Say for instance you want to modify a > 512-byte message (e.g. an SSL certificate) to point to your own CN. Here > your rainbow table, even if you could store it somewhere (you couldn't, > btw), would do you little good here. > > -- > Saso >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
