[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120813222058.GB8817@openwall.com>
Date: Tue, 14 Aug 2012 02:20:58 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: Todo for release?
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. glibc has recently fixed that by using malloc() and
returning NULL on its failure, but that's not great.
Also, if potentially unreasonably long running time is a concern, it
should be noted that for md5crypt and sha*crypt it is roughly
proportional to password length (modulo block size of the underlying
primitive). So e.g. a 1 million char password (which may realistically
be passed to libc's crypt() e.g. via a scripting language) may take
thousands of times longer to be hashed than the sysadmin had intended by
tuning the iteration count.
I'm not sure whether and how a libc should deal with that. In a sense,
it is similar to the issue of high iteration counts, but it's worse in
that the input that may trigger the issue very often comes from a remote
system.
For the extended DES-based crypt() hashes that we now support, this
issue mostly does not arise since the password (even if very long, which
is supported) is passed through just one instance of DES block-by-block,
which is quick. The multiple iterations loop is then applied to the
"compressed" version of the password.
For bcrypt hashes, the issue does not arise because they truncate
passwords at 72 characters (not great, but that's how they're defined,
and it's good enough for practical purposes so far).
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.
