# [RFC] Add hash_pbkdf2 function - Thread: https://externals.io/message/60884 - Original archive: https://news-web.php.net/php.internals/60884 - Started by Anthony Ferrara on 2012-06-18T23:14:06+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #60884 — Anthony Ferrara — 2012-06-18T23:14:06+00:00 URL: https://externals.io/message/60884#60884 Hello all, Since there wasn't that much traffic on the draft version of the RFC, I've moved it into Proposed. https://wiki.php.net/rfc/hash_pbkdf2 What are your thoughts? Thanks, Anthony --- ## #60885 — Adam Jon Richardson — 2012-06-19T06:24:36+00:00 URL: https://externals.io/message/60884#60885 · In reply to: #60884 >  https://wiki.php.net/rfc/hash_pbkdf2 > > What are your thoughts? That's very nice, indeed. One thing I'm wondering about is whether the last parameter could be changed from: raw_output = false To something like: output = "hex" (also allowing output = "raw", output = "base64") Just thinking that most of the time I'd prefer storing the hashed passwords as base64-encoded strings just because it's more compact, but this isn't a big deal, just a thought. Really nice work! Adam --- ## #60886 — Tjerk Meesters — 2012-06-19T10:23:28+00:00 URL: https://externals.io/message/60884#60886 · In reply to: #60885 > > > […] > > That's very nice, indeed. > > One thing I'm wondering about is whether the last parameter could be > changed from: > raw_output = false > > To something like: > output = "hex" (also allowing output = "raw", output = "base64") > That wouldn't be consistent with the rest of the hash_ family though :) > Just thinking that most of the time I'd prefer storing the hashed > passwords as base64-encoded strings just because it's more compact, > but this isn't a big deal, just a thought. > > Really nice work! > > Adam --- ## #60892 — Adam Jon Richardson — 2012-06-19T17:35:20+00:00 URL: https://externals.io/message/60884#60892 · In reply to: #60886 On Tue, Jun 19, 2012 at 6:23 AM, Tjerk Meesters wrote: > > > […] > > That wouldn't be consistent with the rest of the hash_ family though :) I agree that keeping the API consistent throughout the hashing family should be a priority. That said, this function signature is quite different from the other hash functions. Additionally, the practical value of this function relates specifically to password storage, and giving the developer easy, efficient access to more compact storage strings would likely prove helpful. Adam --- ## #60898 — Pierre Joye — 2012-06-20T06:38:03+00:00 URL: https://externals.io/message/60884#60898 · In reply to: #60884 hi Anthony! > Hello all, > > Since there wasn't that much traffic on the draft version of the RFC, > I've moved it into Proposed. > >  https://wiki.php.net/rfc/hash_pbkdf2 > > What are your thoughts? Very nice work! Thanks :) I would update the RFC with the current available algorithms or recommended to be used (depending on the usage or goal). About adding this to 5.4, I do not think it should be done. This is not a small change and it may require more testing, both for the implementations or the API (while it is fairly simple as of now :). php-next is next year anyway. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60900 — Enrico Zimuel — 2012-06-20T09:14:07+00:00 URL: https://externals.io/message/60884#60900 · In reply to: #60884 Hi Anthony, i think your RFC is very good! I like the idea to have PBKDF2 implementation that is able to act, at the same time, as secure hash value generator (without the length parameter) and as key derivation function (with the length parameter). I think we should be consistent with the API of Hash functions of PHP and use the raw_output = false to generate hex string and raw_output = true to generate binary output. If folks need to convert the output to Base64 they can easily use base64_encode($output) where $output is generated with raw_output = true. I don't think this is a big deal. I also agree to insert this function in PHP 5.4, actually in this implementation we reused other hash functions of PHP and the tests for PBKDF2 are fully specified in PKCS #5 test vectors that you used in your patch test. Very nice job! Regards, Enrico 2012/6/19 Anthony Ferrara : > Hello all, > > Since there wasn't that much traffic on the draft version of the RFC, > I've moved it into Proposed. > >  https://wiki.php.net/rfc/hash_pbkdf2 > > What are your thoughts? > > Thanks, > > Anthony --- ## #60902 — Anthony Ferrara — 2012-06-20T10:12:21+00:00 URL: https://externals.io/message/60884#60902 · In reply to: #60898 Pierre, > Very nice work! Thanks :) Thanks! > I would update the RFC with the current available algorithms or > recommended to be used (depending on the usage or goal). When you say "currently available algorithms", are you talking about the hash library as a whole? Or recommended for use with PBKDF2? Or other iterated stretching algorithms similar to PBKDF2? > About adding this to 5.4, I do not think it should be done. This is > not a small change and it may require more testing, both for the > implementations or the API (while it is fairly simple as of now :). > php-next is next year anyway. I'm not arguing that. When I proposed the draft earlier I had indicated that it was for trunk, and others said it could go into 5.4. That's why I put that section in the RFC. Personally, I'm in the middle. I can see some advantage to adding it to 5.4, but I can also see some disadvantages. So I leave that decision to others (such as yourself). Thanks, Anthony --- ## #60903 — Pierre Joye — 2012-06-20T12:27:12+00:00 URL: https://externals.io/message/60884#60903 · In reply to: #60902 hi Anthony! > > […] > > When you say "currently available algorithms", are you talking about > the hash library as a whole? Or recommended for use with PBKDF2? Or > other iterated stretching algorithms similar to PBKDF2? The algos recommended to use with PBKDF2. > > […] > > I can see some advantage to adding it to 5.4, but I can also > see some disadvantages. So I leave that decision to others (such as > yourself). There are always advantages to do it. But they do not help the big picture. However, besides what I said earlier, fast releases of features, 100% BC releases will ease the move to newer versions, faster than the horrible situation we have now. If we keep merging features, nobody will migrate, ever or until they have no other choices. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60904 — Anthony Ferrara — 2012-06-20T12:36:53+00:00 URL: https://externals.io/message/60884#60904 · In reply to: #60903 Pierre, > > hi Anthony! > > On Wed, Jun 20, 2012 at 12:12 PM, Anthony Ferrara wrote: > > > […] > > The algos recommended to use with PBKDF2. I will update the RFC tonight... > > > […] > > There are always advantages to do it. But they do not help the big > picture. However, besides what I said earlier, fast releases of > features, 100% BC releases will ease the move to newer versions, > faster than the horrible situation we have now. If we keep merging > features, nobody will migrate, ever or until they have no other > choices. > You have me convinced... Anthony --- ## #60906 — Jonathan Bond-Caron — 2012-06-20T15:00:04+00:00 URL: https://externals.io/message/60884#60906 · In reply to: #60884 > > https://wiki.php.net/rfc/hash_pbkdf2 > I like this proposal, it could be useful to add a simpler api that has defaults matching the NIST recommendation: hash_password($password, $salt, $algo = 'sha1', $iterations = 1000); if the salt doesn't have at least 16 characters (128 bits), throw error internally this calls: hash_pbkdf2('sha1', $password, $salt, 1000); My point being that: $hash = hash_password('1234', 'my'. $password[1] . 'super-long-salt-secret'); Gives good enough security 80% of use cases and is simpler then: $hash = hash_pbkdf2('sha1', '1234', 'my'. $password[1] . 'super-long-salt-secret', 1000); Developers will still use sha1 or md5 because they are so simple. --- ## #60919 — Anthony Ferrara — 2012-06-21T11:16:33+00:00 URL: https://externals.io/message/60884#60919 · In reply to: #60906 Jonathan, > I like this proposal, it could be useful to add a simpler api that has > defaults matching the NIST recommendation: > hash_password($password, $salt, $algo = 'sha1', $iterations = 1000); Checkout the other thread about adding a simple password API. As far as implementing that as well, I don't care for it. Basically, the reason is that it limits the algorithms that can be called by hash_password. Specifically scrypt would not be possible, because it has more parameters than that. > My point being that: > > $hash = hash_password('1234', 'my'. $password[1] . > 'super-long-salt-secret'); > > Gives good enough security 80% of use cases and is simpler then: > > $hash = hash_pbkdf2('sha1', '1234', 'my'. $password[1] . > 'super-long-salt-secret', 1000); > > Developers will still use sha1 or md5 because they are so simple. The goal of this API addition is not to simplify anything. It's to provide a C implementation of the PBKDF2 algorithm. The other topic about password hashing has the simplification goal. Anthony --- ## #60920 — Anthony Ferrara — 2012-06-21T11:41:59+00:00 URL: https://externals.io/message/60884#60920 · In reply to: #60903 Pierre, > > […] > > The algos recommended to use with PBKDF2. I just updated the RFC to include a description of the non-obvious parameters ($password isn't described). I also included a bit on algorithm selection in there. Take a peak and let me know if that satisfies what you were looking for, or if it needs to be expanded further. Thanks again, Anthony --- ## #61039 — Anthony Ferrara — 2012-06-29T14:19:05+00:00 URL: https://externals.io/message/60884#61039 · In reply to: #60920 Bumping this for a last call RFC. It will be 2 weeks on Monday since the proposal, and since there's not been a lot of traffic on the discussion, I'm planning on putting it up to a vote at that time (unless there are any major objections raised). So if anyone wants to comment prior to the vote, please do so! https://wiki.php.net/rfc/hash_pbkdf2 Anthony > Pierre, > > > […] > > I just updated the RFC to include a description of the non-obvious > parameters ($password isn't described). I also included a bit on > algorithm selection in there. > > Take a peak and let me know if that satisfies what you were looking > for, or if it needs to be expanded further. > > Thanks again, > > Anthony --- ## #61044 — Pierre Joye — 2012-06-29T16:35:45+00:00 URL: https://externals.io/message/60884#61044 · In reply to: #61039 hi, > Bumping this for a last call RFC. > > It will be 2 weeks on Monday since the proposal, and since there's not > been a lot of traffic on the discussion, I'm planning on putting it up > to a vote at that time (unless there are any major objections raised). > > So if anyone wants to comment prior to the vote, please do so! > > https://wiki.php.net/rfc/hash_pbkdf2 Quick reminder, it will be -1 from here if it targets 5.4, for all the reasons I have been repeatedly explaining. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #61046 — Anthony Ferrara — 2012-06-29T17:14:08+00:00 URL: https://externals.io/message/60884#61046 · In reply to: #61044 Pierre, > Quick reminder, it will be -1 from here if it targets 5.4, for all the > reasons I have been repeatedly explaining. I've updated the RFC to indicate such (that it's only targeting master (5.5)). Thanks, Anthony