Re: [VOTE] Timing attack safe string comparison function

From: Date: Mon, 24 Feb 2014 04:22:00 +0000
Subject: Re: [VOTE] Timing attack safe string comparison function
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-72780@lists.php.net to get a copy of this message
Hi Rouven, On Mon, Feb 24, 2014 at 6:05 AM, 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? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net

« previous php.internals (#72780) next »