Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Apr 2012 02:48:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR compilation warnings on OS X 10.7.3 with Xcode 4.3.2

On Sun, Apr 29, 2012 at 11:59:36PM +0200, magnum wrote:
> Afaik the only formats not using sse2 (if any) are ones that just don't fit the intrinsics. I know of one or two md5 ones but I'm not sure we have any sha1 ones left. In fact i think we have none but that's ottomh. 

These source files appear to use SHA-1 from OpenSSL or CommonCrypto with
no ability to use our SSE2 intrinsics:

EPI_fmt_plug.c
episerver_fmt_plug.c
lowpbe.c
mozilla2john.c
mozilla_fmt.c
MSCHAPv2_fmt_plug.c
office_fmt_plug.c
rar_fmt.c
sha1_gen_fmt_plug.c

I guess for some of them this is OK (not performance critical), whereas
for most(?) a change to use the intrinsics is desired.

Similar lists for MD5 and MD4, respectively:

DMD5_fmt_plug.c
hmacmd5.c
NETNTLM_fmt_plug.c
NS_fmt_plug.c
sip_fmt_plug.c

md4_gen_fmt_plug.c
unicode.c

I think these use my implementations from md5.[ch] and md4.[ch], though,
since those are provided and we don't appear to define HAVE_OPENSSL
anywhere.  I don't know if OpenSSL's would be faster or slower - I guess
this may vary between systems.  In md[45].c included in jumbo, we have
the memset() in MD[45]_Final() #if 0'ed out, whereas OpenSSL's probably
try to do something like it (which has some performance cost):

http://www.openwall.com/lists/oss-security/2012/01/01/6

Anyway, these formats will become a lot faster by using the intrinsics
(the code will become far less readable, though).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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