Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rouvenwessling.de designates 5.35.242.46 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
In-Reply-To: <52B80C5B.2050208@sugarcrm.com>
Date: Mon, 23 Dec 2013 11:26:42 +0100
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <6C0AE2F4-26DA-4081-914A-F6D18C46911C@rouvenwessling.de>
References: <3014595E-B155-47F6-AC7B-71083D89525D@rouvenwessling.de> <52B80C5B.2050208@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Timing attack safe string comparison function
From: me@rouvenwessling.de (=?iso-8859-1?Q?Rouven_We=DFling?=)

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
>=20
> 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=