Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 2 Oct 2015 18:10:30 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Kerberoast for John

On 2015-10-02 10:46, Michael Kramer wrote:
> Am Freitag, 02. Oktober 2015 10:33 CEST, magnum <john.magnum@...hmail.com> schrieb:
>> On 02/10/15 09:52, Michael Kramer wrote:
>>> But I still encounter this strange bug. If I just use ./john <myfile>, the speed gets slower over time.
>>>
>>> Some numbers:
>>>
>>> 0g 0:00:00:01 33.54% 1/3 (ETA: 08:32:05) 0g/s 405927p/s 405927c/s 405927C/s
>>>
>>> 0g 0:00:01:08 69.54% 2/3 (ETA: 08:33:40) 0g/s 43377p/s 535782c/s 535782C/s
>>
>>> 0g 0:01:16:24  3/3 0g/s 2320p/s 526810c/s 526810C/s
>>>
>>> Is this behaviour normal?
>>> The file I've loaded has 311 hashes.
>>
>> If you look at the c/s or C/s figures, it actually gets faster. The
>
>> first stage is "single mode" which is expected to have a LOT better p/s
>> for many salts than any other mode, due to its design. All other modes
>> will have a c/s ~= (p/s / number of unique salts) and you can expect the
>> c/s figure to match the benchmark speed figure.
>>
>> If anything, the c/s of stage 2 (wordlist + rules) is curious. It seems
>> to indicate stage 2 is slightly faster than incremental (stage 3). That
>> is normally not the case.
>
> But isn't p/s the candidates/s? So the most interesting value, because it's the actual compares/s? Which means if p/s gets slower the cracking itself gets slower? Or am I understanding something wrong here?

The C/s is "compares" per second if you will. The p/s is number of input 
words tried per second. The latter is affected by number of salts.

Look at it this way: The "normal" speed here is something like 530K c/s 
divided by the number of salts, which is about 1700 p/s.

Stage 1 (single mode) is "way faster than normal" for many salts so you 
don't see much of that "divided by" thing. The other ones are normal. If 
anything is weird with your numbers (compared to other crackers), it's 
the crazy fast relative speed for stage 1.

The figures you see at each status print are the total averages for the 
whole run, so after stage 1 is done the speed shown will decrease slowly 
over time, approaching 1700 p/s (or whatever is the normal speed).

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ