Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70860
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Marco Pivetta <ocramius@gmail.com>
Message-ID: <52B81B9F.6040609@php.net>
Date: Mon, 23 Dec 2013 11:16:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <3014595E-B155-47F6-AC7B-71083D89525D@rouvenwessling.de> <52B80C5B.2050208@sugarcrm.com> <6C0AE2F4-26DA-4081-914A-F6D18C46911C@rouvenwessling.de> <52B81559.8080409@php.net> <CADyq6sJESC+UG_Vb7Wq=nHQWF0-5zL=7Yzpi2L8rr4CQwyr5ug@mail.gmail.com>
In-Reply-To: <CADyq6sJESC+UG_Vb7Wq=nHQWF0-5zL=7Yzpi2L8rr4CQwyr5ug@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Timing attack safe string comparison function
From: krakjoe@php.net (Joe Watkins)

On 12/23/2013 11:04 AM, Marco Pivetta wrote:
> Heya,
>
> I was discussing about this RFC with Joe in Room 11 (where we keep him away
> from society, for the greater good).
>
> I was wondering why such an API must be implemented in PHP core (which
> means C, which means that the usual 15~20 people can fix it if borked,
> which is bad) and cannot be just left in userland as it already happens,
> for example, with
> https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Utils.php#L17-L44and
> similar libraries that have some decent security policies themselves
> (nothing to say about PHP - you guys are doing great!).
>
> Why do we need this in core?
> Why can't a user copy-paste those rows (if it's a monkey-patcher) or just
> use a library?
>
> I don't trust PHP coders in general, so I'm pretty sure that the example
> I've posted before @ https://gist.github.com/Ocramius/8094168 is quite
> obscure to the 99.9% of PHP developers.
>
> Who has been doing it wrong will continue going on and not caring.
>
> Those who are aware of the dangers and do care are most probably already
> using these kinds of checks vie an imported library.
>
> So what is pushing towards yet another function in here?
>
> Don't get me wrong: I am all for security, but I don't see a difference
> between a php-core implementation and a userland implementation.
>
> Cheers,
>
>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Ok, good wanderings dear Macro ...

We already have it in core, here it is:

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. */
295    for (i = 0; i < hash_len; i++) {
296        status |= (ret[i] ^ hash[i]);
297    }

So that puts in perspective the what if it borks argument, and the 
complication argument too, since the new function and old can share a 
static inline implementation of the same logic ... do you really want me 
to explain why static inline c is better than PHP, or is that obvious at 
this point ??

I would love it if at some point in the future you could point at bits 
of PHP and say "that's a good implementation", right now the most you 
can say is "here's some functions implemented to help in this area, and 
here's all the code and knowledge of PHP you require to make good, sane 
use of it".

Anyone who doesn't see that, is barking mad, barking, mad ...

Cheers
Joe