On Mon, Feb 24, 2014 at 4:13 PM, Andrey Andreev <[email protected]> wrote:
> Hey,
>
> Rouven Weßling <[email protected]> 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 <[email protected]> wrote:
>
> > > Rouven Weßling <[email protected]>wrote:
> > > > I did some experiments. It seems it's good to implement timing safe
> > > comparison in engine. i.e. We can make ==/=== secure by default 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 in
> > > 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, 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
> 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 ==/=== 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
>
>
--
--
Tjerk