From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/325 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: FreeSec DES-based crypt(3) Date: Mon, 2 May 2011 22:03:36 +0400 Message-ID: <20110502180336.GA20095@openwall.com> References: <20110502134333.GB18325@openwall.com> <20110502134952.GK277@brightrain.aerifal.cx> 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 1312595725 11603 80.91.229.12 (6 Aug 2011 01:55:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 01:55:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: envelope-from@hidden Mon May 02 18:03:49 2011 Content-Disposition: inline In-Reply-To: <20110502134952.GK277@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:325 Archived-At: On Mon, May 02, 2011 at 09:49:52AM -0400, Rich Felker wrote: > 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. This makes sense. You might be over-estimating the cost of non-const static storage, though. It will only consume address space, not actual memory, until a process actually invokes crypt(3) for a DES-based hash, in which case the cost will be the same as above. > 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... There's a difference between inherently slow crypt and merely a slow implementation, and remote attacks are better dealt with in a different way, in my opinion. I don't want to discuss another bikeshed, so I'd rather not go into detail. JtR doesn't actually care much - it has its own optimized DES code (it'd care about SHA-crypt's speed, because it doesn't support that natively yet), but I just thought that you'd want musl not to be 50x slower than glibc at this. > 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. I think you'd want the default to be fast. The approach with malloc sounds fine to me - that way, you initially preserve the address space as well. Thanks, Alexander