[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120823123120.GB16237@openwall.com>
Date: Thu, 23 Aug 2012 16:31:20 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Real c/s Explaination
On Tue, Aug 21, 2012 at 06:10:08PM -0700, NeonFlash wrote:
> I wanted to understand in depth the meaning of the c/s speed displayed while running an attack using JtR on a cryptographic hashing algorithm.
This is not a trivial question. magnum has provided links to some past
answers to related questions. I'll try to add some detail specific to
your example:
> For instance, if we run:
>
> ./john -fo=DES --test
>
> For me it would show something like, 2300K c/s
It actually shows several numbers, although they're usually pretty close
to each other.
> My understanding is that my processor can perform 2300K DES Encryptions using descrypt of the candidate passwords in 1 second. However, I think this is not an accurate description. I would appreciate it if someone can elaborate over this (Solar Desginer especially :D )
If "2300K c/s" is the number shown on the "Only one salt" line, this
means that 2.3 million candidate passwords can be tested against a
traditional DES-based crypt(3) hash per second using that build of JtR
running on your CPU (perhaps on one core in it, unless you enabled
OpenMP or MPI).
If it's the "Many salts" speed number, then it means that this many
combinations of {candidate password, target salt} can be tested per
second.
Note that DES-based crypt(3) is not the same as "DES encryption".
So the c/s rate does not directly correspond to DES encryption speed,
which is not the exact task you have here. These differ roughly by a
factor of 25 - e.g., 2300K c/s at DES-based crypt(3) corresponds to 57.5
million DES block encryptions per second - although even with this
correction this remains an apples to oranges comparison in many ways.
> Also, how is it related to the clock cycle and clock speed of a Processor?
The faster the processor, the higher c/s rate it will produce. The
number reported already includes the processor's speed factored in,
simply because the code runs faster during the benchmark on a faster
CPU. For example, if you overclock your CPU by 10%, the reported c/s
rate is likely to increase by 10% (so it might be 2530K c/s in your
example).
> For instance, if I am comparing the benchmark for the same hashing algorithm using the same version, build of JtR on two different processor, how accurate is the comparison
It is pretty accurate.
> in terms in efficiency?
I don't understand what you mean by this.
> I guess, cycles per byte need to be calculated for that but for this I need to understand the meaning of c/s in more detail.
Why would you want to compute the oranges equivalent for these apples?
In some contexts, this makes sense. For example, I included such
numbers here:
http://www.openwall.com/lists/john-users/2011/06/22/1
However, this is not needed when you're merely using JtR on different
computers, want to compare and tune the settings, etc.
> I love JtR and I would like to understand in much more depth at code level.
OK, this addresses my question above.
I think your questions are not so much about JtR code as they are about
the supported hash types and what it takes to compute them (to an extent
sufficient to reject a candidate password).
Alexander
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.
