Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.42 as permitted sender)
	client-ip=209.85.192.42; envelope-from=kevinsisco61784@gmail.com;
	helo=mail-qg0-f42.google.com; 
Message-ID: <53174F20.10207@gmail.com>
Date: Wed, 05 Mar 2014 11:21:52 -0500
From: Kevin <kevinsisco61784@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
In-Reply-To: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------050502050209020300080500"
Subject: Re: [Bitcoin-development] New side channel attack that can recover
 Bitcoin keys
Precedence: list

This is a multi-part message in MIME format.
--------------050502050209020300080500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 3/5/2014 7:49 AM, Mike Hearn wrote:
> A new practical technique has been published that can recover 
> secp256k1 private keys after observing OpenSSL calculate as little as 
> 200 signatures:
>
> http://eprint.iacr.org/2014/161.pdf
>
> This attack is based on the FLUSH+RELOAD technique published last 
> year. It works by observing L3 CPU cache timings and forcing cache 
> line flushes using the clflush opcode. As a result, it is applicable 
> to any x86 environment where an attacker may be able to run on the 
> same hardware i.e. virtualised hosting environments where keys are 
> being reused.
>
> I am not currently aware of any efforts to make OpenSSL's secp256k1 
> implementation completely side channel free in all aspects. Also, 
> unfortunately many people have reimplemented ECDSA themselves and even 
> if OpenSSL gets fixed, the custom implementations probably won't.
>
> So, IMHO this is a sign for hot wallet users to start walking (but not 
> running) towards the exits of these shared cloud services:  it doesn't 
> feel safe to sign transactions on these platforms, so hot wallets 
> should be managed by dedicated hardware. Of course other parts of the 
> service, like the website, are less sensitive and can still run in the 
> cloud. I doubt the researchers will release their code to do the side 
> channel attack and it's rather complex to reimplement, so this gives 
> some time for mitigation. Unfortunately the huge sums being held in 
> some "bitbank" style hot wallets mean that attackers are well 
> motivated to pull off even quite complex attacks.
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> 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=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
How can we patch this issue?


-- 
Kevin


--------------050502050209020300080500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 3/5/2014 7:49 AM, Mike Hearn wrote:<br>
    </div>
    <blockquote
cite="mid:CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com"
      type="cite">
      <div dir="ltr">A new practical technique has been published that
        can recover secp256k1 private keys after observing OpenSSL
        calculate as little as 200 signatures:
        <div><br>
        </div>
        <div><a moz-do-not-send="true"
            href="http://eprint.iacr.org/2014/161.pdf">http://eprint.iacr.org/2014/161.pdf</a><br>
        </div>
        <div><br>
        </div>
        <div>This attack is based on the FLUSH+RELOAD technique
          published last year. It works by observing L3 CPU cache
          timings and forcing cache line flushes using the clflush
          opcode. As a result, it is applicable to any x86 environment
          where an attacker may be able to run on the same hardware i.e.
          virtualised hosting environments where keys are being reused.</div>
        <div><br>
        </div>
        <div>I am not currently aware of any efforts to make OpenSSL's
          secp256k1 implementation completely side channel free in all
          aspects. Also, unfortunately many people have reimplemented
          ECDSA themselves and even if OpenSSL gets fixed, the custom
          implementations probably won't.&nbsp;</div>
        <div><br>
        </div>
        <div>So, IMHO this is a sign for hot wallet users to start
          walking (but not running) towards the exits of these shared
          cloud services: &nbsp;it doesn't feel safe to sign transactions on
          these platforms, so hot wallets should be managed by dedicated
          hardware. Of course other parts of the service, like the
          website, are less sensitive and can still run in the cloud. I
          doubt the researchers will release their code to do the side
          channel attack and it's rather complex to reimplement, so this
          gives some time for mitigation. Unfortunately the huge sums
          being held in some "bitbank" style hot wallets mean that
          attackers are well motivated to pull off even quite complex
          attacks.</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion &amp; Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=122218951&amp;iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=122218951&amp;iu=/4140/ostg.clktrk</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    How can we patch this issue?<br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Kevin
</pre>
  </body>
</html>

--------------050502050209020300080500--