Re: [Cfrg] considering new topics for CFRG

Henrick Hellström <henrick@streamsec.se> Sat, 04 January 2014 02:20 UTC

Return-Path: <henrick@streamsec.se>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0F1AE032 for <cfrg@ietfa.amsl.com>; Fri, 3 Jan 2014 18:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.649
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2al50eD-SAoT for <cfrg@ietfa.amsl.com>; Fri, 3 Jan 2014 18:20:47 -0800 (PST)
Received: from vsp8.ballou.se (vsp8.ballou.se [91.189.40.104]) by ietfa.amsl.com (Postfix) with SMTP id 04B881AE024 for <cfrg@irtf.org>; Fri, 3 Jan 2014 18:20:46 -0800 (PST)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp8.ballou.se (Halon Mail Gateway) with ESMTP for <cfrg@irtf.org>; Sat, 4 Jan 2014 03:20:36 +0100 (CET)
Received: from [192.168.0.195] (c-a2c1e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.193.162]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 41997128F6B for <cfrg@irtf.org>; Sat, 4 Jan 2014 03:20:35 +0100 (CET)
Message-ID: <52C76FE1.2020205@streamsec.se>
Date: Sat, 04 Jan 2014 03:20:17 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= <henrick@streamsec.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <52C755AA.70200@cisco.com>
In-Reply-To: <52C755AA.70200@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] considering new topics for CFRG
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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.