public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Date: Wed, 12 Mar 2014 05:44:24 -0400	[thread overview]
Message-ID: <20140312094424.GD15281@savin> (raw)
In-Reply-To: <CAAS2fgRTuOaSbTqnCOp=783gLCeh7ZU0FWbxzMS6pe8WKPTcLQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

On Wed, Mar 05, 2014 at 12:54:04PM -0800, Gregory Maxwell wrote:
> On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd <pete@petertodd.org> wrote:
> > 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.
> 
> But it's still incomplete.
> 
> Say you have an address— used only once!— with a txout with a lot of value.
> 
> Someone starts paying you small amounts to that address over and over
> again. You haven't asked them to, they're just doing it.
> 
> Do you ignore the funds?— maybe tell some customer that was ignorantly
> paying you over and over again to a single address "sorry, those are
> my rules: I only acknowledge the first payment, those funds are
> lost!".
> 
> No, of course not.  You spend the darn coins and if you're on a shared
> host perhaps you disclose a private key.
> 
> The probability of an attack actually going on is low enough compared
> to the cost of spending the coins in that case that even someone with
> good knoweldge of the risks will choose to do so.
> 
> So absolutely, not reusing addresses massively increases your safety
> and limits losses when there is theft. But it isn't enough alone. (Nor
> is smarter signing, considering complex software like this has bugs
> and its hard to be confident that something is side channel free— esp
> when you allow attacker interference).

I think you're misunderstanding me: I'm assuming one of the n parties
signing transactions in my multi-factor authentication scheme is
uncompromised - much easier to do when it's a low-bandwidth box sitting
in a secure location.

Not re-using keys is nice too of course, and while not perfect - your
above scenario - certainely helps limit losses.

-- 
'peter'[:-1]@petertodd.org
0000000000000000afcad9265e8b44bf1171a08165c09b329fab2893bf13ec69

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

  reply	other threads:[~2014-03-12  9:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 12:49 [Bitcoin-development] New side channel attack that can recover Bitcoin keys Mike Hearn
2014-03-05 12:56 ` Pieter Wuille
2014-03-05 13:18   ` Jean-Paul Kogelman
2014-03-05 14:04     ` Pieter Wuille
2014-03-05 16:21 ` Kevin
2014-03-05 19:39   ` Peter Todd
2014-03-05 19:51     ` Gregory Maxwell
2014-03-05 20:32       ` Peter Todd
2014-03-05 20:54         ` Gregory Maxwell
2014-03-12  9:44           ` Peter Todd [this message]
2014-03-05 22:17     ` James Hartig
2014-03-05 22:26       ` Eric Lombrozo
2014-03-06  7:02     ` Odinn Cyberguerrilla
2014-03-08 19:34   ` Luke-Jr
2014-03-09  1:57     ` Gregory Maxwell
2014-03-05 21:31 ` Eric Lombrozo
2014-03-05 21:44   ` Gregory Maxwell
2014-03-05 22:14     ` Eric Lombrozo
2014-03-05 22:25       ` Gregory Maxwell
2014-03-06  8:38         ` Mike Hearn
2014-03-06 10:00           ` Natanael
2014-03-25 13:39             ` Troy Benjegerdes
2014-03-25 13:50               ` Gavin Andresen
2014-03-08 19:29           ` Gustav Simonsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140312094424.GD15281@savin \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gmaxwell@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox