Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: Ben Laurie <ben@links.org>
Subject: Re: Choosing a stronger password hash algorithm
Date: Mon, 2 Jul 2012 21:46:19 +0200
User-Agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; )
References: 
 <CAMD-=VJS7f49CoCjMvhz0j8t=uf2xnaaCuxkA36J34brj2OoyQ@mail.gmail.com>
 <201207022102.12181.sf@sfritsch.de>
 <CAG5KPzx-6-5Hr7VD2i0ZHNVekAtUyEJAQU4OtgWeFN1jT+vAGA@mail.gmail.com>
In-Reply-To: 
 <CAG5KPzx-6-5Hr7VD2i0ZHNVekAtUyEJAQU4OtgWeFN1jT+vAGA@mail.gmail.com>
Cc: dev@apr.apache.org
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201207022146.19376.sf@sfritsch.de>

On Monday 02 July 2012, Ben Laurie wrote:
> FWIW, I am not super-keen on this particular move. Whilst bcrypt is
> certainly an improvement, I am wary of relying on Blowfish - it is
> not a mainstream cipher and is not subject to the kind of scrutiny
> that, say, AES or SHA-2/3 are.
> 
> If we are going to change, then we should change to a mechanism
> that is subject to ongoing cryptanalysis.


bcrypt has the advantage that it currently does not give much speed-up 
of GPUs versus CPUs. So brute-forcing is more difficult than e.g. for 
glibc's sha256 or sha512 based algorithms. And we can't just 
arbitrarily increase the number of rounds because that would make 
httpd prone to DoS attacks. My rationale for bcrypt is here:

http://mail-archives.apache.org/mod_mbox/apr-
dev/201206.mbox/%3C201206232242.42669.sf%40sfritsch.de%3E

Your comments on that would be welcome.

Due to Poul-Henning Kamp's declaration that md5crypt is insecure, 
there is some renewed interest in this field. Maybe there will be a 
new algorithm soon that is both difficult to brute-force on GPUs and 
based on something standard like AES or SHA*.

Maybe we could add bcrypt for now and if something better appears, 
then add that as well?

Cheers,
Stefan