Hi Stas.
On 23.12.2013, at 11:11, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
I wonder how practical this would be. There are probably many side
channels in PHP related to how PHP manages memory, copies variables,
processes opcodes, etc. so I wonder if providing such function for PHP
API would practically add anything or if you should be doing crypto that
sensitive in PHP anyway?
Indeed, a managed language like PHP will never be able to guarantee safety in this regard. However while you may be able to gain information about the length of the known string, I doubt it will be possible to exploit the string comparison itself (getting byte for byte closer to the hash).
As for your last point, you don't need to do terribly sensitive crypo for this to make sense. Any password hash comparison will do.
That there's a need for this sort of thing is probably demonstrated by the fact, that this is already used by major framework like Joomla! and Symfony2, but implemented in pure PHP which suffers even more from the issues you describe. Also PHP core does something like this already, but only in the narrow use case of password_verify.
On 23.12.2013, at 11:20, Joe Watkins <krakjoe@php.net> wrote:
One of the chaps on SO done a bit of testing, it appears that without usleep in php land you cannot avoid cpu spikes, and so cannot get a reliable vector of attack unless the server side code has been prepared to be attacked. But this is only testing.
Do you have a link to that discussion? It'd probably be interesting to read in the context of this discussion.
Best regards
Rouven