Hi all, On Sat, Jun 16, 2012 at 03:39:35PM +0200, Pierre Joye wrote: > Adding Alex to the loop as his insight will be unvaluable in this thread.
Thank you for the chance to comment, and sorry that I did not do so yet. I am busy with lots of other stuff. I'd appreciate it if you don't hurry to implement this stuff too much, and I likely will comment on it (that is, on the actual proposed API and implementation). Please keep me in the loop. > On Sat, Jun 16, 2012 at 2:41 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > > >> This userland library already solves all the issues you outlined with > >> bcrypt: http://www.openwall.com/phpass/ > > > > That library is not without its issues. For example, if you ask for a > > portable hash, it gives you a custom algorithm instead of bcrypt. > > That's because the library is php4 compatible. Note: _if_ you ask for a portable hash. What else should it do if you ask it for just that? > > So for modern versions > > of PHP (5.3+), it produces an unnecessarily weak hash. For modern versions of PHP, if you don't require portability of hashes to older versions, don't ask it for a portable hash. Of course, new PHP apps that will depend on your new API won't run on older versions of PHP by definition, so they could assume bcrypt is available. A concern, though, is that by the time major web apps would be able to assume a recent enough version of PHP (with this new API) we'll prefer to use a password hashing method with more than one configurable parameter (not just one "cost" setting), so we may want to design the API with that in mind. Additionally, I was/am going to experiment with implementing a decent KDF in PHP, but also considering its native reimplementation at the same time (for inclusion in PHP proper, etc.) That way, we could have hashes that are both portable (to older versions of PHP, to other scripting languages, etc.) and efficient. My expectation is that when implemented in a scripting language (using a widely-available crypto primitive like SHA-512 or AES), they could be somewhere inbetween bcrypt and scrypt in terms of cost of attack - and when reimplemented natively, they could be approaching scrypt (although Colin's choice of Salsa20/8 core for the crypto primitive was not arbitrary, and unfortunately we don't have that in PHP). I feel that there's room for exactly one such would-be de-facto standard "scripting KDF", and I might be in a position to set this standard due to phpass (this new thing could be a next generation phpass). But I haven't decided on this yet, I'd need to experiment first, and I don't like to be rushed. ;-) http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00051.html I think it's OK/preferable not to introduce this new hash type earlier than in a year from now or so, unless there's imminent threat of someone else doing it substantially worse. ;-) Meanwhile, I don't mind having an API that would provide bcrypt, even though I think that phpass does this well enough (and I intend to release a minor update to this first generation phpass). As long as we're not introducing a new hash type to this world yet, we are OK to experiment with APIs, etc. Alexander -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
