[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Aug 2012 09:06:23 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: crypt* files in crypt directory
On Wed, Aug 08, 2012 at 09:52:34AM +0200, Szabolcs Nagy wrote:
> * Solar Designer <solar@...nwall.com> [2012-08-08 08:42:35 +0400]:
> > I see that you did this - and I think you took it too far. The code
> > became twice slower on Pentium 3 when compiling with gcc 3.4.5 (approx.
> > 140 c/s down to 77 c/s). Adding -finline-functions
> > -fold-unroll-all-loops regains only a fraction of the speed (112 c/s);
> > less aggressive loop unrolling results in lower speeds.
> >
>
> i thought slowness is a feature in this case..
>
> at least that was the general agreement about the
> size vs speed tradeoff of the des code
Solar's argument is that if you want more slowness, you should just
use a higher iteration count that also affects people trying to crack
your passwords. And being slower at the same count discourages
increasing the count.
Actually this brings up a HUGE DoS vuln in blowfish crypt: with tcb
passwords, a malicious user can put a password with count=31 (it's
logarithmic, so this means 2^31) in their tcb shadow file. This will
cause a root-owned process to eat 100% cpu for hours if not days.
Perform a few simultaneous login attempts and the whole server becomes
unusable.
I don't know how to solve it, but in musl I think we'll have to put a
low limit on count if we're going to support blowfish. Unfortunately I
don't see a good way to make it runtime configurable without
hard-coding additional non-standard config paths, but letting the DoS
bug slip in is not acceptable.
Rich
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.
