Re: Todo for release?

[Solar Designer <solar@openwall.com>]

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.

The same applies to glibc's md5crypt (but we're not going to use that
implementation of md5crypt anyway).

> 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.  Some real-world authentication systems
may be affected; it is not unrealistic even for a C program to use a
buffer several kilobytes large.

Alexander