Re: [Cfrg] considering new topics for CFRG

Henrick Hellström <> Sat, 04 January 2014 02:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E1B0F1AE032 for <>; Fri, 3 Jan 2014 18:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.649
X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2al50eD-SAoT for <>; Fri, 3 Jan 2014 18:20:47 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 04B881AE024 for <>; Fri, 3 Jan 2014 18:20:46 -0800 (PST)
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Sat, 4 Jan 2014 03:20:36 +0100 (CET)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 41997128F6B for <>; Sat, 4 Jan 2014 03:20:35 +0100 (CET)
Message-ID: <>
Date: Sat, 04 Jan 2014 03:20:17 +0100
From: Henrick Hellström <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] considering new topics for CFRG
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: Sat, 04 Jan 2014 02:20:50 -0000

On 2014-01-04 01:28, David McGrew wrote:
> - Documenting ways of implementing existing algorithms that resist
> side-channel attacks, especially timing attacks.   This could include
> documentation of naive implementation methods that are vulnerable, or
> experimental work quantifying vulnerabilities.

I find this very interesting, in particular considering that things like 
arithmetics often get implemented using either an input dependent number 
of instructions, or if with a constant number of instructions, with 
branches, or if not, with branch-less pointer swapping, instead of 
branch-less memory swapping.

Hence, potentially vulnerable implementations have either of the 
following features:

- branches, except loops with a number of iterations that must only 
depend on public parameter values (such as "bit sizes"),
- value dependent memory access, including branch-less pointer swapping

Conversely, any algorithm that can be implemented in such way that the 
number of instructions performed, and the memory addresses accessed, *do 
not* depend of the value of the arguments, can only be vulnerable if the 
CPU itself does not execute individual instructions in constant time.