4 ms·
The GP was likely hinting at SHA1 being an hashing function, non an encryption function, so just applying sha* wouldn't produce a working backup
by riquito 7y ago
The GP was likely hinting at SHA1 being an hashing function, non an encryption function, so just applying sha* wouldn't produce a working backup
- gpm 7y agoIt probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.
- ksangeelee 7y agoYou might be able to find bytes that result in your hash, but they probably won't be the same bytes you 'backed up'.
- gpm 7y agoIf the data is shorter than the hash shouldn't it be the same data I backed up with reasonably high probability?
- pathseeker 7y agoNo. http://matt.might.net/articles/counting-hash-collisions/ http://matt.might.net/articles/counting-hash-collisions/
- monktastic1 7y agoCan 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 7y agoThat 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.
- deleted 7y ago[deleted]
- dorgo 7y agoI guess you get (infinite?) many results which all have the same hash and one (or more) of them will be shorter than the hash.
- jodrellblank 7y agoIf 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 https://security.stackexchange.com/a/6149/1427
- gpm 7y agoThe idea is to wait for a preimage attack on sha, not brute force it.
- im3w1l 7y agoAs 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.
- SAI_Peregrinus 7y agoTo 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 https://cr.yp.to/salsa20.html