Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101217053458.GC6958@openwall.com>
Date: Fri, 17 Dec 2010 08:34:58 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: JtR/OpenMP against Gawker passwords

Dan,

On Wed, Dec 15, 2010 at 05:27:42PM -0800, Dan Tentler wrote:
> I've been playing with this myself on my mac - I have an I7 core machine 
> and I've been trying to use the mpi patches to make it play nicely. Ive 
> had limited success - I tried cracking the gawker list for two days and 
> got 3 passwords - this of course was with zero tuning .. just pointing 
> jtr 1.7.6 with some patches at the files and using MPI. I'm not %100 I'm 
> doing it right.

Perhaps not.  Even with default settings, you should have cracked
thousands of passwords right away.  Try it without any parallelization
first.  Then try to get quicker/better results with parallelization.

I've never used the MPI patches myself, and as you can see this thread
is about OpenMP, which is totally different from MPI (even though
there's an implementation of MPI that is "confusingly" called OpenMPI).
Perhaps try OpenMP (not MPI)?

> But a question for SolarDesigner - does your roadmap for jtr define any 
> distributed capabilities?

Yes, but I am not sure whether I will have time or not.  Sponsorship by
some infosec company would help ensure that this does get implemented -
and is implemented soon.

> I suppose what I'm getting at is "are we stuck with mpi"?

No.  As you can see, there's already OpenMP support instead - it's built
into 1.7.6 for the extra-slow hashes (bcrypt, SHA-crypt, SunMD5) and is
available via patches for DES-based crypt(3) hashes (including the BSDI
style of them, although those are rare) and for LM hashes (although it's
inefficient for those).  I am likely to extend this to some other hash
types.

I consider the OpenMP approach temporary, though - at least for
relatively fast hashes, where it incurs too much overhead.  Part of the
reason why I started implementing it was my lack of time - I needed to
get something working with whatever relatively little time I could throw
at it.  OpenMP let me keep the overall program structure and
user-visible behavior the same, which was a plus (no documentation to
edit, etc.)

So maybe I will complete OpenMP support for other hash types supported
by the official JtR, make a release, then move on to other approaches
(better efficiency, more generic, but more invasive and with
user-visible changes in program behavior).  This is just one of the
possibilities I am considering, though.

Alexander

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.