On Sat, Jul 21, 2012 at 05:23:24PM +0200, Łukasz Sowa wrote:
> Together with Daniel we've prepared initial patch for inclusion crypt_blowfish
> and crypt_gensalt in musl. Things to change were rather cosmetic. Both blowfish
> and gensalt implementations don't use global state, only const statics (which
> needed simply 'const' to meet musl standard). Besides that code looks quite
> clean & nice.

I've been looking at the code some now that I got the 0.9.3 release
out of the way, and I have a few questions for you and the
community...

First, the compatibility code for the sign extension bug. How
important is it to keep this? Part of my question is that I'm having a
hard time understanding how it's useful. For passwords that were
subject to collisions due to this bug, it seems like there's nothing
that can be done except discarding the old hashes, since they're
vulnerable. So my understanding is that the bug-compatibility code
just serves to keep the subset of old hashes of 8-bit passwords that
were _not_ subject to collisions from becoming unusable. I.e. the
bug-compat code only benefits users who:

1. Used passwords containing 8-bit characters
2. Happened to be using a password that was not subject to the
collision bug, and
3. Did not regenerate hashes after the bug was fixed.

I'm uncertain whether there's any portion of musl's user base that
this would be useful to.

For folks completely unfamiliar with the issue, here's an LWN article:
http://lwn.net/Articles/448699/

Second, what can be done to reduce size? I think the first step is
replacing the giant macros (BF_ROUND, BF_ENCRYPT, etc.) with
functions so that the code doesn't get generated in duplicate unless
aggressive inlining is enabled by CFLAGS. But are there other things
that would help? With the data tables being 4k in size, I'm thinking
a reasonable target size for the whole file might be 7k.

Actually while writing this, I made some quick changes and seem to
have already achieved that goal. See the attached file. It's untested,
so I might have broken something in the process. I'm not sure I'll
have time to test it well right away, so I'd appreciate comments on
whether it works as well as any other possible improvements... :-)

Rich