From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WSRZq-0005tG-TO for bitcoin-development@lists.sourceforge.net; Tue, 25 Mar 2014 13:39:38 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WSRZk-0002Lr-Rq for bitcoin-development@lists.sourceforge.net; Tue, 25 Mar 2014 13:39:38 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Tue, 25 Mar 2014 08:39:25 -0500 id 000000000006A342.000000005331870D.00003522 Date: Tue, 25 Mar 2014 08:39:25 -0500 From: Troy Benjegerdes To: Natanael Message-ID: <20140325133925.GW3180@nl.grid.coop> References: <0720C223-E9DD-4E76-AD6F-0308CA5B5289@gmail.com> <7E50E1D6-3A9F-419B-B01E-50C6DE044E0F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.68.2 X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WSRZk-0002Lr-Rq Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 13:39:39 -0000 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" : >=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 = wrote: > > > >> On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo > >> 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