Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 5 Oct 2006 05:44:12 +0400
From: Solar Designer <>
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>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15 - bringing security into open computing environments

To unsubscribe, e-mail and reply
to the automated confirmation request that will be sent to you.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ