Re: [VOTE] Timing attack safe string comparison function

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