Re: [VOTE] Timing attack safe string comparison function

From: Date: Mon, 24 Feb 2014 08:11:06 +0000
Subject: Re: [VOTE] Timing attack safe string comparison function
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
Yasuo Ohgaki 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?


Surely there are two elements to this?

Simply comparing two strings in a time stable manner is relatively easy. You just modify the compare to store the result and always complete a full scan. Only the lengths of the string come into that. How physically that is handled in the processor will actually determine if the time taken is 'byte sensitive' anyway! Simply stopping the core process from the unnecessary <> comparison where the answer is not used is going to be a performance gain, all be it minuscule, but the timing differences that are trying to be hidden are even smaller than that? Tidying the core use of string compare is generally more useful than simply adding yet another method of calling it.

The other element here is actually calculating the hash value to compare with? That will also depend on just how the processor is processing multiple bytes, so simply fixing the final comparison may be somewhat irrelevant if the hash generation also has a leak? Yes it should be another constant, but what is being fed in is the variable being changed during the attack?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Thread (54 messages)

« previous php.internals (#72781) next »