[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1334493468.82419.YahooMailNeo@web161305.mail.bf1.yahoo.com>
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.
