Date: Mon, 2 May 2011 22:03:36 +0400 From: Solar Designer <solar@...nwall.com> To: musl@...ts.openwall.com Subject: Re: FreeSec DES-based crypt(3) 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.