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.