Date: Tue, 25 Mar 2014 08:39:25 -0500
From: Troy Benjegerdes <hozer@hozed.org>
To: Natanael <natanael.l@gmail.com>
Message-ID: <20140325133925.GW3180@nl.grid.coop>
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
	<0720C223-E9DD-4E76-AD6F-0308CA5B5289@gmail.com>
	<CAAS2fgTGDzPFDP=ii08VXcXYpWr2akYWxqJCNHW-ABuN=ESc8A@mail.gmail.com>
	<7E50E1D6-3A9F-419B-B01E-50C6DE044E0F@gmail.com>
	<CAAS2fgScLKgq8_V0oVpvP1gYAKxiyVNGVWA86XfecSmPqsMKUg@mail.gmail.com>
	<CANEZrP1+=JY0RGEMvm9iL09L-tZAWqsSOOwFaroYUKkWumx+xg@mail.gmail.com>
	<CAAt2M19R_97aXs9rwo8UY5PE7DwHZDT12esPhz76M1EOdGrrdQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
In-Reply-To: <CAAt2M19R_97aXs9rwo8UY5PE7DwHZDT12esPhz76M1EOdGrrdQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New side channel attack that can recover
 Bitcoin keys
Precedence: list

This *could* be a useful feature, but only if it's generalizable to
other processor architectures, and **in particular** has an implementatio=
n
using dedicated silicon that has a **public** open-source hardware layout=
,
so you can X-ray the chip, and confirm with a thermal imager that yes, th=
e
encryption code is actually running where you think it's running.

I was *almost* convinced that the 'new key per address' was a good idea
to mitigate ECDSA side channel attacks. Now, however, I find it quite=20
plausible that intelligence agencies are promoting 'new key per transacti=
on'
as a way to make sure all your keys are leaked all over RAM and the nearb=
y
electromagnetic spectrum with side channels intentionally embedded in
commodity hardware.

If you want to convince me otherwise, then help me crowdfund an open-sour=
ce
hardware Bitcoin ASIC that does the crypto and stores your private keys.=20

I expect the 'new key per transaction' crowd will be in for a rude awaken=
ing
when they finally understand the silicon area cost to do this securely.

Conclusion: Not only is 'de-prioritizing address re-use' BAD privacy, it=20
provides a social engineering/key leakage attack vector where someone can
track you down from the EMF generated by your bitcoin wallet when they se=
nd
you money.

If you think otherwise, let's build some ficking open-source hardware and=20
find out how much silicon this will cost.

Although it's probably more profitable to just build a bitcoin wallet=20
detector and keep your mouth shut.

On Thu, Mar 06, 2014 at 11:00:14AM +0100, Natanael wrote:
> You've heard of TRESOR?
>=20
> No, not Trezor.
>=20
> https://en.wikipedia.org/wiki/TRESOR
>=20
> Signing on the CPU, without touching RAM.
>=20
> - Sent from my phone
> Den 6 mar 2014 09:41 skrev "Mike Hearn" <mike@plan99.net>:
>=20
> > I'm wondering about whether (don't laugh) moving signing into the ker=
nel
> > and then using the MTRRs to disable caching entirely for a small scra=
tch
> > region of memory would also work. You could then disable pre-emption =
and
> > prevent anything on the same core from interrupting or timing the sig=
ning
> > operation.
> >
> > However I suspect just making a hardened secp256k1 signer implementat=
ion
> > in userspace would be of similar difficulty, in which case it  would
> > naturally be preferable.
> >
> >
> > On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell <gmaxwell@gmail.com>=
wrote:
> >
> >> On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo <elombrozo@gmail.com>
> >> wrote:
> >> > Everything you say is true.
> >> >
> >> > However, branchless does reduce the attack surface considerably - =
if
> >> nothing else, it significantly ups the difficulty of an attack for a
> >> relatively low cost in program complexity, and that might still make =
it
> >> worth doing.
> >>
> >> Absolutely. I believe these things are worth doing.
> >>
> >> My comment on it being insufficient was only that "my signer is
> >> branchless" doesn't make other defense measures (avoiding reuse,
> >> multsig with multiple devices, not sharing hardware, etc.)
> >> unimportant.
> >>
> >> > As for uniform memory access, if we avoided any kind of heap
> >> allocation, wouldn't we avoid such issues?
> >>
> >> No. At a minimum to hide a memory timing side-channel you must perfo=
rm
> >> no data dependent loads (e.g. no operation where an offset into memo=
ry
> >> is calculated). A strategy for this is to always load the same value=
s,
> >> but then mask out the ones you didn't intend to read... even that I'=
d
> >> worry about on sufficiently advanced hardware, since I would very mu=
ch
> >> not be surprised if the processor was able to determine that the loa=
d
> >> had no effect and eliminate it! :) )
> >>
> >> Maybe in practice if your data dependencies end up only picking arou=
nd
> >> in the same cache-line it doesn't actually matter... but it's hard t=
o
> >> be sure, and unclear when a future optimization in the rest of the
> >> system might leave it exposed again.
> >>
> >> (In particular, you can't generally write timing sign-channel immune
> >> code in C (or other high level language) because the compiler is
> >> freely permitted to optimize things in a way that break the property=
.
> >> ... It may be _unlikely_ for it to do this, but its permitted=E2=80=94 =
and
> >> will actually do so in some cases=E2=80=94, so you cannot be complet=
ely sure
> >> unless you check and freeze the toolchain)
> >>
> >> > Anyhow, without having gone into the full details of this particul=
ar
> >> attack, it seems the main attack point is differences in how squarin=
g and
> >> multiplication (in the case of field exponentiation) or doubling and =
point
> >> addition (in the case of ECDSA) are performed. I believe using a bra=
nchless
> >> implementation where each phase of the operation executes the exact =
same
> >> code and accesses the exact same stack frames would not be vulnerabl=
e to
> >> FLUSH+RELOAD.
> >>
> >> I wouldn't be surprised.
> >>
> >>
> >> --------------------------------------------------------------------=
----------
> >> Subversion Kills Productivity. Get off Subversion & Make the Move to
> >> Perforce.
> >> With Perforce, you get hassle-free workflows. Merge that actually wo=
rks.
> >> Faster operations. Version large binaries.  Built-in WAN optimizatio=
n and
> >> the
> >> freedom to use Git, Perforce or both. Make the move to Perforce.
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140=
/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> > ---------------------------------------------------------------------=
---------
> > Subversion Kills Productivity. Get off Subversion & Make the Move to
> > Perforce.
> > With Perforce, you get hassle-free workflows. Merge that actually wor=
ks.
> > Faster operations. Version large binaries.  Built-in WAN optimization =
and
> > the
> > freedom to use Git, Perforce or both. Make the move to Perforce.
> >
> > http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140/=
ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >

> -----------------------------------------------------------------------=
-------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Pe=
rforce.
> With Perforce, you get hassle-free workflows. Merge that actually works=
.=20
> Faster operations. Version large binaries.  Built-in WAN optimization a=
nd the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140/os=
tg.clktrk

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--=20
-------------------------------------------------------------------------=
---
Troy Benjegerdes                 'da hozer'                  hozer@hozed.=
org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.c=
oop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash