[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Aug 2012 22:35:08 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Todo for release?
On Tue, Aug 14, 2012 at 06:13:17AM +0400, Solar Designer wrote:
> On Mon, Aug 13, 2012 at 09:46:53PM -0400, Rich Felker wrote:
> > On Tue, Aug 14, 2012 at 02:20:58AM +0400, Solar Designer wrote:
> > > On Mon, Aug 13, 2012 at 11:31:54PM +0200, Szabolcs Nagy wrote:
> > > > the sha2 based crypt seems to be designed recently
> > > > and the spec has a public domain implementation
> > > > http://www.akkadia.org/drepper/SHA-crypt.txt
> > >
> > > Unfortunately, the reference implementation uses alloca() on both salt
> > > and key strings.
> >
> > Why? Does it need working space proportional to the input length?
>
> It uses implementations of SHA-512 and SHA-256 that assume alignment, so
> it provides such alignment by copying the inputs to aligned buffers if
> the inputs to crypt() don't happen to be already aligned.
This could be solved by doing the copy a block at a time, and
submitting the blocks to the encryption code a block at a time.
Failure to do so is just laziness, and it's the same type of laziness
that's all over glibc.
If this issue is as simple to solve as it sounds, it might make sense
to allow arbitrary key sizes. After all, programs that could be DoS'd
by long keys are already going to be limiting key length themselves.
If time grew superlinearly in key length, I'd say it should definitely
be limited, but since the growth is just linear (the expected growth
rate for any interface that takes a string argument), I think it's
less clear what should be done.
> > In light of both the alloca issue and the way runtime scales with key
> > length, I think we should just put an arbitrary limit on the key
> > length and return failure for longer keys. This should not affect any
> > real-world authentication systems, since the daemon you're attempting
> > to login to will also be placing a (probably much lower) limit on the
> > input buffer size for passwords (if it's not, you can trivially DoS
> > the server by sending gigabyte-long passwords for random users).
> >
> > Something like 128-256 bytes would probably be a very generous limit.
>
> Yes, but the failure should be indicated in the way we discussed - those
> "*0" and "*1" strings, not NULL.
Yes, it should be treated like any other invalid input and hashed to
something that can never match. By the way, would you agree that all
programs that generate new password hashes should do so by calling
crypt twice, the second time using the output of the first as the
setting/salt, and verify that the results match? This seems to be the
only safe/portable way to make sure you got a valid hash and not an
error.
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.
