Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <0720C223-E9DD-4E76-AD6F-0308CA5B5289@gmail.com>
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
	<0720C223-E9DD-4E76-AD6F-0308CA5B5289@gmail.com>
Date: Wed, 5 Mar 2014 13:44:30 -0800
Message-ID: <CAAS2fgTGDzPFDP=ii08VXcXYpWr2akYWxqJCNHW-ABuN=ESc8A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New side channel attack that can recover
 Bitcoin keys
Precedence: list

On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> If we don't mind sacrificing some performance when signing, there's a fairly
> simple way to implement a constant-time constant-cache-access-pattern
> secp256k1.
> It is based on the idea of branchless implementations of the field and group
> operations.

Do take care that branchless doesn't mean side-channel free: On
non-trivial hardware you must have uniform memory accesses too.

(and that itself isn't enough for sidechannel freeness against an
attacker that can do power analysis... then you star worrying about
the internal structure your primitive adders and the hamming weight of
your numbers, and needing to build hardware that uses differential
logic, and yuck yuck yuck:  This is why you still shouldn't reuse
addresses, and why a blinding approach may still be sensible, even if
you believe your implementation is hardened against side-channels)