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.