Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72792
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPhkiZxpLkyu4AGuFFYHWx6TLYXP22uHxHm3mhkSTWBvV+5Z4Q@mail.gmail.com>
References: <CAPhkiZxpLkyu4AGuFFYHWx6TLYXP22uHxHm3mhkSTWBvV+5Z4Q@mail.gmail.com>
Date: Mon, 24 Feb 2014 19:25:58 +0800
Message-ID: <CAHMUw2FhOT1GqPPL8w0B5=U=+=vsb7iNYwirjebxiPcWNLo7Pg@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0111da1e5b23f004f3253c29
Subject: Re: [PHP-DEV] [VOTE] Timing attack safe string comparison function
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--089e0111da1e5b23f004f3253c29
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 24, 2014 at 4:13 PM, Andrey Andreev <narf@devilix.net> wrote:

> 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. :)
>

It's not obvious that `hash_compare()` would return a `bool(true)` if both
hashes match and `bool(false)` otherwise; something that the name
`hash_equals()` does convey. Maybe it's not the "most best" name, but it's
at least obvious what the return value would be like.


>
> 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 def=
ault 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
> mail).
> > > Also personally I don't like it. I don't see that the supposed gain i=
n
> > > security is worth the performance implication. Also if it turns out
> there's
> > > a bug, and we'd have to make it 100 times slower for some reason, tha=
n
> > > 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
> that
> > > 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.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
--
Tjerk

--089e0111da1e5b23f004f3253c29--