Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73294
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXa+tEdhfr6LWG7f9yWvOBdBUjVs1jpOw1ihKCSrdWavnA@mail.gmail.com>
References: <9E3AA302-1EC1-4497-996F-716555CAAB64@rouvenwessling.de>
	<CAGa2bXbPA_LPT85XpNj8G=ivYw+ynZf_LuuFLt7t2MDU1hXx2w@mail.gmail.com>
	<4403BF54-041A-42F7-8B93-16EC3B2B0F43@rouvenwessling.de>
	<CADajX4CLyH+FqbucaLwkr8ZvB9c5UeVj5HPS0SM3xgnhLWUG4g@mail.gmail.com>
	<CAH-PCH6PqzaqazJ4LKQwBYaf-6odppW50JAK77ct_zwb36BKpQ@mail.gmail.com>
	<CAGa2bXa+tEdhfr6LWG7f9yWvOBdBUjVs1jpOw1ihKCSrdWavnA@mail.gmail.com>
Date: Wed, 19 Mar 2014 03:31:38 +0100
Message-ID: <CAH-PCH7j4zTrVTDRX9yRiiECeCVnZDC+Q7ir==GUAEifzCiJJQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Adam Harvey <aharvey@php.net>, =?UTF-8?Q?Rouven_We=C3=9Fling?= <me@rouvenwessling.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c13acacbba1b04f4ec7372
Subject: Re: [PHP-DEV] [VOTE] Timing attack safe string comparison function
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c13acacbba1b04f4ec7372
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 19, 2014 at 1:27 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> On Wed, Mar 19, 2014 at 3:56 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>> > > > From benchmark result, overhead for timing safe comparison is
>> negligible
>> > > > with byte by byte comparison.
>> > > > I would like to see timing safe "=3D=3D=3D" for 5.6, if it's possi=
ble.
>> (=3D=3D could
>> > > > be timing safe, too)
>> > > >
>> > > > Is anyone working on it?
>> > >
>> > > I don't know if someone else is, but I am not.
>> >
>> > I'm not in favour of this =E2=80=94 identity doesn't imply timing safe=
ty, and
>> > I think we should keep operators as performant as possible.
>> >
>>
>> Agree and afair it was explicitly stated as out of scope for this rfc.
>> (sorry for not merging this sooner, thanks Adam for thaking care of this=
).
>>
> Benchmark reveals performance issue is negligible.
>

and that benchmark was executed only one platform, with random data.
I'm not saying that it's not accurate, but it is a different kind of risk
when you introduce a new method for specific compare functionality than
replacing =3D=3D=3D with this new method for everybody.


>
> Regardless of where it is implemented, simple byte by byte compare is the
> best.
> We may ignore length leak at all. It's simpler (less risk) and faster.
>
> It's better to make =3D=3D=3D timing safe like Python, since it would
> be far less risks than dedicated API, but we may consider this later if
> the risk is
> getting greater.
>

I disagree, yeah we could cover up more ground if we replace the =3D=3D=3D
implementation with a timing safe one, but that would be more riskier from
the stability point of view, than adding it as a separate function first.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c13acacbba1b04f4ec7372--