Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72432 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22881 invoked from network); 10 Feb 2014 08:59:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Feb 2014 08:59:55 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:46995] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9C/90-18799-A0598F25 for ; Mon, 10 Feb 2014 03:59:54 -0500 Received: (qmail 7911 invoked by uid 89); 10 Feb 2014 08:59:51 -0000 Received: by simscan 1.3.1 ppid: 7905, pid: 7908, t: 0.0733s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 10 Feb 2014 08:59:50 -0000 Message-ID: <52F895CB.2020308@lsces.co.uk> Date: Mon, 10 Feb 2014 09:03:07 +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: internals@lists.php.net References: <9E3AA302-1EC1-4497-996F-716555CAAB64@rouvenwessling.de> In-Reply-To: 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: > 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. -- 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