From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1577 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 06:13:17 +0400 Message-ID: <20120814021317.GA10036@openwall.com> References: <20120813185329.GA20024@brightrain.aerifal.cx> <20120813213154.GI20243@port70.net> <20120813222058.GB8817@openwall.com> <20120814014652.GC27715@brightrain.aerifal.cx> 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 1344910399 20946 80.91.229.3 (14 Aug 2012 02:13:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2012 02:13:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1578-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 14 04:13: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 1T16dD-0003Uf-TS for gllmg-musl@plane.gmane.org; Tue, 14 Aug 2012 04:13:20 +0200 Original-Received: (qmail 15984 invoked by uid 550); 14 Aug 2012 02:13:18 -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 15976 invoked from network); 14 Aug 2012 02:13:18 -0000 Content-Disposition: inline In-Reply-To: <20120814014652.GC27715@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:1577 Archived-At: On Mon, Aug 13, 2012 at 09:46:53PM -0400, Rich Felker wrote: > On Tue, Aug 14, 2012 at 02:20:58AM +0400, Solar Designer wrote: > > 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. > > Why? Does it need working space proportional to the input length? It uses implementations of SHA-512 and SHA-256 that assume alignment, so it provides such alignment by copying the inputs to aligned buffers if the inputs to crypt() don't happen to be already aligned. The same applies to glibc's md5crypt (but we're not going to use that implementation of md5crypt anyway). > In light of both the alloca issue and the way runtime scales with key > length, I think we should just put an arbitrary limit on the key > length and return failure for longer keys. This should not affect any > real-world authentication systems, since the daemon you're attempting > to login to will also be placing a (probably much lower) limit on the > input buffer size for passwords (if it's not, you can trivially DoS > the server by sending gigabyte-long passwords for random users). > > Something like 128-256 bytes would probably be a very generous limit. Yes, but the failure should be indicated in the way we discussed - those "*0" and "*1" strings, not NULL. Some real-world authentication systems may be affected; it is not unrealistic even for a C program to use a buffer several kilobytes large. Alexander