Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Sep 2011 19:08:52 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: [moved from john-users] Speed of jtr on your machine?

From: "magnum" <rawsmooth@...dband.net>
>
>> Here is what I see in a 32 bit intrinsic build (cygwin). Now, this is not
>> jumbo-5, but I did not think anything changed about how md5_gen is built,
>> since then.
>>
>> $ ../run/john -test -form=md5-gen
>> Benchmarking:  md5_gen(0): md5($p)  (raw-md5)  [SSE2 16x4x2 (intr)]... 
>> DONE
>> Raw:    9653K c/s
>>
> It shows correctly when using md5_gen(0) but not when using thin raw-md5:
>
> $ ./john -fo:"md5_gen(0)" -test
> Benchmarking:  md5_gen(0): md5($p)  (raw-md5)  [SSE2 16x4x2 (intr)]... 
> DONE
> Raw: 13832K c/s real, 13832K c/s virtual
>
> $ ./john --format=raw-md5 --test
> Benchmarking: Raw MD5 [gen]... Using raw-md5 mode, by linking to 
> md5_gen(0) functions DONE
> Raw: 13858K c/s real, 13858K c/s virtual
>
> This is simply because the format (rawMD5go_fmt_plug.c) says so:
> #define ALGORITHM_NAME "gen"
>
> It would be better if md5_gen replaced that. Perhaps it should when a thin 
> format sets ALGORITHM_NAME to a null string?

This might be something that the base 'md5-gen' format will need to 'expose' 
to the thin formats, when they 'link'  The base (md5-gen) format is the one 
that is 'in charge' of calling the lowest level crypt functions, and the one 
that knows how it is going to proceed.  This was something that was 
overlooked in prior code.

I will have a look at the code later.   However, I am glad to see that even 
though it is showing [gen], it is properly 'using' SSE2i code to do the real 
work.

Jim. 

Powered by blists - more mailing lists

Your e-mail address:

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