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

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

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.

--

--

Tjerk