[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061005014412.GA15991@openwall.com>
Date: Thu, 5 Oct 2006 05:44:12 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: JTR and os X macintel
On Mon, Oct 02, 2006 at 06:50:41PM +0200, websiteaccess wrote:
> I have now a Macintel (Apple, Intel core 2 duo) with os X (10.4.8), 2
> gigas RAM.
That's nice. And, by the way, your RAM size does not matter. ;-)
What CPU clock rate?
> Some month ago Alex told to me to compile the unix source of JTR with
> the command:
> "make macosx-x86-mmx".
That's correct. The "-sse2" target did not exist at the time.
> Now, I have compiled the same source with the command :
> "make macosx-x86-sse2"
> now test return me :
>
> Benchmarking: Traditional DES [128/128 BS SSE2]... DONE
> Many salts: 1841K c/s real, 1845K c/s virtual
> Only one salt: 1532K c/s real, 1535K c/s virtual
That's really good performance - it looks like we have a new leader at
DES-based crypt(3).
> Is there others commands for compiling JTR'source and get better
> performance ?
Currently, no. (Well, you might be able to achieve minor speedups by
tweaking compiler flags.)
One question that I had to someone familiar with Mac OS X on Intel is
whether 64-bit builds of application software are supported. If so, I
should probably add a macosx-x86-64-sse2 target that would make use of
the 64-bit mode extended 16-register SSE2. It is not certain whether it
will be faster, the same, or slower on current CPUs, though.
> My mac has a "core duo", is JTR use 2 cores at the same time ?
No. As discussed on this mailing list oh-so-many times, you need to
start two instances of JtR manually in order to have it use both CPU
cores. For "incremental" mode, a reasonable way to split the task
across two cores is to set one instance to try lengths 0 through 7 and
the other to length 8. The following FAQ entry is relevant:
Q: Does John support multi-processing or distributed processing?
A: There's no real MP or distributed processing support in John right
now, but you can distribute the work between a few nodes manually. One
approach would be to have your nodes (CPUs, machines) each try different
password lengths. This is easily accomplished with "incremental" mode's
"MinLen" and "MaxLen" settings (see CONFIG). Typically, you would not
really need to split the work for "single crack" and wordlist modes
since these are relatively quick, although you may dedicate one node to
those initially. You may safely run multiple instances of John in the
same working directory, all writing to the same "pot file" (this is a
feature). You do, however, need to assign each of them a unique session
name, with "--session". Other approaches, such as splitting password
files naively (without regard to salts), are typically less efficient
(in some cases to the extent where there's no speedup from using
multiple processors at all).
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
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.
