Date: Fri, 24 Mar 2006 20:15:25 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: JTR not exactly breaking the speed limits On Fri, Mar 24, 2006 at 04:48:57PM +0000, Hari Sekhon wrote: > I'm running john on 2 linux machines to crack unshadowed passwords from > another linux box in the format FreeBSD MD5 [32/32] I think. FWIW, in the informational strings like "FreeBSD MD5 [32/32]" that John outputs, it's the "FreeBSD MD5" which refers to the hash type, whereas the "[32/32]" refers to the particular implementation that John happens to use on your system. > One is a pathetic 1GHz Via cpu with 256Mb ram; ./john --status is as > follows > > ./john --status > guesses: 1 time: 4:05:50:23 (3) c/s: 1591 > > The second box is a better AMD Athlon XP 2200+ with 1.25Gb Ram; it's > ./john --status is as follows > > ./john --status > guesses: 2 time: 3:16:50:00 (3) c/s: 5147 This looks fine. (Obviously, the RAM size is irrelevant.) > What I want to know is why the c/s process is so slow. Is MD5 such a > slow algorithm to generate a hash with? It's not MD5 which is slow. It's the FreeBSD-style password hashing algorithm implemented on top of MD5 which is. That's roughly 1000 iterations of the MD5 compression function per candidate password, plus some other "overhead". > I think so judging by how long > it takes me to generate .md5s for files at home.... That's irrelevant. You can't judge the performance of "high-level" password hashing algorithms such as those implemented within the crypt(3) framework based on the performance of the underlying cryptographic primitives. It's the way those primitives are used, not the primitives themselves, which matters the most. > When cracking cache dumped DES from XP machines I used to get something > like 300,000 tries a second, Yes, there can be a lot of a difference in performance of different hashing methods. > I think I'll be here forever on this password file. Yes - you should not expect to crack all of these password hashes - you should only expect to identify the weak passwords. > Maybe the salts are making it harder... Yes, they are. Essentially, you're not getting the speedup which would otherwise be possible when cracking multiple hashes at once. > can't remember > how many salts this has though and I don't know how to find out. This information should be in the log files, and you can also obtain it by interrupting and restarting those sessions. > I know this is the primary decision for choosing the hashing method for > the shadow file and most linux distros give you the choice between MD5 > and blowfish. Actually, very few Linux distributions support the more advanced Blowfish-based (bcrypt) password hashing, unfortunately. I have them listed at the bottom of this web page: http://www.openwall.com/crypt/ > I was under the impression that blowfish was the stronger > since it's slower to generate and therefore stronger to brute force in > this manner? Yes, the Blowfish-based method (bcrypt) produces stronger hashes. As I have explained above, it's primarily not because of differences between MD5 and Blowfish, but rather because of differences in the higher-level algorithms built upon these cryptographic primitives. You should be using bcrypt if you can. > Are there any stronger? I am not aware of a password hashing method stronger than bcrypt that is currently in use. (I do have some thoughts on what could be improved even further and how, but so far that's pure theory.) -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments Was I helpful? Please give your feedback here: http://rate.affero.net/solar
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.