Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Sep 2011 11:35:34 -0500
From: "jfoug" <>
To: <>
Subject: RE: Re: [moved from john-users] Speed of jtr on your machine?

I have found several issues here.  First, the output strings to
benchmarking, or normal running (and logging), where the format string, and
algorithm was output was happening PRIOR to init() function being called.
Well, that works fine if using data that is compiled in (in the md5-gen
case, it is '[gen]').  However, if we want to harvest that from the md5-gen
underlying format, then we have to make sure we call init() first.

Also, I had to change the init() function in all 'thin' formats.  In there,
I simply assign the params.algorithm_name of the thin format, to the format
pointer returned (which points to the md5-gen sub format).  Pretty easy.

I also removed the 'linked to md5_gen(x)' line that was being output with a
'simple' printf command.

I will get things cleaned up, and get a patch done.   I also have another
small formatting issue magnum pointed out that I will get in there.

Here is an 'example' of the changed look/feel of the output.

Prior to change:
john -for=raw-md5
Using raw-md5 mode, by linking to md5_gen(0) functions
Loaded 1 password hash (Raw MD5 [gen])
guesses: 0  time: 0:00:00:17 0.00% (3)  c/s: 6018K  trying: TjRo - 49387021

john -for=raw-md5  -test
Benchmarking: Raw MD5 [gen]... Using raw-md5 mode, by linking to md5_gen(0)
functions DONE
Raw:    10915K c/s

After change:
john -for=raw-md5
Loaded 1 password hash (Raw MD5 [SSE2 32x4 (.S)])
guesses: 0  time: 0:00:00:00 0.00% (3)  c/s: 184104  trying: allash - beats

john -for=raw-md5  -test
Benchmarking: Raw MD5 [SSE2 32x4 (.S)]... DONE
Raw:    10940K c/s


>From: JimF []
> ....
>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.

Powered by blists - more mailing lists

Your e-mail address:

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