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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ