2 ms·
On a 2012 laptop with john 1.8: • 24 million tries/second for unsalted MD5 • 18 million tries/second for unsalted SHA1 • 80,000 tries/second for crypt-md5 (s
by creshal 10y ago
On a 2012 laptop with john 1.8:
• 24 million tries/second for unsalted MD5
• 18 million tries/second for unsalted SHA1
• 80,000 tries/second for crypt-md5 (state of the art… in 1995)
• 2400 tries/second for bcrypt (already becoming obsolete in 2012)
• And a tremendous 100 tries/second for scrypt (then state of the art)
So yeah, the ~30% performance hit roughly fits. But even md5 can be used much more intelligently than just salting, and would have been available in major programming languages.
- Sami_Lehtinen 10y agoStill scanning the MD5 key space 2^128 would take a while to brute force passwords. Of course it only takes time. But a lot of time. SHA1 is better, because it's 2^168 options. Also there's a problem, what if the data isn't in single block. Then you might find collision, but that collision might include something which can't be put in the password field, and therefore doesn't solve the problem. MD5 for PQKDEj52vGQVKudQaBMSewJ5MMifgaVxNYK9zsRTxMzBkyvompLMtgYCYv6SNzDE is cd5480cf1ad1cf7fab3aedbc6495609d. I would love to see someone to reverse that. Even if you find the colliding hash with sorter set of input bits. It's highly likely, it won't be in the acceptable character set. Or am I getting something wrong?
- creshal 10y ago> Or am I getting something wrong? Yes, we're talking about passwords, not private keys. Virtually all passwords found in the wild have a massively lower entropy, so the amount of possible hashes doesn't really matter, only how long it takes to iterate through our much smaller password space. The longer that takes, the less attractive it is for attackers to try and brute-force people's passwords so they can try them on other services.