Re: crypt_r()?

[Joerg Sonnenberger <joerg%bec.de@localhost>]

Am Tue, Feb 15, 2022 at 08:04:29PM -0500 schrieb Mouse:
> > 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.

All modern password hashing algorithms use a large memory buffers and
will attempt to scale them according to system ressources. This applies
at least to ARGON2 (which we include) and scrypt. Thi is an essential
hardening step against FPGA/custom ASIC implementations. Even ignoring
that, the application has to deal with errors at least from general
password hashing function anyway, so there is no extra complexity in the
application.

Joerg