To be excessively pedantic you can encrypt securely (but slowly for the SHA series) with a hash function of sufficient capacity by running the hash function in CTR mode. You turn it into a stream cipher. Ideally you also MAC the ciphertext, nonce, and other associated data. That's is pretty easy with such a hash function (either use HMAC or a MAC mode of the hash function if supported).

Salsa20 & ChaCha20 cores are hash functions (though not collision-resistant compression functions since it's not needed for their design goal and would be slower) run in CTR mode.[1]

[1] https://cr.yp.to/salsa20.html

> To be excessively pedantic

This is the best, most delicious, type of pedantry friend!

You're the best kind of pedantry friend!

(Just some more pedantry, friend.)

Ok man, now that's just over the top.

/s

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

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

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

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.

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

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").

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.

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.

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

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