Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Nov 2011 19:49:33 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: more targets using sse-intrinsics.S

2011-11-12 13:26, magnum wrote:
> 2011-11-11 21:45, jfoug wrote:
>> These 2 also need looked at:
>> Benchmarking: Netscape LDAP SSHA [4x]... DONE
...
>> Benchmarking: Netscape LDAP SSHA [8x]... DONE
...
>> I am not sure about these.  I do not know what the [8x] is, or where it comes from.
> 
> I had a look at OPENLDAPS_fmt_plug.c and it is a mess. There are
> shammx() calls in there but the code is not complete - so there are
> simply a couple of #undefs that disables mmx/sse completely!
...
> I will submit a patch that just fixes this bogus use of SHA1_N_STR
> though we should eventually enable use of intrinsics in all three.

After some digging around in the formats I found that Bartavelle's
salted-sha1 replaces NSLDAPS (ssha) *and* OPENLDAPS (openssha). The same
tag {SSHA} is used and it can use both salt lengths, which is apparently
the only difference between the older ones. I think we should just move
NSLDAPS and OPENLDAPS to unused.

And NSLDAP_fmt (nsldap) is just raw SHA1 with a '{SHA}' tag and using
Base64 instead of hex. I think the best thing to "fix" this format is to
move NSLDAP_fmt to unused and make a new one based on rawSHA1_fmt. I'll
put that on top of my to-do list, it's a one beer job.

Speaking of raw SHA1, I think we should add a tag for that one. In fact
we already have such a tag, namely $dynamic_26$. Like with dynamic, we
should support reading legacy (untagged) hashes from john.pot but always
write tags to new entries.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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