Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60998
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120627130734.GA17477@openwall.com>
References: <CAF+90c-6VWJ_kBW=Z8Br-NOxKyuTkwStRg-OMBa6844w3=CjDA@mail.gmail.com>
	<CAKOpQSzHLWhQxe9D2hjAo+O4AevoAEL4vFAhkoyxiZS8fvc3GA@mail.gmail.com>
	<CAAUB37CP1pCKCAvvQ56EkeT_0VdjpXwd_=FnQct+9XZTou0_GA@mail.gmail.com>
	<CAAyV7nEKuta7rFx2ZAQQyD6JMA6z2G3UGF-ETmPbcs73vy74GQ@mail.gmail.com>
	<CAEZPtU7pH1mW-_sF1pPw=-8zYG-cFEd8XQk7N4KnWFNuKF3jAQ@mail.gmail.com>
	<20120627092217.GA16399@openwall.com>
	<CAAyV7nHBSCasLi1BzvRx09LjMF0GgnO_s0ydGiY=asXCVgp4Sw@mail.gmail.com>
	<20120627130734.GA17477@openwall.com>
Date: Wed, 27 Jun 2012 09:16:47 -0400
Message-ID: <CAAyV7nE9fHw1V9j06bqZ65u6tMt+P=FscJE_sHoe1GO-5if--g@mail.gmail.com>
To: Solar Designer <solar@openwall.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Herman Radtke <hermanradtke@gmail.com>, 
	Nikita Popov <nikita.ppv@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Adding a simple API for secure password hashing?
From: ircmaxell@gmail.com (Anthony Ferrara)

Alexander,

> BTW, what version of PHP introduced the =3D=3D=3D comparison operator?
> I guess this should become the minimum version for phpass since this is
> highly desirable to use.
>
> http://www.php.net/manual/en/language.operators.comparison.php does not
> say anything about that.
>

That's been in there for quite some time... I know at least php 5.0
had it (and I'm pretty sure it was 4)...

> Thank you for not including other crypt() hashes. =A0I fully support
> starting with bcrypt only, and only adding to it if there's something
> actually better, not just for the sake of giving more options to a user
> who can't make an educated decision.

I originally included them, but then it was pointed out that they are
weaker, and I was asked *why include them*. when I couldn't answer, I
pulled them...

> In the same spirit, while I support your proposal to add PBKDF2 to PHP
> proper, let's not add a crypt()-like hash encoding based on PBKDF2.
> I'd rather not see additional weaker-than-bcrypt hash types in use.
> In other words, I oppose your $pbkdf$ thing from PHP-PasswordLib. ;-)

I had no plan on adding that to the core... So we're in perfect
agreement there... (although in a side-lib, I don't see the harm as
long as it's not default).

> For that, we'd need to decide on a proper crypt() hash encoding syntax
> for scrypt - something Colin chose not to do so far. =A0At the very least=
,
> we'd need to know and consider his current opinion on the matter. =A0IIRC=
,
> when I asked in 2010 (in March or April), his reply was that he did not
> feel scrypt was mature enough for that (it was about 1 year old at the
> time, since 2009).

Agree. If I was to add it (I've been thinking about it), I would add
it along side hash_pbkdf2 as hash_scrypt(). I would prefer waiting for
the standard encoding syntax (so that we're not creating a new one) to
include it in crypt().

> It might happen that we come up with another memory-hard function to use
> for password hashing before there's an agreed upon hash encoding syntax
> for scrypt in particular. =A0To me, this possibility is a reason not to
> hurry with introducing such syntax for scrypt. =A0We also need to decide
> on an approach to this:
> http://www.openwall.com/lists/crypt-dev/2011/05/12/4
> (dealing with the memory requirements with concurrent authentication
> requests). =A0Well, maybe just require relatively little memory - way mor=
e
> than bcrypt, but less than what scrypt was originally designed for.

Sure...

> Meanwhile, I suggest that we treat scrypt just like we do PBKDF2 -
> provide a native function for it as a KDF, but no crypt() hash encoding
> syntax for its use for password authentication yet (even though this
> might be a more relevant use of it in PHP in the long run).

Again, agreed.

> Maybe, but if we add scrypt proper then I see little use for Salsa20/8
> on its own.

Very true. Was just a thought.

> What was the reason why Salsa20 was dropped in 5.4 (it was in 5.3, but
> probably not usable for scrypt because of different round count)?

I don't know. I was trying to find that out but everywhere I looked
turned into a dead end.

Thanks,

Anthony