Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 09 May 2011 12:07:20 +0200
From: bartavelle <bartavelle@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: John core change patch (and md5-gen, etc)

Here is a patch that adds my intrinsics files. It is not really usable
and thus not on the wiki :
* I modified MD5GenBaseFunc__FreeBSDMD5Crypt_MMX with #ifdef until it
compiled. It does not work at all, as I didn't try to understand what
the code did. This will be for next time
* I included the sse-intrinsics.[ch]
* I altered the Makefile and arch files
* I hacked an empty shammx() function so that it compiles

The following formats fail -test:
md5_gen(12): md5(md5($s).md5($p))
md5_gen(13): md5(md5($p).md5($s))
md5_gen(21): HTTP Digest Access Auth
md5_gen(22): md5(sha1($p))
md5_gen(23): sha1(md5($p))
md5_gen(26): sha1($p)
md5_gen(27): OpenBSD MD5
md5_gen(28): Apache MD5

On 09/05/2011 02:50, JimF wrote:
> ? As for the arch.h, would'nt it be better to have makefile rules that
> simply defined MD5_PARA properly, or defined a 'USE_MD5_PARA', and not
> have to maintain a whole new set of x86*.h files ?  The para was
> something that IIRC needed hand tuned, mostly depending upon the 32/64
> bit, and what compiler was being used.  However, if we had proper
> targets in the make file, then we could set proper defines, and have the
> arch.h use the define(s) given to it.

I disagree. MD5_PARA and stuff like that is architecture specific and
should be defined once in the x86-64.h and x86-sse.h files. The only
reason for having another set of targets is for users not wanting to use
intrinsics, but they are too weak to bother with ! Perhaps it should be
defined with the AVX stuff.

> One question I have about the intrisic code.  Can it do passwords longer
> than 54 bytes? 

It couldn't, but I just included an "init" option. When set to 1, it
uses standard initialization vectors. When set to 0, it reads from the
output directory. It is now possible to chain them and work with larger
blocks of data.

How do you want to work from here ? Is that enough for you or do you
want me to patch some more ? I believe a linux-x86-64-icc target would
be handy.

[ CONTENT OF TYPE application/x-gzip SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ