Re: [Cfrg] Side Channel Attacks Against Curve25519

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 10 September 2017 12:40 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AE41326DF for <cfrg@ietfa.amsl.com>; Sun, 10 Sep 2017 05:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 WmuVuF5Yx7A6 for <cfrg@ietfa.amsl.com>; Sun, 10 Sep 2017 05:40:46 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBD9132697 for <cfrg@irtf.org>; Sun, 10 Sep 2017 05:40:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 126DF5371A; Sun, 10 Sep 2017 15:40:44 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id RDbOqyFaK1Dp; Sun, 10 Sep 2017 15:40:43 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 7E4BE27B; Sun, 10 Sep 2017 15:40:41 +0300 (EEST)
Date: Sun, 10 Sep 2017 15:40:40 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Thomas Garcia <tgarcia.3141@gmail.com>
Cc: cfrg@irtf.org
Message-ID: <20170910124040.q2jq5mmaysi5k5ss@LK-Perkele-VII>
References: <CAFTSWvdq8p3i20veq=GgHi_rnOS6Wv4dK1xQpJHaPS4r5e5-SQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAFTSWvdq8p3i20veq=GgHi_rnOS6Wv4dK1xQpJHaPS4r5e5-SQ@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/3AZTcPtM3azOCZKux2_3qfwKD1A>
Subject: Re: [Cfrg] Side Channel Attacks Against Curve25519
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Sep 2017 12:40:48 -0000

On Sun, Sep 10, 2017 at 08:12:28AM +0100, Thomas Garcia wrote:

> something similar be done to encourage correct bignum arithmetic? Is it
> possible to choose the parameters, such as the prime, such that the
> simplest implementation will be less susceptible to side channel attacks?
> What I imagine is a prime which would normally have long computation times,
> but has a trick that enables simpler addition which is coincidentally
> constant time.

I do not know how much modern bigint libraries optimize based on the
prime. However, the very idea of fast primes for ECC is that those
primes have various tricks to perform fast modular multiplication
(since multiplication is the dominant cost). And those kinds of primes
are pretty rare, especially the more efficient (relative to size) ones.


Both X25519 and X448 have useful reductions in base field
((2^51)^5 -> 19 and ((2^56)^4)^2 -> ((2^56)^4)^1 + ((2^56)^4)^0,
respectively).


Of course, one could use reductions like that to optimize the modulo
operation with bigint library, but dedicated constant-time routine
would still likely be faster with little optimization. Especially as
one can partially fold those reductions into multiplication itself.


Then there are other forms of side-channel leakage beside base field
arithmetic. E.g. the conditional swaps in Montgomery ladder. However,
most other forms of elliptic curves have actual conditional adds or
even worse, edge cases in addition.


-Ilari