[gpm]

It probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.

[ksangeelee]

You might be able to find bytes that result in your hash, but they probably won't be the same bytes you 'backed up'.

[gpm]

If the data is shorter than the hash shouldn't it be the same data I backed up with reasonably high probability?

[dorgo]

I guess you get (infinite?) many results which all have the same hash and one (or more) of them will be shorter than the hash.

[pathseeker]

No. http://matt.might.net/articles/counting-hash-collisions/

[monktastic1]

Can you explain the relevance? If I put N items randomly into >> N buckets the chance of there being a second item in a particular bucket is small (as opposed to there merely being a bucket with two items, as in the birthday "paradox").

[DuskStar]

That doesn't apply here, since the birthday paradox is about the existence of a collision, not that any particular sequence collides.

Most people in the room will still have unique birthdays even if one pair share theirs.

[im3w1l]

As an aside, sha-1 is smaller than 128 bytes.

From my numerical experiments (I hope I didn't mess up...) using the random oracle model, the probability that a given key is collision-free is 99.6% if the input is one byte shorter than hash, 1/e if input is same size as hash and 6.6e-112 if the input is one byte longer than hash.

And this holds basically irrespective of key size.

[jodrellblank]

If you're planning to brute-force count through 2^(128x8) possible bit inputs, it will be quite a few decades indeed. And you'll need a few spare solar systems to annihilate to get enough energy to drive your counting engine through that many states.

https://security.stackexchange.com/a/6149/1427

[gpm]

The idea is to wait for a preimage attack on sha, not brute force it.