Date: Sun, 15 Apr 2012 05:37:48 -0700 (PDT) From: deepika dutta <deepikadutta_19@...oo.com> To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com> Subject: Re: statistics -openssl vs john Hi all, Thanx for your replies, yaa i also thought this question fits on john-users well so re-posted it here, but no need of sorry's :) I am happy you replied with so much details. Got to know a lot of new things. > Yet such comparisons are sometimes useful if you know how to interpret the >results and don't assume that you have a direct comparison. > >Yes such comparisons are useful as they make you appreciate and feel excited about new techniques and works such as JTR. :) > >>Then, these performance numbers and those you posted before suggest that >you might be on a virtual machine or at least on a system with other >load. Benchmark results are very often incorrect when you run those >benchmarks inside a VM: the VM's timers might not behave well enough. >In your case, OpenSSL's performance numbers might be inflated (I am >getting twice worse speeds on a non-virtualized 2.5 GHz Core 2'ish CPU), >and John's affected in some other way. Large c/s real vs. c/s virtual >differences are not normal when you're benchmarking things on a >supposedly otherwise idle system. You need to actually make the system >idle first - and avoid VMs. > >Wow, your are right, I took these figures inside a VM. These figures looked to me also exaggarated as 12 million enc/sec from a core of 2 GHz, Intel core 2 Duo looked surprising. Now I got the reason behind it - timer misbehavior in VM. Thanks for it, I was not aware of this fact in VMs. > >>These are pretty low speeds for John. Do you deliberately build it with >a non-optimal make target for a "fair" comparison against OpenSSL >(assuming that OpenSSL won't use SSE2 or the like for DES)? That might >not actually be fair. The primary advantage of bitslicing is that it >lets you use arbitrarily wide machine words or SIMD vectors efficiently. >With only 32-bit machine words, that advantage is not present, but with >128-bit SSE2 vectors it is. > >Right, I deliberately build john without optimizations for a fair comparison, I will use optimizations now. > >> With john, considering LM DES (which according to what I read does 2 DES >> encryption), > >No, it is just one DES encryption, but the key changes every time you do >it (JtR tries different candidate passwords), and there's also the hash >comparison step (to detect cracked passwords). > >Well, from what I read on net, in LM Hash the password is used to generate two DES keys and 2 encryptions are done per password with the ciphertexts concatenated. How then you say it is only one encryption?? > >--- >Benchmarking: Traditional DES [128/128 BS AVX-16]... DONE >Many salts: 20668K c/s real, 2593K c/s virtual >Only one salt: 8724K c/s real, 1094K c/s virtual > >That's for 8 threads on this quad-core CPU with SMT. > >(By the way, this corresponds to over 500 million of DES block >encryptions per second, or a data encryption speed of 33 Gbps, if we >were encrypting data. Of course, in practice there would be other >limitations, such as data transfer bandwidth. But the crypto code and >the CPU are this fast.) >--- > >Newer versions of JtR built with newer gcc achieve higher speeds on the >same machine: > >Benchmarking: Traditional DES [128/128 BS AVX-16]... DONE >Many salts: 22773K c/s real, 2843K c/s virtual >Only one salt: 18284K c/s real, 2291K c/s virtual > >Since every DES-based crypt(3) computation involves 25 modified-DES >encryptions (slower than normal DES), that's over 4.5 Gbytes/sec or >36 Gbps data encryption speed. (In the multi-salt case, the key setup >is out of the loop.) > >For a more direct comparison (yet still apples to pears indeed) to the >OpenSSL benchmarks I posted above, here's what John achieves on one core >in the FX-8120 o/c 4.5 GHz (turbo): > >Benchmarking: Traditional DES [128/128 BS XOP-16]... DONE >Many salts: 5275K c/s real, 5275K c/s virtual >Only one salt: 4993K c/s real, 4993K c/s virtual > >(Non-OpenMP build this time, to use just one CPU core.) > >That's 1055000 x 1000 bytes per second (about 1 Gbyte/sec), which is >about 14 times faster than the OpenSSL speed. And that's not >considering that JtR also implements DES-based crypt(3) salts in this >benchmark (roughly a 7% performance hit). > >For a pure 32-bit build, if you must, I expect JtR to be faster than >OpenSSL's DES - in this apples to pears comparison - by a factor of >1.2 (x86 in 32-bit mode, register-starved) to 4 (decent architectures). > >Here's a low speedup example (almost worst case for JtR), Pentium 3 >1.0 GHz, deliberately non-optimal build of JtR ("make generic"): > >Benchmarking: Traditional DES [32/32 BS]... DONE >Many salts: 125632 c/s real, 124388 c/s virtual >Only one salt: 124448 c/s real, 124448 c/s virtual > >That's about 25 million bytes per second. OpenSSL on the same machine: > >type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes >des cbc 20319.54k 21552.33k 21682.94k 21918.41k 21882.78k > >So we have a speedup of only between 1.2x to 1.25x here. As soon as we >switch to an optimal build, things change dramatically (same machine): > >Benchmarking: Traditional DES [64/64 BS MMX]... DONE >Many salts: 376320 c/s real, 376320 c/s virtual >Only one salt: 367040 c/s real, 367040 c/s virtual > >That's about 75 million bytes per second, or a speedup of 3.5x. > >The speeds are awesome, thanks for all the effort you put in answering, JTR rocks!! :) > > >Cheers, >Deepika >
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.