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