From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1110 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: FreeSec crypt() Date: Wed, 13 Jun 2012 16:43:25 +0400 Message-ID: <20120613124325.GD22021@openwall.com> References: <20120612235113.GA21296@openwall.com> <20120613011842.GA163@brightrain.aerifal.cx> <20120613061032.GH17860@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 1339591409 26662 80.91.229.3 (13 Jun 2012 12:43:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2012 12:43:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1111-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 13 14:43:28 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 1Semv1-0001Rd-Rr for gllmg-musl@plane.gmane.org; Wed, 13 Jun 2012 14:43:28 +0200 Original-Received: (qmail 15372 invoked by uid 550); 13 Jun 2012 12:43:27 -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 15364 invoked from network); 13 Jun 2012 12:43:27 -0000 Content-Disposition: inline In-Reply-To: <20120613061032.GH17860@port70.net> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:1110 Archived-At: On Wed, Jun 13, 2012 at 08:10:32AM +0200, Szabolcs Nagy wrote: > static int ascii_to_bin2(int c) > { > if (c >= 128) > c += -128 + 18; > else if (c >= 97) > c += -97 + 38; > else if (c >= 65) > c += -65 + 12; > else > c += 128 + 18; > return (unsigned)c % 64; > } I think we should use a lookup table instead, which would also reduce the timing leaks we have here. Salts are not secret (not any more than the hashes), but they're not supposed to be known to an attacker in advance (before the hashes are possibly leaked/stolen) and knowing them (but not yet the hashes) may enable char-by-char timing attacks on hash encoding comparisons (thereby leaking the hashes after _many_ tries). This is almost purely theoretical for a number of reasons, yet if we strive for perfection, we should do the right thing in this respect as well. Perhaps the same lookup table should also replace ascii_is_unsafe() by returning a value outside of the 0 .. 63 range in the unsafe cases. We'd need to check for such out of range values, then. Thank you for your comments! Alexander