[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    Re: [PHP-DEV] [VOTE] Timing attack safe string comparison function
From:       Tjerk Meesters <tjerk.meesters () gmail ! com>
Date:       2014-02-24 11:25:58
Message-ID: CAHMUw2FhOT1GqPPL8w0B5=U=+=vsb7iNYwirjebxiPcWNLo7Pg () mail ! gmail ! com
[Download RAW message or body]


On Mon, Feb 24, 2014 at 4:13 PM, Andrey Andreev <narf@devilix.net> wrote:

> Hey,
>
> Rouven Weßling <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ßling <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 ==/=== 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


[prev in list] [next in list] [prev in thread] [next in thread]