Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120613124325.GD22021@openwall.com>
Date: Wed, 13 Jun 2012 16:43:25 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: FreeSec crypt()

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.