Recommended way to probe for bcrypt support?

Recommended way to probe for bcrypt support?

[Isaac Dunham]

I'm wondering if there's a recommended way to probe for bcrypt support;
it would be nice to add this to toybox so mkpasswd could use blowfish on
musl or OWL systems.

Thanks,
Isaac Dunham

Re: Recommended way to probe for bcrypt support?

[Rich Felker]

On Mon, Jun 23, 2014 at 02:53:58PM -0700, Isaac Dunham wrote:
> I'm wondering if there's a recommended way to probe for bcrypt support;
> it would be nice to add this to toybox so mkpasswd could use blowfish on
> musl or OWL systems.

The best way to do this is with runtime detection: simply attempt to
use crypt or crypt_r with a setting string that requests bcrypt and
see if it works.

Rich

Re: Recommended way to probe for bcrypt support?

[Solar Designer]

On Mon, Jun 23, 2014 at 06:33:39PM -0400, Rich Felker wrote:
> On Mon, Jun 23, 2014 at 02:53:58PM -0700, Isaac Dunham wrote:
> > I'm wondering if there's a recommended way to probe for bcrypt support;
> > it would be nice to add this to toybox so mkpasswd could use blowfish on
> > musl or OWL systems.
> 
> The best way to do this is with runtime detection: simply attempt to
> use crypt or crypt_r with a setting string that requests bcrypt and
> see if it works.

Sure.  This works for ./configure when we're fine with static
compile-time detection.  Unfortunately, at runtime detecting bcrypt in
this way is a bit slow since the minimum cost setting is 4 (meaning 16
iterations of the eksBlowfish loop).  For mkpasswd it is acceptable -
so do it - but e.g. in phpass I am reluctant to do it that way.

There's a way to detect crypt_blowfish-style error returns quicker, and
infer whether bcrypt support is likely present or not from that, but
there are systems that support bcrypt yet don't use these error returns,
so it won't detect bcrypt support present on those systems (including
OpenBSD, and that's unacceptable because bcrypt originates from there).

Alexander

Re: Recommended way to probe for bcrypt support?

[Rich Felker]

On Tue, Jun 24, 2014 at 03:17:35AM +0400, Solar Designer wrote:
> On Mon, Jun 23, 2014 at 06:33:39PM -0400, Rich Felker wrote:
> > On Mon, Jun 23, 2014 at 02:53:58PM -0700, Isaac Dunham wrote:
> > > I'm wondering if there's a recommended way to probe for bcrypt support;
> > > it would be nice to add this to toybox so mkpasswd could use blowfish on
> > > musl or OWL systems.
> > 
> > The best way to do this is with runtime detection: simply attempt to
> > use crypt or crypt_r with a setting string that requests bcrypt and
> > see if it works.
> 
> Sure.  This works for ./configure when we're fine with static
> compile-time detection.

Yes; I rather frown upon such compile-time detection though because it
precludes cross-compiling, and because such _behaviors_ (as opposed to
interfaces) tend to be things that change between versions. In the
case of libc supporting bcrypt this is not going to change, but in
principle it's a bad policy. Especially when presence/absence of a
feature might depend on kernel, and running on an older kernel than
the one used while compiling is likely to happen.

> Unfortunately, at runtime detecting bcrypt in
> this way is a bit slow since the minimum cost setting is 4 (meaning 16
> iterations of the eksBlowfish loop).  For mkpasswd it is acceptable -
> so do it - but e.g. in phpass I am reluctant to do it that way.

I'm not clear why it would be necessary to probe for it when not
actually attempting to use it, except in cases like providing a list
of supported hashes (e.g. --help or similar). The normal usage case
for "runtime probe" seems to be "try to use it, and report failure if
it's not available".

Rich

Re: Recommended way to probe for bcrypt support?

[Solar Designer]

On Mon, Jun 23, 2014 at 07:52:55PM -0400, Rich Felker wrote:
> On Tue, Jun 24, 2014 at 03:17:35AM +0400, Solar Designer wrote:
> > On Mon, Jun 23, 2014 at 06:33:39PM -0400, Rich Felker wrote:
> > > The best way to do this is with runtime detection: simply attempt to
> > > use crypt or crypt_r with a setting string that requests bcrypt and
> > > see if it works.
> > 
> > Sure.  This works for ./configure when we're fine with static
> > compile-time detection.
> 
> Yes; I rather frown upon such compile-time detection though because it
> precludes cross-compiling, and because such _behaviors_ (as opposed to
> interfaces) tend to be things that change between versions. In the
> case of libc supporting bcrypt this is not going to change, but in
> principle it's a bad policy. Especially when presence/absence of a
> feature might depend on kernel, and running on an older kernel than
> the one used while compiling is likely to happen.

Presence/absence of bcrypt support may vary between (patched) glibc
versions and builds, especially since it's not available upstream.

> > Unfortunately, at runtime detecting bcrypt in
> > this way is a bit slow since the minimum cost setting is 4 (meaning 16
> > iterations of the eksBlowfish loop).  For mkpasswd it is acceptable -
> > so do it - but e.g. in phpass I am reluctant to do it that way.
> 
> I'm not clear why it would be necessary to probe for it when not
> actually attempting to use it, except in cases like providing a list
> of supported hashes (e.g. --help or similar). The normal usage case
> for "runtime probe" seems to be "try to use it, and report failure if
> it's not available".

Yes, or fallback to something else.

Alexander

Re: Recommended way to probe for bcrypt support?

[Isaac Dunham]

On Mon, Jun 23, 2014 at 07:52:55PM -0400, Rich Felker wrote:
> > Unfortunately, at runtime detecting bcrypt in
> > this way is a bit slow since the minimum cost setting is 4 (meaning 16
> > iterations of the eksBlowfish loop).  For mkpasswd it is acceptable -
> > so do it - but e.g. in phpass I am reluctant to do it that way.
> 
> I'm not clear why it would be necessary to probe for it when not
> actually attempting to use it, except in cases like providing a list
> of supported hashes (e.g. --help or similar). The normal usage case
> for "runtime probe" seems to be "try to use it, and report failure if
> it's not available".
FYI, (toybox) mkpasswd has "-m help".
(passwd currently has a static list of hashes.)

Thanks,
Isaac Dunham