FWIW, I am not super-keen on this particular move. Whilst bcrypt is certainly an improvement, I am wary of relying on Blowfish - it is not a mainstream cipher and is not subject to the kind of scrutiny that, say, AES or SHA-2/3 are.
If we are going to change, then we should change to a mechanism that is subject to ongoing cryptanalysis. On Mon, Jul 2, 2012 at 8:02 PM, Stefan Fritsch <s...@sfritsch.de> wrote: > On Sunday 01 July 2012, William A. Rowe Jr. wrote: >> On 6/29/2012 4:23 AM, Stefan Fritsch wrote: >> > Therefore I will go ahead and add bcrypt support to apr-util >> > which will be a big improvement for the 95% of users who don't >> > need FIPS. >> >> It sounds to me that after we spent a great deal of time to make >> APR largely library agnostic, you are insisting on binding us to a >> specific library. I would be very hostile to that. >> > > No. As I have mentioned in one of the other mails, I prefer importing > a suitably licensed version of the source code. > > What I currently have is > > http://people.apache.org/~sf/apr_bcrypt_password_support.diff > > diffstat: > > build.conf | 2 > crypto/apr_md5.c | 145 ------- > crypto/apr_passwd.c | 196 ++++++++++ > crypto/crypt_blowfish.c | 902 ++++++++++++++++++++++++++++++++++++++ > crypto/crypt_blowfish.h | 27 + > include/apr_md5.h | 5 > > >> If you are talking about a plugable, client-agnostic approach which >> the user can ignore the details of how apr was built, that would be >> fine. >> >> Before throwing code at APR, please post a patch, because the group >> might largely be in agreement. The delta to configure.in and the >> headers is probably sufficient for now. But if your solution is to >> add more mandatory dependencies or make apr less flexible, it would >> be met with resistance. > > No new dependency, no configure.in change. Instead I add two files > from the crypt_blowfish distribution. I intend to make some benchmarks > with the assembler version, but it says it was written for Pentium 1, > so I am not so sure that it will greatly improve performance on > current processors. If it is actually significantly faster than the > pure C version, I would add it plus the necessary build logic. That > would mean one additional file (there is only an assembler version for > i386). > > The diff of crypt_blowfish.c versus upstream is one line. So importing > new versions if there happen to be any upgrades should be easy. > >> >> The user should remain largely oblivious whether the pw crypt used >> lives in bcrypt or openssl or the kernel, and the resulting pw data >> should be always portable between different builds of apr. This >> was the logic behind the sha1, md5 and other common password >> schemes. The crypt scheme was an exception, one which can be >> resolved even on win32 and hpux with the use of openssl's crypt >> implementation or linking to fcrypt. >> >> Platform or library binding dependent pw data takes us back to >> 1999. > > Yes. That's why I was sceptical about using apr_crypto for this task, > too. After all, apr_crypto is still optional. > > Cheers, > Stefan
