Hi
Let me link your Fediverse reply for reference as well:
https://infosec.exchange/@sc00bz/111178818937154254
On 10/5/23 02:07, st...@tobtu.com wrote:
I know I'm late but bcrypt cost 12 (which looks like the winner) is high. Cost 12
is ~1 kH/s/GPU and the accepted limit for good settings is <10 kH/s/GPU. Cost
12 is 10x stronger than it needs to be as a *minimum*. I believe cost 10 is a good
*default* for the next 1-3 years and cost 11 should be good for the next 5-10
years.
Yes, you were late (the vote was not yet closed at the time of your
Fediverse post / your email, though).
According to your Fediverse reply beginning with next year, 11 would be
an appropriate value for longevity. The default will only change
starting in PHP 8.4 which is roughly 13 months away from its gold
release. It will likely even longer before it actually broadly hits the
users.
The next Debian Stable is expected to be released in the middle of 2025,
with freeze starting around the end of 2024. Depending on the timing and
compatibility of PHP 8.4, it might or might not make the cut. In any
case, Debian will see PHP 8.4 no earlier than middle of 2025 and then
users will need to upgrade to that version.
Likewise the next Ubuntu LTS is expected in April 2024 and thus will not
include PHP 8.4, the first LTS version to include PHP 8.4 will arrive in
April 2026.
I also expect that those versions will live in production way past the
date the PHP project itself stops supporting them. Erring on the side of
"strong" seems to be the right choice to me, especially since a CPU that
is 12 years old as of today handles a cost of 12 in less than 330ms
(which still is acceptable for interactive authentication), with current
server CPUs (Xeon Gold 5416S mentioned by Alexandru) being at around the
100ms you mentioned.
Also the poll for increasing from cost 11 to cost 12 should be a 2/3 majority
to get cost 12. Since the poll for increasing from cost 10 to cost 11 is a 2/3
majority. You can think of this as a 2/3 majority poll to increase to cost 11
followed by a 2/3 majority poll to increase to cost 12.
I've included the majority rules within the first version of the RFC, so
it was clear to everyone who voted how the results are going to be
interpreted. Redefining the majority rules shortly before the end of the
vote would be questionable, that's why I proceeded to announce the
results with the rules that were announced at the start of the vote.
I also don't think that 12 is a wrong choice for the reasons outlined above.
Best regards
Tim Dsüterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
