From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1645 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Help-wanted tasks for musl Date: Sun, 19 Aug 2012 18:56:52 +0200 Message-ID: <20120819165652.GE16602@port70.net> References: <20120819042611.GA8731@brightrain.aerifal.cx> <20120819114914.GD16602@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: ger.gmane.org 1345395429 3438 80.91.229.3 (19 Aug 2012 16:57:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Aug 2012 16:57:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1646-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 19 18:57:09 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 1T38oE-0002AN-4y for gllmg-musl@plane.gmane.org; Sun, 19 Aug 2012 18:57:06 +0200 Original-Received: (qmail 9693 invoked by uid 550); 19 Aug 2012 16:57:04 -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 9683 invoked from network); 19 Aug 2012 16:57:04 -0000 Content-Disposition: inline In-Reply-To: <20120819114914.GD16602@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1645 Archived-At: * Szabolcs Nagy [2012-08-19 13:49:14 +0200]: > * Rich Felker [2012-08-19 00:26:11 -0400]: > > Preparing MD5 and SHA crypt for integration > > > > See the threads on the list. Basically we need source with appropriate > > license status (MIT/BSD/permissive or public domain) that's optimized > > for size. > > > > i'm looking into this > > fun fact: > the sha based crypt (the modern one designed in 2007, > but it follows the old weird md5 crypt algo) > has limits on the rounds but no mention of limits on keys > > http://www.akkadia.org/drepper/SHA-crypt.txt > > eventhough > > step 11. is O(keylen * log(keylen)) > step 14. is O(keylen^2) (!) > step 16. the reference implementation uses alloca(keylen) (!!) > step 21. is O(keylen * rounds) > i have preliminary code for md5 and sha crypt http://port70.net/~nsz/crypt/ but i found other design problems with sha crypt 1) keylen is not limited while the algo is O(keylen^2) (see above) 2)* according to the spec 'rounds=$' prefix should be recognized as an iteration specification, but the reference implementation (and in glibc) accepts empty or whitespace only N as well, ie. '$5$rounds= $' is treated as '$5$rounds=0$' 3)* reference implementation and glibc accepts negative rounds in an implementation defined way, ie. '$5$rounds=-4294965296$' is treated as '$5$rounds=2000$' on a 32bit system and as '$5$rounds=999999999$' on a 64bit one (according to spec N is clamped into 1000...999999999 so the correct treatment would be '$5$rounds=1000$') 4) if the rounds part is not closed by '$' then it is treated as a salt, but in the output there will be a $ after the salt so it will look like a proper rounds setting, so output should be treated carefully when the salt has to be parsed back, ie. '$5$rounds=1000' setting will result in an output like '$5$rounds=1000$' where the salt is 'rounds=1000' the output can be correctly parsed (based on the $s) but it's not possible to use the output as a setting like in the md5 crypt case i don't know if this is a real issue, but it seems ugly * the cause of 2) and 3) is that the reference implementation recognizes rounds=$ if strtoul returns with the end pointer on a '$' so strtoul semantics should be assumed for the '$' part which depends on ULONG_MAX value in case of negative numbers and may modify errno etc