1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WLJcE-00053B-CC
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 21:44:38 +0000
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;
Received: from mail-la0-f47.google.com ([209.85.215.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WLJcD-0006aj-He
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 21:44:38 +0000
Received: by mail-la0-f47.google.com with SMTP id y1so1148595lam.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 05 Mar 2014 13:44:31 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.138.10 with SMTP id qm10mr4742411lbb.19.1394055870927;
Wed, 05 Mar 2014 13:44:30 -0800 (PST)
Received: by 10.112.189.164 with HTTP; Wed, 5 Mar 2014 13:44:30 -0800 (PST)
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
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WLJcD-0006aj-He
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New side channel attack that can recover
Bitcoin keys
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 21:44:38 -0000
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)
|
