From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1578 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Todo for release? Date: Mon, 13 Aug 2012 22:35:08 -0400 Message-ID: <20120814023508.GD27715@brightrain.aerifal.cx> References: <20120813185329.GA20024@brightrain.aerifal.cx> <20120813213154.GI20243@port70.net> <20120813222058.GB8817@openwall.com> <20120814014652.GC27715@brightrain.aerifal.cx> <20120814021317.GA10036@openwall.com> 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 1344911654 32348 80.91.229.3 (14 Aug 2012 02:34:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2012 02:34:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1579-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 14 04:34:13 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 1T16xQ-0005xA-So for gllmg-musl@plane.gmane.org; Tue, 14 Aug 2012 04:34:13 +0200 Original-Received: (qmail 24527 invoked by uid 550); 14 Aug 2012 02:34:11 -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 24519 invoked from network); 14 Aug 2012 02:34:11 -0000 Content-Disposition: inline In-Reply-To: <20120814021317.GA10036@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1578 Archived-At: On Tue, Aug 14, 2012 at 06:13:17AM +0400, Solar Designer wrote: > 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. This could be solved by doing the copy a block at a time, and submitting the blocks to the encryption code a block at a time. Failure to do so is just laziness, and it's the same type of laziness that's all over glibc. If this issue is as simple to solve as it sounds, it might make sense to allow arbitrary key sizes. After all, programs that could be DoS'd by long keys are already going to be limiting key length themselves. If time grew superlinearly in key length, I'd say it should definitely be limited, but since the growth is just linear (the expected growth rate for any interface that takes a string argument), I think it's less clear what should be done. > > 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. Yes, it should be treated like any other invalid input and hashed to something that can never match. By the way, would you agree that all programs that generate new password hashes should do so by calling crypt twice, the second time using the output of the first as the setting/salt, and verify that the results match? This seems to be the only safe/portable way to make sure you got a valid hash and not an error. Rich