Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.