Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Apr 2012 05:37:48 -0700 (PDT)
From: deepika dutta <>
To: "" <>
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!! :)

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.