diff options
| author | Peter Todd <pete@petertodd.org> | 2014-03-05 15:32:22 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-05 20:32:52 +0000 |
| commit | 508693ee08431ce4a4eaa5e77f276e429ceec40a (patch) | |
| tree | 4b98fa18f4d5a680d9a05c45274f0c83ad102ec2 | |
| parent | afc2f6427e72da295be55a19981e9effaea85682 (diff) | |
| download | pi-bitcoindev-508693ee08431ce4a4eaa5e77f276e429ceec40a.tar.gz pi-bitcoindev-508693ee08431ce4a4eaa5e77f276e429ceec40a.zip | |
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
| -rw-r--r-- | 91/6a6c219d13c83932da69d38803dae037548ff0 | 149 |
1 files changed, 149 insertions, 0 deletions
diff --git a/91/6a6c219d13c83932da69d38803dae037548ff0 b/91/6a6c219d13c83932da69d38803dae037548ff0 new file mode 100644 index 000000000..6b40eb3d6 --- /dev/null +++ b/91/6a6c219d13c83932da69d38803dae037548ff0 @@ -0,0 +1,149 @@ +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 <pete@petertodd.org>) id 1WLIUm-0001jv-Nz + for bitcoin-development@lists.sourceforge.net; + Wed, 05 Mar 2014 20:32:52 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org + designates 62.13.149.81 as permitted sender) + client-ip=62.13.149.81; envelope-from=pete@petertodd.org; + helo=outmail149081.authsmtp.net; +Received: from outmail149081.authsmtp.net ([62.13.149.81]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1WLIUl-0006w2-Ej for bitcoin-development@lists.sourceforge.net; + Wed, 05 Mar 2014 20:32:52 +0000 +Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) + by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s25KWiPr007436; + Wed, 5 Mar 2014 20:32:44 GMT +Received: from tilt ([64.210.40.106]) (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s25KWPt8065532 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Wed, 5 Mar 2014 20:32:36 GMT +Date: Wed, 5 Mar 2014 15:32:22 -0500 +From: Peter Todd <pete@petertodd.org> +To: Gregory Maxwell <gmaxwell@gmail.com> +Message-ID: <20140305203222.GD24917@tilt> +References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com> + <53174F20.10207@gmail.com> <20140305193910.GA24917@tilt> + <CAAS2fgR+q4fDs3JfX9az8b17Dk7VKjC3SxYja-2spwU-kM74fA@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="AkbCVLjbJ9qUtAXD" +Content-Disposition: inline +In-Reply-To: <CAAS2fgR+q4fDs3JfX9az8b17Dk7VKjC3SxYja-2spwU-kM74fA@mail.gmail.com> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Server-Quench: 4cb9dfc4-a4a5-11e3-b802-002590a15da7 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aQdMdgcUFVQGAgsB AmIbWVReU197XWI7 bQ5PbwRdfE5OQQRq + VldMSlVNFUsrAxl6 YX5aWhl0cgBFejBx Y0ViXj5fDxZzIRAu + RlMFETwDeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES + HhM4ODE3eDlSNilR RRkIIFQOdA4tEyF0 XBEOEH0kHUQDQSg3 + ZxU6NlcXHw4NMkwu eVAoXxoCPhQVFABE fQlnATNSIFgHDykm HBgy +X-Authentic-SMTP: 61633532353630.1023:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 64.210.40.106/587 +X-AuthVirus-Status: No virus detected - but ensure you scan with your own + anti-virus system. +X-Spam-Score: -0.9 (/) +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.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server + [64.210.40.106 listed in dnsbl.sorbs.net] + -0.0 SPF_PASS SPF: sender matches SPF record +X-Headers-End: 1WLIUl-0006w2-Ej +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 20:32:52 -0000 + + +--AkbCVLjbJ9qUtAXD +Content-Type: text/plain; charset=utf-8 +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Wed, Mar 05, 2014 at 11:51:25AM -0800, Gregory Maxwell wrote: +> On Wed, Mar 5, 2014 at 11:39 AM, Peter Todd <pete@petertodd.org> wrote: +> > If you're following good practices you're not particularly vulneable to +> > it, if at all, even if you make use of shared hosting. First of all you +> > shouldn't be re-using addresses, which means you won't be passing that +> > ~200 sig threshold. +> > +> > More important though is you shouldn't be using single factor Bitcoin +> > addresses. Use n-of-m multisig instead and architect your system such +>=20 +> Both of these things have long been promoted as virtuous in part +> because they increase robustness against this sort of thing. +>=20 +> But while I don't disagree with these things the reality is that many +> people do not follow either of these piece of advice and following +> them requires behavioral changes that will not be adopted quickly... +> so I don't think that advice is especially useful. +>=20 +> And even if it were=E2=80=94, good security involves defense in depth, so +> adding on top of them things like side-channel resistant signing is +> important. +>=20 +> I haven't had a chance to sit down and think through it completely but +> I believe oleganza's recent blind signature scheme for ECDSA may be +> helpful (http://oleganza.com/blind-ecdsa-draft-v2.pdf): +>=20 +> The idea is that instead of (or in addition to=E2=80=94 belt and suspende= +rs) +> making the signing constant time, you use the blinding scheme to first +> locally blind the private key and point being signed, then sign, then +> unblind. This way even if you are reusing a key every signing +> operation is handling different private data... and the only point +> where unblinded private data is handled is a simple scalar addition. + +That's nice, but I wrote my advice to show people how even if they don't +know any crypto beyond what the "black boxes" do - the absolute minimum +you need to know to write any Bitcoin software - you can still defend +yourself against that attack and many others. + +Point is you can architect systems that remain secure even when parts of +them fail, and you don't need any special cryptographic background to do +so - any competent programmer can. + +Meanwhile, if you're not willing to take those simple steps, the Bitcoin +community damn well should look down on your amateur efforts, e.g. +Coinbase and EasyWallet. + +--=20 +'peter'[:-1]@petertodd.org +000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 + +--AkbCVLjbJ9qUtAXD +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.12 (GNU/Linux) + +iQEcBAEBCAAGBQJTF4nWAAoJECSBQD2l8JH7gJkH/3VzB+d9raGrN6szwkvMGLs8 +do36FrD8S3+EyXvK9q2S9NyXWRvZLXd3XLRhHLx3MYp1aUDuu6A8UyVyv3Chk4oo +MpaQwt/nF/a0OB1yFgf2rsnlDVIhoOj7AM0RCzrY71iU5I7nT0VVHwQOt4X1llgB +UnGAAKuzhgRZukd8FkxQxbZvUn9cCBk+6cah8vES/U0ELx1S9Y9BSTFEaYRevyoL +5h5eAkZUtziz+jdQ0QUVrJejXm31mqgNQ1Ig17YOqLQpJqeS3jgFW31sqKKVzaCP +ex1EcbH2FxNV+XNQy5J64istonJNpC6sBz5qjaKyfN6Kwmpa8BAKY1DCpfa4ZEY= +=+fZf +-----END PGP SIGNATURE----- + +--AkbCVLjbJ9qUtAXD-- + + |