[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110502180336.GA20095@openwall.com>
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.
