tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: crypt_r()?

On 2/15/2022 5:04 PM, Mouse wrote:
(2) Hashing password, which takes the password and the settings and returns an allocated string with the resulting hash. [...]
I really don't like making them depend on malloc, though I have a hard time articulating what bothers me about it.

I can't say what bothers *you* about it :^) but what bothers me is that it makes it impossible to pre-allocate memory for the purpose.  This might be a concern, for example, on a system with no swap.

Combine that with a need for thread safety, say for a threaded login daemon on a system with no swap, and you get crypt_r(3) as described.

Of course the clearest use-case for crypt_r(3) is a password cracker: each thread sets up its own local memory and blasts through calls to crypt_r(3) as fast as it can.  I've run a cracker as a white-hat.  But I can see not wanting to add the capability to base if that's the only convincing use case.

Take care,

    Konrad Schroder

Home | Main Index | Thread Index | Old Index