# [RFC][DISCUSSION] Argon2 Password Hash - Thread: https://externals.io/message/94854 - Original archive: https://news-web.php.net/php.internals/94854 - Started by Charles R. Portwood II on 2016-08-05T12:47:56+00:00 - Messages: 24 - 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 --- ## #94854 — Charles R. Portwood II — 2016-08-05T12:47:56+00:00 URL: https://externals.io/message/94854#94854 Hello Internals, Due to a couple issue with the original RFC's scope, the RFC for introducing Argon2 as an alternative hashing algorithm for the password_* functions was closed shortly after starting on Monday. The following details were adjusted. and I would appreciate your feedback before re-opening the vote. - The RFC scope was reduced to only cover inclusion in 7.2. This RFC no longer proposes changes to `PASSWORD_DEFAULT` in 7.4. - Argon2d is not suitable for password hashing, and has been removed to keep in line with the scope goals of the password_* functions. - The configure flag was changed to --with-argon2 to --with-password-argon2 to further clarify the scope of this RFC. Further rationale for these items is provided in the RFC itself. The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash. Thanks to those who emailed me directly to discuss the matter on Monday, and for your feedback on these changes. *Charles R. Portwood II* --- ## #94855 — Tom Worster — 2016-08-05T14:19:52+00:00 URL: https://externals.io/message/94854#94855 · In reply to: #94854 > The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash. Hi Charles, Thanks for doing this. I'm glad Argon2 is coming to PHP. You can have a longer voting period if you like, which I think would be a good idea. I think it's confusing to have two consts to identify the algorithm. I don't understand the analogy to PASSWORD_DEFAULT. If we only provide Argon2i, one const is easier. If we anticipate adding another Argon2 algo in the future that is not backward compatible with this one then I don't think we would want to change PASSWORD_ARGON2 to point to it. Finally, I wonder if it wouldn't be better if, for the time being, we do not provide default costs constants. Argon2 is new (as crypto algos go) and very early in a gradual introduction in deployments. And it is hard to use because of the three cost factors. Correctly tuning those for different machines is not yet a commonly-understood skill. (You even can find conflicting advice on how to tune Bcrypt's time factor.) If we offer default costs then it will appear, to some people, even those who know little about it beyond the name, as though deploying Argon2 is just a matter of using it with the defaults. I'm not sure this is a good idea. If, on the other hand, we omit the constants and require the $options argument then it discourages inexpert users. At the same time it encourages experimentation and understanding of the costs, among those who take an interest, which I think is just what we want. Those who want to use Argon2 are going to make special efforts to get the lib and enable it in PHP. So I don't think it's unreasonable to expect the early adopters to give some thought to the costs. Tom --- ## #94857 — Charles R. Portwood II — 2016-08-05T14:49:43+00:00 URL: https://externals.io/message/94854#94857 · In reply to: #94855 > > > The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash > > […] > > Hi Charles, > > Thanks for doing this. I'm glad Argon2 is coming to PHP. > Hi Tom, Thanks for the feedback! You can have a longer voting period if you like, which I think would be > a good idea. Sounds good to me. I think it's confusing to have two consts to identify the algorithm. I > don't understand the analogy to PASSWORD_DEFAULT. If we only provide > Argon2i, one const is easier. If we anticipate adding another Argon2 > algo in the future that is not backward compatible with this one then I > don't think we would want to change PASSWORD_ARGON2 to point to it. I agree. Originally there was PASSWORD_ARGON2I and PASSWORD_ARGON2D, with PASSWORD_ARGON2 aliasing to PASSWORD_ARGON2I, but with Argon2d removed from scope the extra constant is now largely unnecessary. I don't anticipate Argon2 adding any additional algorithms at this point, given the spec and reference library is finalized. I think for clarity, PASSWORD_ARGON2I would be sufficient. What are your thoughts? Finally, I wonder if it wouldn't be better if, for the time being, we > do not provide default costs constants. Argon2 is new (as crypto algos > go) and very early in a gradual introduction in deployments. And it is > hard to use because of the three cost factors. Correctly tuning those > for different machines is not yet a commonly-understood skill. (You > even can find conflicting advice on how to tune Bcrypt's time factor.) > If, on the other hand, we omit the constants and require the $options > argument then it discourages inexpert users. At the same time it > encourages experimentation and understanding of the costs, among those > who take an interest, which I think is just what we want. The rationale for providing defaults is to ensure the password_* functions remain easy to use. Assuming that at some point PASSWORD_ARGON2I (or any new algorithm) would become PASSWORD_DEFAULT, the end user's expectations would be that *password_hash($password, PASSWORD_DEFAULT)* just works, without needing to specify additional arguments. As the spec requires some minimum values to even work (and there's recommendations from the developers [1]), I think we should be providing defaults so that the algorithm works out of the box, though I agree they could be set to lower values. Note that the spec does specifically say that there is no "insecure" value for the memory and time cost attributes. If we wanted to drop it to the minimum recommend by the developers, the values would be: m_cost = 16 t_cost = 2 threads = 1 I'm open to other suggestions or alternatives though. Thanks, *Charles R. Portwood II* [1]: https://github.com/P-H-C/phc-winner-argon2/issues/144 --- ## #94858 — Charles R. Portwood II — 2016-08-05T14:59:59+00:00 URL: https://externals.io/message/94854#94858 · In reply to: #94857 On Fri, Aug 5, 2016 at 9:49 AM, Charles R. Portwood II < charlesportwoodii@erianna.com> wrote: > > > > […] > > > As the spec requires some minimum values to even work (and there's > recommendations from the developers [1]), I think we should be providing > defaults so that the algorithm works out of the box, though I agree they > could be set to lower values. Note that the spec does specifically say that > there is no "insecure" value for the memory and time cost attributes. If we > wanted to drop it to the minimum recommend by the developers, the values > would be: > > m_cost = 16 > t_cost = 2 > threads = 1 > > I'm open to other suggestions or alternatives though. > > Thanks, > *Charles R. Portwood II* > > [1]: https://github.com/P-H-C/phc-winner-argon2/issues/144 > > For clarity, a memory cost of 16 implies 65536 KiB, or 64 MiB of memory. The only difference between the values recommended by the developers, and the cost outlined in the RFC is that the t_cost is set to 3. *Charles R. Portwood II* --- ## #94859 — Ryan Pallas — 2016-08-05T15:08:14+00:00 URL: https://externals.io/message/94854#94859 · In reply to: #94857 On Fri, Aug 5, 2016 at 8:49 AM, Charles R. Portwood II < charlesportwoodii@erianna.com> wrote: > > > > […] > > Finally, I wonder if it wouldn't be better if, for the time being, we > > […] > > > If, on the other hand, we omit the constants and require the $options > > […] > > > The rationale for providing defaults is to ensure the password_* functions > remain easy to use. Assuming that at some point PASSWORD_ARGON2I (or any > new algorithm) would become PASSWORD_DEFAULT, the end user's expectations > would be that *password_hash($password, PASSWORD_DEFAULT)* just works, > without needing to specify additional arguments. > I think this is the most important part to consider. If you make $options required for this algo, then making this algo the `PASSWORD_DEFAULT` would mean that its a backwards incompatible change, because now all calls to password_hash($password, PASSWORD_DEFAULT) would need to be updated to use an older constant or pass in $options which I think totally defeats the purpose of the password_hash API. Please keep it so that defaults will work, but $options is available for tuning as that's how the feature currently works. --- ## #94860 — Tom Worster — 2016-08-05T15:14:35+00:00 URL: https://externals.io/message/94854#94860 · In reply to: #94857 On 8/5/16, 10:49 AM, "Charles R. Portwood II" wrote: >I think for clarity, PASSWORD_ARGON2I would be sufficient. What are your >thoughts? Looks good. >The rationale for providing defaults is to ensure the password_* >functions remain easy to use. I understand. I was actually suggesting that we deliberately make it harder to use! > Assuming that at some point PASSWORD_ARGON2I (or any new algorithm) >would become PASSWORD_DEFAULT, the end user's expectations would be that >password_hash($password, PASSWORD_DEFAULT) just works, without needing to >specify additional arguments. I agree entirely. I'm not against introducing default cost constants. I am instead proposing we allow a period of time after introduction of Argon2 into PHP before deciding what the default costs should be and define the constants at the same time as setting `PASSWORD_DEFAULT` = PASSWORD_ARGON2I, or possibly before. Please reread my previous message for the reasons behind this (odd, I admit) idea. Tom --- ## #94862 — Tom Worster — 2016-08-05T15:21:44+00:00 URL: https://externals.io/message/94854#94862 · In reply to: #94859 >Please keep it so that defaults will work, but $options is available for >tuning as that's how the feature currently works. My suggestion doesn't affect that. I agree that password_hash($password, PASSWORD_DEFAULT) should always "just work". Instead, I think there should be an interim status, before changing PASSWORD_DEFAULT, in which password_hash($password, PASSWORD_ARGON2I) requires $options. Reasons given in my first reply. There is no hurry to change PASSWORD_DEFAULT, afaik. Tom --- ## #94863 — Niklas Keller — 2016-08-05T16:29:20+00:00 URL: https://externals.io/message/94854#94863 · In reply to: #94854 2016-08-05 14:47 GMT+02:00 Charles R. Portwood II < charlesportwoodii@erianna.com>: > Hello Internals, > > Due to a couple issue with the original RFC's scope, the RFC for > introducing Argon2 as an alternative hashing algorithm for the password_* > functions was closed shortly after starting on Monday. > > The following details were adjusted. and I would appreciate your feedback > before re-opening the vote. > > - The RFC scope was reduced to only cover inclusion in 7.2. This RFC no > longer proposes changes to `PASSWORD_DEFAULT` in 7.4. > - Argon2d is not suitable for password hashing, and has been removed to > keep in line with the scope goals of the password_* functions. > - The configure flag was changed to --with-argon2 to > --with-password-argon2 to further clarify the scope of this RFC. > > Further rationale for these items is provided in the RFC itself. > > The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash. > > Thanks to those who emailed me directly to discuss the matter on Monday, > and for your feedback on these changes. > > *Charles R. Portwood II* > Hi Charles, I'd prefer `memory_cost` and `time_cost` over `m_cost` and `t_cost`. Do we have any reason to use the shorter but less readable names here? Regards, Niklas --- ## #94864 — Charles R. Portwood II — 2016-08-05T16:36:51+00:00 URL: https://externals.io/message/94854#94864 · In reply to: #94859 > > > I think this is the most important part to consider. If you make $options > required for this algo, then making this algo the `PASSWORD_DEFAULT` would > mean that its a backwards incompatible change, because now all calls to > password_hash($password, PASSWORD_DEFAULT) would need to be updated to use > an older constant or pass in $options which I think totally defeats the > purpose of the password_hash API. > > Please keep it so that defaults will work, but $options is available for > tuning as that's how the feature currently works. > > The rationale for providing defaults is to ensure the password_* > > […] > > I understand. I was actually suggesting that we deliberately make it > harder to use! Assuming that at some point PASSWORD_ARGON2I (or any new algorithm) > > […] > > I agree entirely. I'm not against introducing default cost constants. I am > instead proposing we allow a period of time after introduction of Argon2 > into PHP before deciding what the default costs should be and define the > constants at the same time as setting `PASSWORD_DEFAULT` = PASSWORD_ARGON2I, > or possibly before. > Please reread my previous message for the reasons behind this (odd, I > admit) idea. Hi Tom, I understand what you're saying. Ryan said it a bit more clearly than I did, making the options required causes backwards-incompatible changes to the password_hash API. That's my real reservation behind not providing defaults. A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I = PASSWORD_DEFAULT). If the supplied constants need to be changed for that, I think that would be the time to do so. I think for now something needs to be provided to ensure the password_hash API doesn't change. > > Hi Charles, > > I'd prefer `memory_cost` and `time_cost` over `m_cost` and `t_cost`. Do we > have any reason to use the shorter but less readable names here? > > Regards, Niklas > 'm_cost' and 't_cost' is what is used in the reference library. Someone looking at the reference material would see those names. Thanks, *Charles R. Portwood II* --- ## #94865 — Tom Worster — 2016-08-05T17:12:15+00:00 URL: https://externals.io/message/94854#94865 · In reply to: #94864 On 8/5/16, 12:36 PM, "Charles R. Portwood II" wrote: >I understand what you're saying. Ryan said it a bit more clearly than I >did, making the options required causes backwards-incompatible changes to >the password_hash API. That's my real reservation behind not providing >defaults. > >A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I = >PASSWORD_DEFAULT). If the supplied constants need to be changed for that, >I think that would be the time to do so. I think for now something needs >to be provided to ensure the password_hash API doesn't change. I can understand an argument that it's too much to expect a user to provide an options array when using Argon2. But I don't understand how my suggestion breaks BC. In my idea, a future RFC would propose default cost constants. Changing `PASSWORD_DEFAULT` to PASSWORD_ARGON2I depends on those constants so they would need to be defined before changing `PASSWORD_DEFAULT` or at the same time. So... password_hash('password', PASSWORD_DEFAULT) will always work. password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is introduced in your proposal, but has to wait for another future RFC in my suggested change. password_hash('password', PASSWORD_ARGON2I, [costs]) will always work. How does a BC break happen? Tom --- ## #94866 — Niklas Keller — 2016-08-05T17:51:11+00:00 URL: https://externals.io/message/94854#94866 · In reply to: #94864 2016-08-05 18:36 GMT+02:00 Charles R. Portwood II < charlesportwoodii@erianna.com>: > > > […] > use > > […] > > > > > […] > > I understand. I was actually suggesting that we deliberately make it > > […] > > > Assuming that at some point PASSWORD_ARGON2I (or any new algorithm) > > […] > to > > […] > > I agree entirely. I'm not against introducing default cost constants. I am > > […] > PASSWORD_ARGON2I, > > […] > > > > […] > > > Hi Tom, > > I understand what you're saying. Ryan said it a bit more clearly than I > did, making the options required causes backwards-incompatible changes to > the password_hash API. That's my real reservation behind not providing > defaults. > > A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I = > PASSWORD_DEFAULT). If the supplied constants need to be changed for that, I > think that would be the time to do so. I think for now something needs to > be provided to ensure the password_hash API doesn't change. > > > > […] > we > > […] > > 'm_cost' and 't_cost' is what is used in the reference library. Someone > looking at the reference material would see those names. People knowing the reference library will probably recognize `memory_cost` and `time_cost`, but this is a simple API targeted on a large audience. Most users of it won't know the reference library's internals. Regards, Niklas --- ## #94867 — Charles R. Portwood II — 2016-08-05T18:20:57+00:00 URL: https://externals.io/message/94854#94867 · In reply to: #94865 > > I can understand an argument that it's too much to expect a user to > provide an options array when using Argon2. But I don't understand how my > suggestion breaks BC. In my idea, a future RFC would propose default cost > constants. Changing `PASSWORD_DEFAULT` to PASSWORD_ARGON2I depends on those > constants so they would need to be defined before changing > `PASSWORD_DEFAULT` or at the same time. So... > > password_hash('password', PASSWORD_DEFAULT) will always work. > > password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is > introduced in your proposal, but has to wait for another future RFC in my > suggested change. > > password_hash('password', PASSWORD_ARGON2I, [costs]) will always work. > > How does a BC break happen? > > Tom > Hi Tom, It breaks the API in the interim between this RFC and a potential future one. The $options parameter for both password_hash and password_needs_rehash is optional. Making it required for one algorithm but not another changes the API's for both methods. The expectations outlined in the original password_hash RFC make the third parameter for tuning the algorithm, not for making the algorithm work. Without default values, both password_hash and password_needs_rehash would fail unless the costs are provided. Hi Niklas, People knowing the reference library will probably recognize `memory_cost` > and `time_cost`, but this is a simple API targeted on a large audience. > Most users of it won't know the reference library's internals. If that's going to be easier for people I'm all for it. --- ## #94869 — lauri.kentta@gmail.com — 2016-08-05T20:51:50+00:00 URL: https://externals.io/message/94854#94869 · In reply to: #94867 > > > […] > > Hi Tom, > > It breaks the API in the interim between this RFC and a potential > future > one. The $options parameter for both password_hash and > password_needs_rehash is optional. Making it required for one algorithm > but > not another changes the API's for both methods. The expectations > outlined > in the original password_hash RFC make the third parameter for tuning > the > algorithm, not for making the algorithm work. Without default values, > both > password_hash and password_needs_rehash would fail unless the costs are > provided. > I think it's very important to provide some kind of default parameters. We have password_needs_rehash for the exact reason that we can later change the defaults if they are not good enough (anymore). If the defaults are not set, people will have to invent their own parameters, which may be good or very bad. These parameters will not be automatically updated with future versions of PHP. There is nothing to lose from setting some sane defaults. There is nothing to gain from NOT setting the defaults. About the memory requirements: setting the memory cost too high may limit using this algorithm in many inexpensive shared web hosting services, which may have default PHP memory limit as low as 128 MB or 256 MB. -- Lauri Kenttä --- ## #94881 — Niklas Keller — 2016-08-06T11:09:05+00:00 URL: https://externals.io/message/94854#94881 · In reply to: #94869 2016-08-05 22:51 GMT+02:00 Lauri Kenttä : > > > > […] > I think it's very important to provide some kind of default parameters. > We have password_needs_rehash for the exact reason that we can later > change the defaults if they are not good enough (anymore). > > If the defaults are not set, people will have to invent their own > parameters, which may be good or very bad. These parameters will not be > automatically updated with future versions of PHP. > We should definitely provide defaults. > There is nothing to lose from setting some sane defaults. > There is nothing to gain from NOT setting the defaults. > > About the memory requirements: setting the memory cost too high may limit > using this algorithm in many inexpensive shared web hosting services, > which may have default PHP memory limit as low as 128 MB or 256 MB. Setting the memory limit too high could also result in overall memory exhaustion with many concurrent login attempts. --- ## #94884 — Charles R. Portwood II — 2016-08-06T14:47:27+00:00 URL: https://externals.io/message/94854#94884 · In reply to: #94881 > 2016-08-05 22:51 GMT+02:00 Lauri Kenttä : > > > […] > > We should definitely provide defaults. > > > > […] > > > Setting the memory limit too high could also result in overall memory > exhaustion with many concurrent login attempts. > Hi, Absolutely. What are your thoughts on the following cost factors? time_cost = 3 memory_cost = 12 threads = 1 The reference library provides a CLI program where these values are listed [1]. A memory_cost factor of 12 would be 4 MiB. Thanks, *Charles R. Portwood II* [1]: https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L27 --- ## #94885 — lauri.kentta@gmail.com — 2016-08-06T16:37:20+00:00 URL: https://externals.io/message/94854#94885 · In reply to: #94884 > Absolutely. What are your thoughts on the following cost factors? > > time_cost = 3 > memory_cost = 12 > threads = 1 > > The reference library provides a CLI program where these values are > listed. A memory_cost factor of 12 would be 4 MiB. Looks like there's already some ambiguity in the parameters. As I understand it, m_cost is the memory size in kilobytes. Thus, m_cost = 4096 would be 4 MiB. The source file you referenced [1] has actually LOG_M_COST_DEF, where m_cost = 1 << LOG_M_COST_DEF. Testing with argon2_cffi [2] (Python) shows that your parameters (with m_cost = 4096 = 4 MiB) take 57 ms per hash on my laptop and 14 ms on my VPS, compared to bcrypt cost 10 taking 88 ms. Personally, I would be satisfied with even smaller parameters, maybe something like memory_cost 512, time_cost 2, threads 2. Disclaimer: I'm not familiar with Argon2, I only looked shortly at the source files and the Python library [2]. However, care should be taken to use the correct definition for m_cost. [1] https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L27 [2] http://argon2-cffi.readthedocs.io/en/stable/parameters.html -- Lauri Kenttä --- ## #94886 — Tom Worster — 2016-08-06T17:08:49+00:00 URL: https://externals.io/message/94854#94886 · In reply to: #94867 On 8/5/16, 2:20 PM, "Charles R. Portwood II" wrote: >It breaks the API in the interim between this RFC and a potential future >one. The $options parameter for both password_hash and >password_needs_rehash is optional. Making it required for one algorithm >but not another changes the API's for both methods. The expectations >outlined in the original password_hash RFC make the third parameter for >tuning the algorithm, not for making the algorithm work. Without default >values, both password_hash and password_needs_rehash would fail unless >the costs are provided. OK. I misunderstood what qualifies as "broken". Looks most like most people want to set default costs right away so I'll leave it here. As for choosing the right default values for PHP, what are the criteria? Tom --- ## #94887 — Charles R. Portwood II — 2016-08-06T17:55:50+00:00 URL: https://externals.io/message/94854#94887 · In reply to: #94885 On Sat, Aug 6, 2016 at 11:37 AM, Lauri Kenttä wrote: > > > > […] > > Looks like there's already some ambiguity in the parameters. > As I understand it, m_cost is the memory size in kilobytes. > Thus, m_cost = 4096 would be 4 MiB. > The source file you referenced [1] has actually LOG_M_COST_DEF, > where m_cost = 1 << LOG_M_COST_DEF. > > Testing with argon2_cffi [2] (Python) shows that your parameters > (with m_cost = 4096 = 4 MiB) take 57 ms per hash on my laptop > and 14 ms on my VPS, compared to bcrypt cost 10 taking 88 ms. > > Personally, I would be satisfied with even smaller parameters, > maybe something like memory_cost 512, time_cost 2, threads 2. > > Disclaimer: I'm not familiar with Argon2, I only looked shortly > at the source files and the Python library [2]. However, care > should be taken to use the correct definition for m_cost. > > [1] https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L27 > > > [2] http://argon2-cffi.readthedocs.io/en/stable/parameters.html > > > > -- > Lauri Kenttä > Hi Laura, The confusion is on my part, I apologize. Both this implementation, and the Argon2 reference library use a bitwise shift on the memory cost factor. When I say "12", I'm really meaning "1<<12", which is 4096, or 4 Mib. [1][2]. The RFC itself actually states the bitwise shift in the examples, and for the cost factors represents it in Mib. We can drop the memory cost down lower if people would prefer that. My only concern with setting the default thread count to 2 is that it may cause problems for individuals on single core machines. The PHP implementation performs as follows from the CLI with the following cost factors on one of my VPS'. The time cost for each of the Argon2 implementations in this case is 3, with a thread count of 1. [3] 2 ms : argon2i, 256 KiB > 2 ms : argon2i, 512 KiB > 3 ms : argon2i, 1024 KiB > 17 ms : argon2i, 4096 KiB > 53 ms : argon2i, 16384 KiB 203 ms : argon2i, 65536 KiB Setting the memory cost to 4 MiB, or even 1 MiB are pretty fast in the PHP implementation. I think the following costs would be acceptable to avoid concerns over memory exhaustion. These appear to be the defaults outlined in the reference library's CLItool. memory_cost = 4 MiB, 1<<12 > time_cost = 3 > threads = 1 I think there's a bunch of ways we can tweak this. As there's no "bad" values for any of these cost factors per the spec, it may just be easy to set the costs even lower end user decide if they need to be increased (or increase them in core at a later time). memory_cost = 1 MiB 1<<10 > time_cost = 2 > threads = 1 > OK. I misunderstood what qualifies as "broken". Looks most like most > people want to set default costs right away so I'll leave it here. As for > choosing the right default values for PHP, what are the criteria? Typically a run time of of under 50 ms is the target goal. Argon2 can be tweaked to use a specific amount of memory, time, or CPU cores. Trying to find good default cost factors is problematic since all 3 of those factors are variable on any given machine. *Charles R. Portwood II* [1] https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L160 [2] https://github.com/php/php-src/pull/1997/files#diff-c902 6333c79da7abe3b1285ef7c0c312R36 [3] https://gist.github.com/charlesportwoodii/3e113a53d243b5a722babfd421a93d c3 [4] https://gist.github.com/charlesportwoodii/ceaa87c9a9adb069b9f2eaddf56ab8 71 --- ## #94900 — Tom Worster — 2016-08-07T15:06:45+00:00 URL: https://externals.io/message/94854#94900 · In reply to: #94887 On 8/6/16, 1:55 PM, "Charles R. Portwood II" wrote: >Typically a run time of of under 50 ms is the target goal. Argon2 can be >tweaked to use a specific amount of memory, time, or CPU cores. Trying to >find good default cost factors is problematic since all 3 of those >factors are variable on any given machine. (Yes ... the very reason I wanted ... never mind.) Can anyone think of a way to organize or even automate collection of timing information together with the relevant specs of the machine the test was run on? I'm not sure if the qa-reports@lists.php.net process still operates. Maybe some other idea? Tom --- ## #94902 — Jared Williams — 2016-08-07T16:14:42+00:00 URL: https://externals.io/message/94854#94902 · In reply to: #94854 > Hello Internals, > > Due to a couple issue with the original RFC's scope, the RFC for > introducing Argon2 as an alternative hashing algorithm for the > password_* > functions was closed shortly after starting on Monday. > > The following details were adjusted. and I would appreciate your > feedback > before re-opening the vote. > >    - The RFC scope was reduced to only cover inclusion in 7.2. This > RFC no >    longer proposes changes to `PASSWORD_DEFAULT` in 7.4. >    - Argon2d is not suitable for password hashing, and has been > removed to >    keep in line with the scope goals of the password_* functions. >    - The configure flag was changed to --with-argon2 to >    --with-password-argon2 to further clarify the scope of this RFC. > > Further rationale for these items is provided in the RFC itself. > > The RFC is available at: https://wiki.php.net/rfc/argon2_password_has > h. > > Thanks to those who emailed me directly to discuss the matter on > Monday, > and for your feedback on these changes. > > *Charles R. Portwood II* Argon2 also supports keyed hashes and associated data, but seen no mention of either. Jared --- ## #94944 — Charles R. Portwood II — 2016-08-08T17:18:00+00:00 URL: https://externals.io/message/94854#94944 · In reply to: #94854 > > Argon2 also supports keyed hashes and associated data, but seen no > mention of either. > Jared Hi Jared, This is a design decision to prevent changing the PHP API. The Argon2 reference library exposes two ways of working with Argon2 hashes, we can either use the Argon2_Context struct, or pass our data directly to the argon2_hash/verify functions. The former is the only way to provided a hash key and associated data. Since password_hash doesn't expose the salt is generates, and since password_verify doesn't accept an array options, it would be impossible to verify Argon2 hashes created with a hash key and associated data without changing the PHP API for that function. *Charles R. Portwood II* --- ## #95271 — Charles R. Portwood II — 2016-08-17T19:48:21+00:00 URL: https://externals.io/message/94854#95271 · In reply to: #94887 On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II < charlesportwoodii@erianna.com> wrote: > > > I think there's a bunch of ways we can tweak this. As there's no "bad" > values for any of these cost factors per the spec, it may just be easy to > set the costs even lower end user decide if they need to be increased (or > increase them in core at a later time). > Hi everyone, I've spent the last week and a half playing around with various cost factors on different virtual machines and hardware (including compiling this down for armv6 and testing on a Pi Zero), and looking over the spec a bit more and would like to update the proposal to use the following cost factors: memory_cost = 1 MiB > time_cost = 2 > threads = 2 There are no "bad" cost factors for Argon2, but obviously more work is better than less. These cost factors provide sufficient work effort without exhausting system resources. Argon2 is pretty fast with these cost factors even on a Pi Zero, which is the most resource constrained system I could get my hands on. In all my testing I wasn't ever able to get memory exhaustion to occur just from running argon2 hashing. I'd like to gather some last feedback and make sure there aren't any serious objections to these cost factors (or anything else for that matter) before putting this up for a vote. Please let me know your thoughts. Thanks, *Charles R. Portwood II* --- ## #95276 — Tom Worster — 2016-08-17T21:45:05+00:00 URL: https://externals.io/message/94854#95276 · In reply to: #95271 On 8/17/16, 3:48 PM, "Charles R. Portwood II" wrote: >Hi everyone, > >I've spent the last week and a half playing around with various cost >factors on different virtual machines and hardware (including compiling >this down for armv6 and testing on a Pi Zero), and looking over the spec >a bit more and would like to update the proposal to use the following >cost factors: > > >memory_cost = 1 MiB >time_cost = 2 >threads = 2 > > >There are no "bad" cost factors for Argon2, but obviously more work is >better than less. These cost factors provide sufficient work effort >without exhausting system resources. Argon2 is pretty fast with these >cost factors even on a Pi Zero, which is the most resource constrained >system I could get my hands on. In all my testing I wasn't ever able to >get memory exhaustion to occur just from running argon2 hashing. > >I'd like to gather some last feedback and make sure there aren't any >serious objections to these cost factors (or anything else for that >matter) before putting this up for a vote. Please let me know your >thoughts. Hi Charles, I trust your judgement in drawing conclusions from these experiments. Thank you for the work you've put in. Tom --- ## #95346 — lauri.kentta@gmail.com — 2016-08-21T15:45:28+00:00 URL: https://externals.io/message/94854#95346 · In reply to: #95271 > On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II > wrote: > > > […] > > I'd like to gather some last feedback and make sure there aren't any > serious objections to these cost factors (or anything else for that > matter) before putting this up for a vote. Please let me know your > thoughts. The whole RFC looks good to me now. Thanks for your work on this! -- Lauri Kenttä