Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A50BD17581 for ; Fri, 29 May 2015 16:39:05 +0000 (UTC) Received: (qmail 42160 invoked by uid 500); 29 May 2015 16:39:04 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 42091 invoked by uid 500); 29 May 2015 16:39:04 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 42077 invoked by uid 99); 29 May 2015 16:39:04 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 May 2015 16:39:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 2D2F61A403B for ; Fri, 29 May 2015 16:39:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.998 X-Spam-Level: ** X-Spam-Status: No, score=2.998 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id kG-rJIcZicw9 for ; Fri, 29 May 2015 16:39:03 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 7D6BE24CE8 for ; Fri, 29 May 2015 16:39:02 +0000 (UTC) Received: by iepj10 with SMTP id j10so66804508iep.3 for ; Fri, 29 May 2015 09:38:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1vwfPkfltPMITWoHIxfoYcgM+TqwvfKJGSJfqC/Z5SU=; b=WIHVlelfvwWdMjjD/ssk6Hg+HxsVYTuS3K8/b8UUYY2LR/kwDR/hLJOskbH0YcJrrh DkMOtbSx1GrJSUKlkMI67Ay7/pPOGKcARzkMGNzOUGF823qebVdIiEM/Eod4WWOhUP2r x95kzqe41kAWVDQfgf20hN++KI8Q4I7P+wCsxOPfMS2QRwvQ04iHbtLdRTtUe0YI8kQN CdcVzCVu0LneaI1hicJxcqlQ+XDFLfEj548jMQAtSmNYYgnWy/3tPZdhfvsWJytH3hnm 6y2MCpjFmJkJFOPZqt/wMt4ZcgoCf13eIvFOQ7ZBRXJSbEXHTkPZzOhDDKjQTNcyK6BC M06w== X-Gm-Message-State: ALoCoQmO8lig7ljS7WhKuJE+Lf4rE6TA8Ud71lPLQDdf4b7vmw8xNlt0Cr1kYuH2+t5XOzqSf2+5 MIME-Version: 1.0 X-Received: by 10.50.90.179 with SMTP id bx19mr5120376igb.43.1432917534860; Fri, 29 May 2015 09:38:54 -0700 (PDT) Received: by 10.107.190.195 with HTTP; Fri, 29 May 2015 09:38:54 -0700 (PDT) X-Originating-IP: [76.252.112.72] Received: by 10.107.190.195 with HTTP; Fri, 29 May 2015 09:38:54 -0700 (PDT) In-Reply-To: References: <4FC92B9D-977C-4E97-858B-95059898B192@webweaving.org> <3E2C9806-4617-4BBE-972E-384EB49CEB97@webweaving.org> <6855C7BB-796E-494F-822F-0C8F479A556A@webweaving.org> <3AB5558F-D8E5-4D56-8A12-644A9EFF4F7E@webweaving.org> <7C2493F9-AB5C-43BC-BEA1-FB113DBDA257@webweaving.org> <9B9BFA13-0679-4FB4-A2E1-A30A6A36DC9B@webweaving.org> Date: Fri, 29 May 2015 11:38:54 -0500 Message-ID: Subject: Re: Good at assembler ? (Was:httpd - side channel attack - timing of digest comparisons) From: William A Rowe Jr To: httpd Content-Type: multipart/alternative; boundary=047d7bea4294a8817705173b1c66 --047d7bea4294a8817705173b1c66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Secondly - when we get to the end of the shorter string; we can either keep comparing to the last char or \0; or we go =E2=80=98modulo=E2=80=99 to= the start of the string. Now modulo is perhaps not ideal; and seems to affect the pipeline on the XEON cpu (something I confess not to quite understand; and I cannot see/replicate on ARM). Comparing the same byte is easily optimized out. What about looping over the same 16-byte micro-page we ended with, to avoid fetching much earlier pages? Truncate the address by nulling pointer bits 0x0f ? --047d7bea4294a8817705173b1c66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> Secondly - when we get to the end of the shorter string; we can either= keep comparing to the last char or \0; or we go =E2=80=98modulo=E2=80=99 t= o the start of the string. Now modulo is perhaps not ideal; and seems to af= fect the pipeline on the XEON cpu (something I confess not to quite underst= and; and I cannot see/replicate on ARM).

Comparing the same byte is easily optimized out.

What about looping over the same 16-byte micro-page we ended= with, to avoid fetching much earlier pages?=C2=A0 Truncate the address by = nulling pointer bits 0x0f ?

--047d7bea4294a8817705173b1c66--