Date: Wed, 14 Sep 2011 11:35:34 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> 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 md5.in 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 md5.in 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 Jim. >From: JimF [mailto:jfoug@....net] > > .... >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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ