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
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
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
> > 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
> > 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.
zfs-discuss mailing list