Re: [Cfrg] Comments on side channel draft

Manuel Pégourié-Gonnard <> Wed, 08 January 2014 17:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 532C01ADFF8 for <>; Wed, 8 Jan 2014 09:34:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.893
X-Spam-Level: **
X-Spam-Status: No, score=2.893 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VEYUdajgujWu for <>; Wed, 8 Jan 2014 09:34:23 -0800 (PST)
Received: from (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by (Postfix) with ESMTP id 554C01AD9AD for <>; Wed, 8 Jan 2014 09:34:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id EE7241614F for <>; Wed, 8 Jan 2014 18:34:12 +0100 (CET)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id BD82129883 for <>; Wed, 8 Jan 2014 18:34:09 +0100 (CET)
Message-ID: <>
Date: Wed, 08 Jan 2014 18:34:09 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: "" <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] Comments on side channel draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jan 2014 17:34:25 -0000

On 08/01/2014 01:21, Watson Ladd wrote:
> Blinding is my second choice compared to constant time. The reason is
> that blinding might not work perfectly, whereas circuit-like programs have
> no timing sidechannels by definition.
Maybe the draft should go into more details about he possible shortcomings of
blinding then.

I feel like, for existing implementations, it's often easier to add blinding at
some well-chosen places than to rewrite their whole arithmetic from scratch to
be constant-time. So, used properly, it can be an interesting way to gradually
enhance the resistance of existing implementations.

> The problem is that one really cannot tell what does and does not contain
> jumps without looking at the assembler output.

Agreed. However, there seems to be ways to code things that are commonly
accepted as producing no hidden branches on common platforms with common compilers.

> Mix in the different compilers, architectures, and compiler options, and
> this is far, far too much work for me to reasonably do.
Sure, but by the same reasoning it's too much work for any implementer wanting
to write portable code (so that assembly isn't an option). IMO this is precisely
in such situations that it is useful to share the collective knowledge of the
CFRG in a document that can then be relied upon by others, even if it's not

If providing reliable solutions is too hard, then at least the draft could warn
about constructs that may look constant-time but are actually not of some common
platforms. Examples could include integer division (see below), and the "hidden
branch in 'c = (a == b)'" issue if it's still an issue with common compilers on
common platforms.

> Even integer division is not constant time on some CPU families.
Well, it's not just some exotic CPUs, it includes common Intel, AMD, ARM and Via
CPUs at least, according to [1] (which focuses on floating point but also tests
integer operation).