[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080608124206.GA21749@openwall.com>
Date: Sun, 8 Jun 2008 16:42:06 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: How to chose computer for John?
On Sun, Jun 08, 2008 at 11:34:11AM +0000, rolf tester wrote:
> I am about to buy a new computer, which I also would like to use for password-recovery.
OK. My answers below are specific to current versions of JtR. For
other password recovery and password security auditing programs things
could be different.
> My questions:
>
> * How important is RAM?
RAM is completely unimportant. Any size and speed will do equally well.
This means that you can also go for a lower FSB frequency (cheaper CPU)
with almost no performance loss for JtR.
> * What would be better: Intel-Pentium Dual-Core
This is not specific enough. It could refer to completely different CPUs.
> (For instance E2160),
That's a good choice.
> or AMD Sempron64 3000+ or AMD Athlon 64 4000?
These are a lot slower, especially at DES-based hashes supported by JtR
natively (that is, not with contributed patches).
All of these are low-end, though. If you can afford a more expensive
CPU and don't mind higher power consumption, and you really intend to be
running JtR a lot and care about its performance a lot (maybe you should
not, actually), I'd recommend going for a quad-core Core 2 based
processor. Q6600 is a good choice for JtR in terms of price/performance
- retail prices appear to be in the $200 to $250 (USD) range now. E2160
appears to go for $60 to $70 now, so, yes, you'd be paying $150+ extra
for the CPU if you choose Q6600, but the performance improvement is 2.5
times when all cores are in use. When you consider the overall price of
the computer, the price increase is definitely less than 2.5 times. And
you can save by buying less RAM initially (you can add RAM later).
Of course, you will need to run one instances of JtR per core manually.
This means two instances on E2160 or four instances on Q6600.
> * For John the Ripper, what is better in general, Pentium or AMD?
There's no general answer. Specific CPUs and specific hash types need
to be compared. Right now, my advice is to go for Core 2 based CPUs,
some of which are now confusingly branded a "Pentium" again. However,
most other CPUs also branded a "Pentium", such as Pentium D, are a lot
slower and consume a lot more power (and please don't be misled by their
higher clock rates).
> (I read some improvements only concern AMD, and which AMD?)
You must be referring to JtR change log entries comparing versions 1.7,
1.7.1, and 1.7.2. You should not care about this. You're interested in
overall performance of current versions on different CPUs, not in
changes in performance between versions (you would not be running the
older versions anyway). Besides, newer CPUs are now available anyway,
so the changes that were initially of benefit on AMD processors only
are now of even greater benefit for Intel Core 2 (which was not around
at the time).
> Generally I use Linux but sometimes also Windows. Is it recommended to use the new
> Windows Vista?
No, the version of Windows (except for Windows 9x) makes no difference
for JtR performance. However, you may consider 64-bit versions of both
Linux and Windows, and making a 64-bit build of John. This results in a
10% performance improvement for DES-based hashes supported by John
natively. (Not because of the 64-bitness itself - John uses 128-bit
SSE2 vectors either way - but because of availability of 16 registers in
64-bit mode as opposed to just 8 in 32-bit mode.) Also, if you go for a
quad-core CPU, you'll want a suitable Windows license that will let you
make use of all "CPUs". I'm not familiar with Windows licensing, but I
think that XP used to be licensed for 1-2 CPUs only "by default", and
you needed a more expensive license for more CPUs. I don't know about
Vista. Perhaps someone else will comment on this.
> Finally, what would be the improvement to my current AMD Duron 800??? ;-)
I'll provide numbers for one core in a Q6600 at 2.4 GHz (or E6600, which
is similar but dual-core), running a 64-bit Linux build of JtR 1.7.2.
For all four (or two) cores, multiply these by 4 (or 2). To get numbers
for E2160 at 1.8 GHz, subtract 25%. For overclocking, scale these up
according to the CPU clock rate difference.
> Benchmarking: Traditional DES [64/64 BS MMX]... DONE
> Many salts: 236611 c/s
> Only one salt: 216775 c/s
Benchmarking: Traditional DES [128/128 BS SSE2-16]... DONE
Many salts: 2290K c/s real, 2300K c/s virtual
Only one salt: 1949K c/s real, 1969K c/s virtual
> Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE
> Many salts: 7972 c/s
> Only one salt: 7628 c/s
Benchmarking: BSDI DES (x725) [128/128 BS SSE2-16]... DONE
Many salts: 74500 c/s real, 74949 c/s virtual
Only one salt: 72558 c/s real, 72704 c/s virtual
> Benchmarking: FreeBSD MD5 [32/32]... DONE
> Raw: 1854 c/s
Benchmarking: FreeBSD MD5 [32/64 X2]... DONE
Raw: 8596 c/s real, 8578 c/s virtual
> Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
> Raw: 107 c/s
Benchmarking: OpenBSD Blowfish (x32) [32/64]... DONE
Raw: 343 c/s real, 343 c/s virtual
> Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE
> Short: 44706 c/s
> Long: 159319 c/s
Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 322682 c/s real, 322039 c/s virtual
Long: 988774 c/s real, 988774 c/s virtual
> Benchmarking: NT LM DES [64/64 BS MMX]... DONE
> Raw: 1865K c/s
Benchmarking: NT LM DES [128/128 BS SSE2-16]... DONE
Raw: 11973K c/s real, 11949K c/s virtual
> Test was made with Firewall&Antivirus running, under non-ideal conditions.
The above test on Q6600 was run on a server under moderate load - at
least one CPU core was almost always available (as it can be seen from
the small real vs. virtual time performance differences), but there were
some context switches (the process was likely bouncing between the cores
a little).
--
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
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.
