Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72781
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
Message-ID: <530AFE9A.30502@lsces.co.uk>
Date: Mon, 24 Feb 2014 08:11:06 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <9E3AA302-1EC1-4497-996F-716555CAAB64@rouvenwessling.de> <3EAEC401-F0FF-42E6-8B93-41D2E8658A80@rouvenwessling.de> <47C11B57-84E9-4805-9952-1E78A9F112C5@rouvenwessling.de> <CAGa2bXYz0o=swhqt=OrwdxFScA=LuxZQ=8vpvMxEJj7_FTZUeQ@mail.gmail.com> <8092191F-9B60-43C3-91A8-095FB74C02A5@rouvenwessling.de> <CAGa2bXYE8YFvpMsfksi1QLcULa-7_PKh__=z8AsrKjjYdqxy4w@mail.gmail.com>
In-Reply-To: <CAGa2bXYE8YFvpMsfksi1QLcULa-7_PKh__=z8AsrKjjYdqxy4w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Timing attack safe string comparison function
From: lester@lsces.co.uk (Lester Caine)

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