Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.