[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120814024903.GA10188@openwall.com>
Date: Tue, 14 Aug 2012 06:49:03 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: Todo for release?
On Mon, Aug 13, 2012 at 10:35:08PM -0400, Rich Felker wrote:
> 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:
> > > > > 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.
Note that this moves the copying inside the many-iterations loop, so
there will be a difference in speed.
That said, yes, e.g. my public domain implementation of MD5 avoids the
alignment requirement by possibly copying the block the first time it's
used. There may be some performance hit from using it to implement
md5crypt as compared to using glibc's implementation of MD5 (because the
copying will in fact be in the 1000 iterations loop), but not much - and
overall my implementation might be faster (for other reasons),
especially on x86, where the copying may be avoided altogether in favor
of possibly unaligned accesses.
> 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.
That's wishful thinking.
> 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.
Yes, it is not clear what should be done.
> > 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.
This makes sense, yet it sounds overkill to me. I'd simply check for
hash && strlen(hash) >= 13.
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.
