[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110502134952.GK277@brightrain.aerifal.cx>
Date: Mon, 2 May 2011 09:49:52 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: FreeSec DES-based crypt(3)
On Mon, May 02, 2011 at 05:43:33PM +0400, Solar Designer wrote:
> Another issue is that somehow the speed of your FreeSec code in musl is
> extremely poor - it runs about 50 times slower than expected (e.g., than
> it does in glibc on Owl). This is as tested with "john --test
> --format=crypt" with JtR 1.7.7 on x86_64. I suggest that you run this
> test too, both before and after you replace the FreeSec code.
You are right, and the reason, as suspected, is that the state is
reinitialized on each call to crypt (crypt is just a wrapper for
crypt_r with state on the stack). I tried eliminating the des_init
function and instead just using memcpy from a static const
initial_state object, but as this structure is very large, it
increased the object size by ~35k. Using a non-const static object
would be even worse, as it would increase the non-sharable data size
of any process by this amount. I could consider using malloc to obtain
a permanent des state, allocated and initialized on first use, with
fallback to the stack if malloc fails. But I'm wondering if it's
really desirable for crypt to be fast anyway. Surely JtR wants a fast
crypt, but my impression was always that slow crypt was a cheap way to
get some added defense against brute force login attempts and such...
Thoughts?
Rich
P.S. crypt is in no way integrated with other parts of libc, so
linking with -lfastcrypt (separate library) is a potentially viable
option for situations where you want a fast one.
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.
