From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1575 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Todo for release? Date: Tue, 14 Aug 2012 02:20:58 +0400 Message-ID: <20120813222058.GB8817@openwall.com> References: <20120813185329.GA20024@brightrain.aerifal.cx> <20120813213154.GI20243@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1344896461 24036 80.91.229.3 (13 Aug 2012 22:21:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Aug 2012 22:21:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1576-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 14 00:21:02 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 1T130P-00061h-SJ for gllmg-musl@plane.gmane.org; Tue, 14 Aug 2012 00:21:01 +0200 Original-Received: (qmail 19943 invoked by uid 550); 13 Aug 2012 22:21:00 -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 19935 invoked from network); 13 Aug 2012 22:21:00 -0000 Content-Disposition: inline In-Reply-To: <20120813213154.GI20243@port70.net> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:1575 Archived-At: On Mon, Aug 13, 2012 at 11:31:54PM +0200, Szabolcs Nagy wrote: > the sha2 based crypt seems to be designed recently > and the spec has a public domain implementation > http://www.akkadia.org/drepper/SHA-crypt.txt Unfortunately, the reference implementation uses alloca() on both salt and key strings. glibc has recently fixed that by using malloc() and returning NULL on its failure, but that's not great. Also, if potentially unreasonably long running time is a concern, it should be noted that for md5crypt and sha*crypt it is roughly proportional to password length (modulo block size of the underlying primitive). So e.g. a 1 million char password (which may realistically be passed to libc's crypt() e.g. via a scripting language) may take thousands of times longer to be hashed than the sysadmin had intended by tuning the iteration count. I'm not sure whether and how a libc should deal with that. In a sense, it is similar to the issue of high iteration counts, but it's worse in that the input that may trigger the issue very often comes from a remote system. For the extended DES-based crypt() hashes that we now support, this issue mostly does not arise since the password (even if very long, which is supported) is passed through just one instance of DES block-by-block, which is quick. The multiple iterations loop is then applied to the "compressed" version of the password. For bcrypt hashes, the issue does not arise because they truncate passwords at 72 characters (not great, but that's how they're defined, and it's good enough for practical purposes so far). Alexander