Re: [RFC] Timing attack safe string comparison function

On 12/23/2013 10:26 AM, Rouven Weßling wrote:

Hi Stas. On 23.12.2013, at 11:11, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

I'd like to propose this RFC to introduce a time-constant string comparison function: https://wiki.php.net/rfc/timing_attack

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

Right so,

291    /* We're using this method instead of == in order to provide
292     * resistence towards timing attacks. This is a constant time
293     * equality check that will always check every byte of both
294     * values. */

We already do this, it is a completion of the API, there should be no argument at all, I'd come at it from this angle, name it as a completion of this API (password_match) and document it as such. Cheers Joe