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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ