[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060324171525.GA27057@openwall.com>
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.
