Re: [VOTE] Timing attack safe string comparison function
| From: | Yasuo Ohgaki | 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