Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70862
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52B81B9F.6040609@php.net>
References: <3014595E-B155-47F6-AC7B-71083D89525D@rouvenwessling.de>
 <52B80C5B.2050208@sugarcrm.com> <6C0AE2F4-26DA-4081-914A-F6D18C46911C@rouvenwessling.de>
 <52B81559.8080409@php.net> <CADyq6sJESC+UG_Vb7Wq=nHQWF0-5zL=7Yzpi2L8rr4CQwyr5ug@mail.gmail.com>
 <52B81B9F.6040609@php.net>
Date: Mon, 23 Dec 2013 12:25:35 +0100
Message-ID: <CADyq6sJR6VZ0Fx907pFdbzJoSxYMgSh8+SNevYgF3LoUcmnZnQ@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc13fe2b0b2304ee31e439
Subject: Re: [PHP-DEV] [RFC] Timing attack safe string comparison function
From: ocramius@gmail.com (Marco Pivetta)

--047d7bdc13fe2b0b2304ee31e439
Content-Type: text/plain; charset=UTF-8

On 23 December 2013 12:16, Joe Watkins <krakjoe@php.net> wrote:

>
> 291    /* We're using this method instead of == in order to provide
> 292     * resistence towards timing attacks. This is a constant time
> 293     * equality check that will always check every byte of both
> 294     * values. */
> 295    for (i = 0; i < hash_len; i++) {
> 296        status |= (ret[i] ^ hash[i]);
> 297    }
>
> So that puts in perspective the what if it borks argument, and the
> complication argument too, since the new function and old can share a
> static inline implementation of the same logic ... do you really want me to
> explain why static inline c is better than PHP, or is that obvious at this
> point ??
>

The performance question is irrelevant to me - I don't think I'd ever code
a performance-sensitive API with this sort of function, but maybe someone
has a real world example for that. Slower is probably even better here :P

Let me re-state: "performance is not a problem here".


> I would love it if at some point in the future you could point at bits of
> PHP and say "that's a good implementation",


That's admirable, but the userland implementation seems ok for me as well.


> Anyone who doesn't see that, is barking mad, barking, mad ...
>
>
I'm always barking mad :-)


Cheers,


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--047d7bdc13fe2b0b2304ee31e439--