Alex, > 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.
It's not a huge rush, but at the same time I'd like to get it in by 5.5. The RFC process takes at minimum 3 weeks from official proposal (2 week discussion + 1 week voting). And I haven't officially proposed it yet. So there's still some time. > Note: _if_ you ask for a portable hash. What else should it do if you > ask it for just that? That's a fair point. I guess since the adoption of 5.3, and the fact that 5.2 is dead (yet alone php4), has me thinking that "portable" means something different today than it did then... >> > 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. That's fair. Perhaps the documentation needs updating to indicate that *portable* really just means compatibility with php <= 5.2... > 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. That's a very good point. And it's already designed into the API. Right now, it only implements one algorithm in the core, but the switches and options are all there to support multiple. I just didn't see any solid reason to include the other (slightly less favored) crypt() hashes available today (SHA512 for example). But it's designed so that they can be added easily. I know there's talk floating around the list with respect to adding scrypt support into core. If that happens, it would definitely be added to the implementation. > 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. ;-) No rush at all. I like the concept though. Would it be worth while to add an implementation of salsa20/8 to the core? > 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. Well, part of the reason for this API, is that it appears that the majority of developers either aren't willing to use a library, or don't know it exists (even though it's very easy to find if you try). Additionally, I would think there would need to be a vetting period for a new KDF like this (for review, and trial implementations and such) before it would be considered "stronger" than bcrypt. If that's the case, then the core implementation would work fine. You implement the new KDF in a library. It goes through vetting and testing. if all is good, when it's mature it can be added back into core in this API. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
