# How long will it take to crack a hashed random string

If I generate 128 bit, 512 bit and 1024 bit random strings using either:

And hash the random string using one of these hashes:

How long will it take for someone to find the random string from the hashed result?

I assume:

128, 512, 1024 bit strings generated from a native rand() using any hash will be very insecure. Since someone can just find the seed and begin generating the random strings. Irregardless of the hash, meaning no bruteforce is needed.

But with OpenSSL and HRNG, I would expect it to take much longer. How long would this take? Would this still be the case if MD5 or SHA1?

And why would it be a bad idea to use these strings as a salt?

• For the rand() function, it highly depends on how it was implemented, and where the seed came from. If done properly, it'll be exactly the same as openSSL or a properly implemented hardware RNG. For 128 bits, you'll almost certainly be dead before you could find the original text, even if Moore's law were to miraculously continue for the next 100 years. If the seed was taken from the system clock, cracking is potentially very feasible. Jul 7 '19 at 6:36
• @SteveSether Would this still be true if you used weak hashes like MD5 and SHA1? If so why would it be a bad idea to use these strings as a salt? Jul 7 '19 at 6:44
• Cryptographic salts have nothing significant in common with simply hashing a random string of bytes, no matter how those bytes were generated. Salting and hashing solve different, albeit sometimes related, problems.
– user
Jul 7 '19 at 14:15
• Right, so if one were to generate a random (128,512,1024 bit) string using the methods above, would MD5 or SHA1 be secure enough to hide the string? Jul 7 '19 at 15:52
• MD5 and SHA1 while "weak" aren't vulnerable to this sort of reversing. When people use the word "weak" to describe a hash it applies to a specific weakness, not a general weakness. Jul 8 '19 at 15:46