Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 09 Sep 2011 13:00:41 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: RE: New pkzip format  [Moved to 'onlist' ]

On 2011-09-09 01:33, JimF wrote:
> From: "magnum" <rawsmooth@...dband.net>
>> NT went from 27M c/s down to 18M c/s from the more work put in bench.c.
>
> I realize that non-salted (and 1 salt) runs are going to be slowed down,
> from what the default is. However, on this machine, what is the 'true'
> speed you see, if using one of the faster methods, like inc:alnum,
> -inc:alpha, etc? I bet the 'real' performance is much closer to 18M than
> it is to 27M :)

I thought so too but thats's not really it. However, NT is so fast it 
really gets hit by incremental mode "shifting gears" (which gets less 
frequent the longer you run it) so it's hard to tell what is a 'true' 
figure. Attacking one single, unbreakable, NT hash, I exhaust 
-inc:digits in seconds with a "low" figure:

guesses: 0  time: 0:00:00:05 DONE  c/s: 21408K  trying: 83536787 - 83536784


Running -inc:alpha, the reported speed exceeds that immediately:

guesses: 0  time: 0:00:00:49 0.52%  c/s: 22908K  trying: hclkcubb - hclkcuje
guesses: 0  time: 0:00:01:26 0.92%  c/s: 23198K  trying: sosfcfor - sosfcfea
guesses: 0  time: 0:00:01:57 1.26%  c/s: 23263K  trying: kiaddhbo - kiaddpan
guesses: 0  time: 0:00:02:25 1.57%  c/s: 23455K  trying: casebbei - casebmmn


And running plain -inc it's soon near 24M:

guesses: 0  time: 0:00:03:37 0.00%  c/s: 23659K  trying: 23apjoee - 23apjomu
guesses: 0  time: 0:00:04:17 0.00%  c/s: 23837K  trying: rhtsduli - rhtsdut1
guesses: 0  time: 0:00:04:34 0.00%  c/s: 23904K  trying: dipbaye - dipbifl
guesses: 0  time: 0:00:06:11 0.00%  c/s: 23919K  trying: s7mabE - s7max@
guesses: 0  time: 0:00:07:51 0.00%  c/s: 23998K  trying: bweghy16 - bweghy22


I don't think we should change the benchmark for this case at all, just 
add another "mode" for use with formats like yours.


By the way, here are two crafted benchmarks, the first using a fixed 
speed test password of one character, the second using the max. 27 chars:

Benchmarking: NT MD4 [128/128 X2 SSE2-16]... DONE
Raw:	32799K c/s real, 33130K c/s virtual

Benchmarking: NT MD4 [128/128 X2 SSE2-16]... DONE
Raw:	18652K c/s real, 18840K c/s virtual

The format is so fast that the length of plaintexts is a significant 
parameter. I noticed this before when NT got more self-tests.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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