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.