[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
