From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1470 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: crypt* files in crypt directory Date: Wed, 8 Aug 2012 17:48:55 -0400 Message-ID: <20120808214855.GL27715@brightrain.aerifal.cx> References: <20120808022421.GE27715@brightrain.aerifal.cx> <20120808044235.GA22470@openwall.com> <20120808052844.GF27715@brightrain.aerifal.cx> <20120808062706.GA23135@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1344462499 27764 80.91.229.3 (8 Aug 2012 21:48:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Aug 2012 21:48:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1471-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 08 23:48:20 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SzE70-0007Pj-1E for gllmg-musl@plane.gmane.org; Wed, 08 Aug 2012 23:48:18 +0200 Original-Received: (qmail 9766 invoked by uid 550); 8 Aug 2012 21:48:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9744 invoked from network); 8 Aug 2012 21:48:16 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1470 Archived-At: On Wed, Aug 08, 2012 at 09:03:00AM +0200, Daniel Cegiełka wrote: > > Maybe you could support -DFAST_CRYPT or the like. It could enable > > forced inlining and manual unrolls in crypt_blowfish.c. > > > > Alexander > > This can be a very sensible solution. Unless there's a really compelling reason to do so, I'd like to avoid having multiple alternative versions of the same code in a codebase. It makes it so there's more combinations you have to test to be sure the code works and doesn't have regressions. As it stands, the code I posted with the manual unrolling removed performs _better_ than the manually unrolled code with gcc 4 on x86_64 when optimized for speed, and it's 33% smaller when optimized for size. As for being slower on gcc 3, there's already much more performance-critical code that's significantly slower on musl+gcc3 than on glibc due to gcc3 badness, for example all of the endianness-swapping functions (byteswap.h and htonl,etc. in netdb.h). Really the only place where crypt performance is critical is in JtR, and there you're using your own optimized code internal to JtR, right? Even if crypt is half-speed on gcc3 without the manual unrolling, that still only makes a 1-order-of-magnitude (base 2) difference to the iterations you can use while keeping the same responsiveness/load, i.e. not nearly enough to make or break somebody's ability to crack your hashes. (In general, as long as you don't try to iterate this principle, an attacker who can afford N time (or N cores) can also afford 2*N time (or 2*N cores).) Aside from my own feelings on the matter, I'm trying to consider the impressions it makes on our user base. I've already taken some heat for replacing the heap sort qsort code in musl with smoothsort, despite it being a lot faster in a task where performance is generally important, and the size difference was less than this crypt unrolling. When someone frustrated with bloat sees hand-unrolled loops, their first reaction is "eew, this code is bloated". My intent with modernizing (and fixing the stack usage) of the old DES crypt code was to save enough space that we could get the new algorithms (blowfish, md5, sha) integrated without much (or even any, if possible) size increase versus the old bad DES code. I think this makes a difference for "selling" the idea of supporting all these algorithms to the anti-bloat faction of musl's following. Rich