> On Jul 21, 2017, at 10:24 PM, Ted Unangst <t...@tedunangst.com> wrote:
>
> Scott Cheloha wrote:
>> crypt_newhash(3) will return -1 and set errno to EINVAL if hashsize is
>> too small to accommodate bcrypt's hash space. I imagine this would
>> also be the case i
Scott Cheloha wrote:
> crypt_newhash(3) will return -1 and set errno to EINVAL if hashsize is
> too small to accommodate bcrypt's hash space. I imagine this would
> also be the case if anything other than bcrypt were supported.
i went ahead and reworked the page a bit. i think it clarif
Hi,
crypt_newhash(3) will return -1 and set errno to EINVAL if hashsize is
too small to accommodate bcrypt's hash space. I imagine this would
also be the case if anything other than bcrypt were supported.
Test program:
#include
#include
#include
int
main(int argc, char *argv
ted, and
> > > +.Fa hashsize
> > > +must contain its size, which cannot be less than 61 bytes.
> >
> > that's an implementation detail. if we're advising a limit, i think we
> > should say 128 or so.
>
> How come? Tracing the code of crypt_newha
ain its size, which cannot be less than 61 bytes.
>
> that's an implementation detail. if we're advising a limit, i think we
> should say 128 or so.
How come? Tracing the code of crypt_newhash() we end up in
bcrypt_hashpass(), which has the following check:
if (encryptedl
Michal Mazurek wrote:
> When talking about this with mulander@ it came out that the docs could
> use a touch.
>
> The commit message for the diff that didn't update the docs was:
>
> permit "bcrypt" as an alias for "blowfish". this is, after all, what
> 99% of the world calls it.
>
On 21:16:08, 6.06.17, Michal Mazurek wrote:
> When talking about this with mulander@ it came out that the docs could
> use a touch.
>
> The commit message for the diff that didn't update the docs was:
>
> permit "bcrypt" as an alias for "blowfish". this is, after all, what
> 99% of the
Michal Mazurek wrote:
> Yes, the function seems a bit inconsistent, in that "bcrypt" means "bcrypt,a"
> but NULL means "bcrypt,8". awolk@ points out that the function is used in
> just a few places - src and some ports patches, so we should be able to
> change it. Judging by the commit message the
On Tue, Jun 06, 2017 at 08:29:23PM +, Florian Obser wrote:
> On Tue, Jun 06, 2017 at 08:49:32PM +0200, Adam Wolk wrote:
> > On Tue, Jun 06, 2017 at 12:28:59PM -0600, Theo de Raadt wrote:
> > > > The only thing against using automatic rounds would be having them
> > > > guessed on a
> > > >
> On 20:49:05, 6.06.17, Jason McIntyre wrote:
> > right now this man page suggests that people will use "bcrypt,a"
> > to "automatically suggest rounds based on system performance". is
> > that right? i'd have expected people to just use "bcrypt" (w/o
> > args).
Because you can't change
ypt_gensalt(8), sizeof(salt)) >= sizeof(salt))
> - errx(1, "salt too long");
> - if (strlcpy(hash, bcrypt(pass, salt), sizeof(hash)) >= sizeof(hash))
> - errx(1, "hash too long");
> + if (crypt_newhash(pass, "bcrypt,a", hash, sizeof(hash)) != 0)
> + err(1, "can't generate hash");
> explicit_bzero(pass, sizeof(pass));
>
> if (file == NULL)
--
I'm not entirely sure you are real.
On 20:49:05, 6.06.17, Jason McIntyre wrote:
> right now this man page suggests that people will use "bcrypt,a"
> to "automatically suggest rounds based on system performance". is
> that right? i'd have expected people to just use "bcrypt" (w/o
> args). in fact, why have "a" at all? why not just
have the default
as automatically selecting rounds, but you can optionally specify
an amount of rounds?
sorry, i know that's not really the main concern of your diff. it just
seems a bit weird, and that reflects in the way you're having to word
this.
jmc
> +.Dq blowfish
> +can be used a
owfish
+can be used as an alias for
+.Dq bcrypt .
.El
.Sh RETURN VALUES
.Rv -std crypt_checkpass crypt_newhash
@@ -89,7 +101,9 @@ to
.Er EINVAL
if
.Fa pref
-is unsupported.
+is unsupported, or the value of
+.Fa hashsize
+is insufficient.
.Sh SEE ALSO
.Xr crypt 3 ,
.Xr login.conf 5 ,
--
Michal Mazurek
s2, sizeof(pass2));
}
- if (strlcpy(salt, bcrypt_gensalt(8), sizeof(salt)) >= sizeof(salt))
- errx(1, "salt too long");
- if (strlcpy(hash, bcrypt(pass, salt), sizeof(hash)) >= sizeof(hash))
- errx(1, "hash too
> The only thing against using automatic rounds would be having them guessed on
> a
> weaker machine and used on a more powerful server - doubt though that would
> ever
> pick something below 8 rounds.
I don't see the concern. It has a lower bound.
hash))
> > - errx(1, "hash too long");
> > + if (crypt_newhash(pass, "bcrypt,8", hash, sizeof(hash)) != 0)
> > + err(1, "can't generate hash");
> > explicit_bzero(pass, sizeof(pass));
> >
> > if (file ==
ses the new crypt API
>
> The documentation for bcrypt states:
> These functions are deprecated in favor of crypt_checkpass(3) and
> crypt_newhash(3).
>
> I'm attaching a diff moving htpasswd to the new API. Tested with httpd from
> 6.1 with a htpasswd generated with the di
of crypt_checkpass(3) and
crypt_newhash(3).
I'm attaching a diff moving htpasswd to the new API. Tested with httpd from
6.1 with a htpasswd generated with the diff applied on current.
Feedback? OK's?
Regards,
Adam
? htpasswd
Index: htpasswd.c
to bcrypt_newhash(3) and
crypt_newhash(3) is undocumented, but judging from its name and uses
across the
tree, it obviously looks like the size of the hash buffer for bounds-checking
purposes. bcrypt_hashpass(3) never uses the size of the buffer, despite
printing
and base64 encoding
Hi,
The flak blog just had an interesting post about why the old crypt() interface
should be replaced, and on the new crypt_newhash() and crypt_checkpass() that
were added to OpenBSD. I would like to see this API become portable and perhaps
standardized, but crypt_newhash is currently tied
On Thu, Nov 20, 2014 at 19:29, Jonas 'Sortie' Termansen wrote:
Hi,
The flak blog just had an interesting post about why the old crypt()
interface
should be replaced, and on the new crypt_newhash() and crypt_checkpass() that
were added to OpenBSD. I would like to see this API become portable
On Thu, Nov 20, 2014 at 20:22, Ted Unangst wrote:
So far only passwd uses the new function; it is still easy for me to
change the interface. (The only constraint being that I need to
coordinate library changes with other developments so it may not be an
immediate change.)
Sneaking the change
23 matches
Mail list logo
