From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/324 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: FreeSec DES-based crypt(3) Date: Mon, 2 May 2011 09:49:52 -0400 Message-ID: <20110502134952.GK277@brightrain.aerifal.cx> References: <20110502134333.GB18325@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1312595724 11598 80.91.229.12 (6 Aug 2011 01:55:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 01:55:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: envelope-from@hidden Mon May 02 13:56:58 2011 Content-Disposition: inline In-Reply-To: <20110502134333.GB18325@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:324 Archived-At: 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.