Re: crypt_r()?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> There are two sensible interface contracts here:

> (1) Verification only, which takes the password and the expected hash
> and returns a bool.  [...]

> (2) Hashing password, which takes the password and the settings and
> returns an allocated string with the resulting hash.  [...]

Well, I disagree about the "allocated" part; I think there is a place
for returning into a buffer specified by the caller.

But, more what's leading me to write now: if you go with (1), you still
need something like (2) in order to _set_ passwords.  (2) - or
something like (2) into a caller-specified string - can be used for
either checking or setting.  (1) can't.

> Given that the goal of the crypt(3) interface is to be slow,
> optimizing a memory allocation away saves nothing, except making a
> more complicated interface.

I disagree.  It saves a bunch of error paths.  Many (most? all?) of the
password hashing algorithms run, or can be made to run, without needing
any heap memory at all, if you use a caller-provided buffer for the
returned string.  I really don't like making them depend on malloc,
though I have a hard time articulating what bothers me about it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B