Re: [VOTE] Timing attack safe string comparison function

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. :) 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.