Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70884
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.44 as permitted sender)
MIME-Version: 1.0
Date: Fri, 27 Dec 2013 12:15:53 -0800
Message-ID: <4472464359645184992@unknownmsgid>
To: Adam Harvey <aharvey@php.net>, Sara Golemon <pollita@php.net>
Cc: PHP Development <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] [RFC] Timing attack safe string comparison function
From: iwanluijks@gmail.com (Iwan Luijks)

Hi all,

Normally I wouldn't post to this mailing list, all ideas are in my
opinion very nicely taken care of. So that's the first note, thanks for
that :).

Besides that, I can't resist to make a note on the fact that this
function might very well be used as callback parameter in an array_walk
or array_map in which only implementing it via an extra parameter in a
strcmp from a practical point of view is a no go. Agree? :)

Next to that, the same functionality could later on be very well used
too compare 2 object hashes, raw hashes, or any non-string
combinations. If I'm correct in this, should there be considered a
function name that might respect this possible upcoming feature
beforehand?

Just a note.


Iwan Luijks

Verzonden met mijn Windows Phone Van: Adam Harvey
Verzonden: 27-12-2013 19:13
Aan: Sara Golemon
CC: PHP Development
Onderwerp: Re: [PHP-DEV] [RFC] Timing attack safe string comparison
function
On 27 December 2013 05:57, Sara Golemon <pollita@php.net> wrote:
> However, I do worry about using this syntax for a couple reasons of
> unintended consequences:
>
> * Fat Fingers: A third int/bool field to strcmp() could very easily
> get misinterpreted by accidentally using strncmp().  Now that
> true/0x01 looks like a length of 1 and your strcmp() only has to match
> the first character!

This does worry me a little too.

Another reason I'm not thrilled with the idea of adding a parameter is
that I think it's clearer what's going on if the function name itself
is descriptive (provided a good name can be found) =97 fundamentally,
they're actually different operations, even if they're in the class of
"string comparison functions", and if you're switching out the entire
implementation based on a mode parameter, that suggests to me they
should be different functions.

> Lastly, please stay away from names like "strcmp_secure()".  5-10
> years from now such a function will inevitably turn out to be insecure
> in some way and we'll need to add
> strcmp_really_secure_I_mean_it_this_time().  That way lies madness.

+1. I don't know what a good name is, but anything with the word
"secure" isn't it. str_compare_constant_time()?

Adam

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php