[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <op.x3ipf7lxzz6j51@1pqhgq1.dtn.com>
Date: Mon, 17 Aug 2015 10:03:33 -0500
From: JimF <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: phpass on CPU, aka dynamic_17
On Mon, 17 Aug 2015 09:37:42 -0500, JimF <jfoug@....net> wrote:
> On Mon, 17 Aug 2015 09:30:25 -0500, Solar Designer <solar@...nwall.com>
> wrote:
>
>> On Sun, Aug 16, 2015 at 07:51:04PM +0200, magnum wrote:
>>> On 2015-08-16 19:44, Solar Designer wrote:
>>> >Would recovering the old phpass format (pre-dynamic) make sense, to
>>> use
>>> >it as a base for the new one?
>>>
>>> Apparently that format pre-dates our git history so we need to get it
>>> from whatever latest jumbo tarball had it (or just rewrite it).
>>
>> Lei - you may download old tarballs from here:
>>
>> http://download.openwall.net/pub/projects/john/
>>
>>> I'll open a GitHub issue for it.
>>
>> Have you?
>
> I have an older phpass-fat I am working on, to at least get it to
> compile. NOTE, it has a much older format structure, so that has to be
> updated, and then it uses non-intrisic SIMD code (the older mmx.S
> stuff), which is no longer included. But getting it to a 'normal' state
> should be trivial. I will upload it at that point to git, but it will
> have have all the work done to get the SIMD working properly, and get it
> ported to handle more than SIMD_COEF==4
Ok, I have uploaded this file to git 6c3053e . The filename is
./src/phpassMD5_fat_fmt_plug.c Once we get things worked out, we likely
can take over the phpassMD5_fmt_plug.c file name and drop the thin one.
The label is phpass-md5 (the thin one uses phpass). I updated the format
structure to get it to compile, but there are still format structure items
that might need work (binary/salt align, iteration count should be a
tunable cost, etc).
All of the SIMD code in there needs work. It is still using the MMX_COEF
define (which we do not use any more), and it also only uses the older
mmx.S interface. But the code 'is' there, it just needs to be updated so
it can handle large SIMD_COEF_32 values properly, and to use the intrisic
interface. At the current time, the SIMD code will NOT (can not)
compile. This allows the code to be put into the source tree even though
it could not be built as it stands for SIMD. It will always build
non-SIMD as it stands.
It still needs LOTS of work, lol, as shown by:
$ ../run/john -test -form=phpass
Benchmarking: phpass ($P$9) [phpass ($P$ or $H$) 128/128 XOP 4x2]... DONE
Raw: 13144 c/s real, 13081 c/s virtual
$ ../run/john -test -form=phpass-md5
Benchmarking: phpass-md5, PHPass MD5 [phpass-md5]... DONE
Raw: 2092 c/s real, 2096 c/s virtual
NOTE, this format should gain a LOT of speed with SIMD, and in the end,
this one was about as big of a gainer as you can get. 5 to 8x (for 4 limb
SIMD) should be expected per core.
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.
