Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72782
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.194 as permitted sender)
MIME-Version: 1.0
Date: Mon, 24 Feb 2014 10:13:35 +0200
Message-ID: <CAPhkiZxpLkyu4AGuFFYHWx6TLYXP22uHxHm3mhkSTWBvV+5Z4Q@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Timing attack safe string comparison function
From: narf@devilix.net (Andrey Andreev)

Hey,

Rouven We=C3=83=C5=B8ling <me@rouvenwessling.de> wrote:

> I've updated the patch, taking the following feedback into account:
> -Renamed function to hash_equals

Why? There were some suggestions to rename it to something more
descriptive and generic, but nobody could think of such and IMO,
hash_compare() was better. :)

Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> > Rouven We=C3=83=C5=B8ling <me@rouvenwessling.de>wrote:
> > > I did some experiments. It seems it's good to implement timing safe
> > comparison in engine. i.e. We can make =3D=3D/=3D=3D=3D secure by defau=
lt like
> > Python. It would be much safer get rid of all timing from PHP.
> > >
> > > We need new RFC to include the change in engine.
> >
> >
> > That's not how I read that discussion (though I might have missed a mai=
l).
> > Also personally I don't like it. I don't see that the supposed gain in
> > security is worth the performance implication. Also if it turns out the=
re's
> > a bug, and we'd have to make it 100 times slower for some reason, than
> > that's not a big deal for a function like hash_equals. It is however if=
 it
> > affects all comparisons.
> >
> > Since I don't believe in that change, I'm not interested in proposing t=
hat
> > RFC.
>
> Understood. This is OK.
>
> From the experiment, performance implication is not much.
> Automatic protection in any place would worth the trade off. IMHO.
> Python even uses less efficient hash for comparison. I heard they
> use optimized version of SipHash, we may better try it before deciding
> algorithm, though.
>
> Any other comments regarding =3D=3D/=3D=3D=3D timing safety?


I also don't like it. The proposed function is just fine.

Cheers,
Andrey.