This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- From: Zack Weinberg <zackw at panix dot com>
- To: Björn Esser <bjoern dot esser at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 1 Jun 2017 14:44:25 -0400
- Subject: Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
Here are some high-level comments; I have not reviewed the code in detail.
First, if we were designing from scratch today, we wouldn't have
crypt(3) in the C library at all; it would make more sense to keep it
with the implementations of login(1) and passwd(1), i.e. the PAM
suite. Indeed, I see that PAM independently implements the $1$
md5-based format and something called "bigcrypt". We're stuck with
crypt(3), the function, in glibc forever because it's in POSIX, but I
have to wonder whether it might make more sense to move _all_ of the
modern password hashes into PAM and _drop_ them from glibc. And
perhaps move the now-legacy-DES-only function into libc proper and
drop libcrypt, freeing the library name for PAM or some other project
to adopt. That would render the question of OpenWall's additional APIs
It would make sense to keep many password-hashing algorithms in libc
if there are a substantial number of programs _other_ than PAM that
use our crypt(), and/or if we think that we can keep up with password
hashing algorithms more efficiently than PAM can -- it's not clear to
me how actively maintained that project is. Can you, or anyone
comment on that?
I agree with Joseph and Florian that we want to review the new APIs
independently from the addition of bcrypt support, and I would suggest
that you look at implementing crypt_checkpass and crypt_genhash [see
http://man.openbsd.org/crypt_checkpass.3] as well. We would ensure
that everything was laid down together for the same _release_, but
review will be much simpler if we can look at the APIs and the
I also agree that documentation for the new APIs is required, and I
would add that the existing documentation for crypt() itself fails to
describe all of the hash formats that we already have. (Relatedly,
what exactly are the differences among formats 2a, 2b, 2x, and 2y?
That needs to be documented as well. If, as is hopefully the case,
only one should be used for new hashes, say so.)
To avoid confusion I strongly recommend referring to the new algorithm
as "bcrypt" and never as "blowfish-based".
Are there any other algorithms we should be adding at the same time?