|
Message-ID: <c47892af0603241141l35c41d86p@mail.gmail.com> Date: Fri, 24 Mar 2006 19:41:15 +0000 From: "Hari Sekhon" <harisekhon@...il.com> To: john-users@...ts.openwall.com Subject: Re: JTR not exactly breaking the speed limits Thanks for the speedy and helpful reply Hari On 24/03/06, Solar Designer <solar@...nwall.com> wrote: > 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 > > -- > To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply > to the automated confirmation request that will be sent to you. > >
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.