Re: FreeSec DES-based crypt(3)

[Solar Designer <solar@openwall.com>]

On Mon, May 02, 2011 at 09:49:52AM -0400, Rich Felker wrote:
> I could consider using malloc to obtain
> a permanent des state, allocated and initialized on first use, with
> fallback to the stack if malloc fails.

This makes sense.

You might be over-estimating the cost of non-const static storage,
though.  It will only consume address space, not actual memory, until a
process actually invokes crypt(3) for a DES-based hash, in which case
the cost will be the same as above.

> But I'm wondering if it's
> really desirable for crypt to be fast anyway. Surely JtR wants a fast
> crypt, but my impression was always that slow crypt was a cheap way to
> get some added defense against brute force login attempts and such...

There's a difference between inherently slow crypt and merely a slow
implementation, and remote attacks are better dealt with in a different
way, in my opinion.  I don't want to discuss another bikeshed, so I'd
rather not go into detail.

JtR doesn't actually care much - it has its own optimized DES code (it'd
care about SHA-crypt's speed, because it doesn't support that natively
yet), but I just thought that you'd want musl not to be 50x slower than
glibc at this.

> P.S. crypt is in no way integrated with other parts of libc, so
> linking with -lfastcrypt (separate library) is a potentially viable
> option for situations where you want a fast one.

I think you'd want the default to be fast.  The approach with malloc
sounds fine to me - that way, you initially preserve the address space
as well.

Thanks,

Alexander