Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72498
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52F895CB.2020308@lsces.co.uk>
References: <9E3AA302-1EC1-4497-996F-716555CAAB64@rouvenwessling.de>
 <CAGa2bXYBbPw8RYZmwHPGe8BPFvicjNs1bD85QvRjMJ6i9aoPuQ@mail.gmail.com>
 <CAGa2bXa35rkmqNLvMw-9hkPJ6F2oPgpzkk4aMXe_9Vbfuoxc2g@mail.gmail.com>
 <CAGa2bXbuH7cDpr6_F==wse-s7doExxqB-BJzP1Vm_127aJ1O2A@mail.gmail.com> <52F895CB.2020308@lsces.co.uk>
Date: Wed, 12 Feb 2014 16:01:35 +0900
Message-ID: <CAGa2bXb36sL4kNvVBC=D3cK0+FQWnyJhR0Kjh7f_HEFCB91KBA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122814819ff1104f230277e
Subject: Re: [PHP-DEV] [VOTE] Timing attack safe string comparison function
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0122814819ff1104f230277e
Content-Type: text/plain; charset=UTF-8

Hi Lester,

On Mon, Feb 10, 2014 at 6:03 PM, Lester Caine <lester@lsces.co.uk> wrote:

> Yasuo Ohgaki wrote:
>
>> Added yet another function to compare suggested by Lester.
>>
>> bool str_word_compare(str, str)
>>
>> This function compares data word by word rather than byte by byte.
>> It supposed to be faster for large data.
>>
>
> Yasuo ... you seem to be missing the point, and I'm not quite sure where
> all these different hash compares come from but ...
>
> bool memequ() should only return true or false and simply compare 'word by
> word' be that 32bit or 64bit words. There should be nothing in the macro
> than an word XOR, and buffers should be padded to the right boundary. It is
> the processing of unnecessary byte related data which is adding back in
> your 'insecurity', but it is also adding extra unnecessary processing.
>
> The point about 'memequ' is that it should both speed up any use of memcpy
> where there is no need to return anything other than a match ... it is the
> subsequent search to find the '</>' byte which even introduces the timing
> attack ... and it also makes these compares unicode safe! So that it is
> only the compares that need the fine result that then need handling for a
> full unicode installation.


The reason why word version of comparison function(str_word_compare) does
not
simply compare word by word, is alignment.

We cannot assume word aligned data for strings. This is the reason why
there is
additional byte by byte comparison. It could be made to align memory to
word size,
but it requires memory allocation for comparison. I'm not sure which is
better, though.

Regards,

BTW, byte by byte part comparison can be optimized by switch since
unaligned data
is only up to 7 bytes.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0122814819ff1104f230277e--