public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Mike Caldwell <mcaldwell@swipeclock.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	"timo.hanke@web.de" <timo.hanke@web.de>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Date: Thu, 25 Apr 2013 16:31:16 +0200	[thread overview]
Message-ID: <CANEZrP0FS5CZaqEEwCZM-nfPB9D2TfC_moX3BE+TEnfWtc=aOg@mail.gmail.com> (raw)
In-Reply-To: <FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>

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

On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell <mcaldwell@swipeclock.com>wrote:

> I am not sure if my replies hit the list. If not, can anyone who sees this
> help?
>
> In the past, I have pre signed (with PGP) large batches of Bitcoin
> addresses for distribution on my server. This way, even in the event of
> compromise, there is no way someone could substitute an address of their
> own and have it have the same characteristics as other addresses I have
> signed.  The same general concept could be used to keep signing keys off
> the web server.
>
> Mike
>

I didn't see your other replies but got this one.

The assumption you made by doing that is that people can obtain your PGP
key. This leads to the question of how someone knows what your key is or
that you signed the list in the first place. The most obvious way is to go
to https://www.casascius.com/ and click "My PGP key" -> but we already
failed at this point if your web server was hacked. I'd have to learn about
your cryptographic identity via some other secure channel, but usually that
doesn't exist.

Being able to survive web server hacks is intuitively attractive because
web servers tend to be so insecure. But unfortunately there doesn't seem to
be any good way to do this with todays infrastructure because for most
businesses, their website *is* their identity, and if a hacker controls
that they it's very hard for anyone (including CAs) to know that something
has gone wrong.

I think there are some simple mitigations we can use in the short term.

One is that wallets could count how many times you paid to addresses signed
by a particular cert. If you're a repeat customer and your wallet says "You
have never paid this recipient before" instead of "You have paid this
recipient 4 times" then you might be suspicious. Someone pointed out to me
that the current payment protocol has nothing to say on phishing using
confusible domains - this could help with that too, and it's easy to
implement. Of course it means you get reset whenever your certificate
expires and has to be renewed, and crying wolf is often worse than doing
nothing at all. So that's an issue.

With time there might be more complex solutions available, like extensions
to X.509/CA infrastructure (if bitcoin stays growing and popular). Also,
alternative PKIs like DNSSEC or the ePassport PKI might be useful. In your
case Mike you aren't really a company, you're trading under your own name,
so signing the key list under your legal identity is really the best
solution. It's just not easily available right now.

[-- Attachment #2: Type: text/html, Size: 3308 bytes --]

  parent reply	other threads:[~2013-04-25 14:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
2013-04-25  9:58 ` [Bitcoin-development] Cold Signing Payment Requests Timo Hanke
2013-04-25 10:05   ` Mike Hearn
2013-04-25 10:28     ` Timo Hanke
2013-04-25 10:45       ` Mike Hearn
2013-04-25 10:52         ` Mike Hearn
2013-04-25 11:55         ` Timo Hanke
     [not found]         ` <FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
2013-04-25 14:31           ` Mike Hearn [this message]
2013-04-25 19:12             ` Jeremy Spilman
2013-04-26  1:07               ` Gavin Andresen
2013-04-28 18:03                 ` Timo Hanke
2013-04-29 18:40                   ` Jeremy Spilman
2013-04-30  9:17                     ` Mike Hearn
2013-04-30 11:32                       ` Jouke Hofman
2013-04-30 13:14                         ` Gavin Andresen
2013-04-30 17:17                           ` Jeremy Spilman
2013-05-06 21:29                             ` Peter Todd
2013-04-24 23:01 Jeremy Spilman
2013-04-24 23:07 ` Alan Reiner
2013-04-25  9:08   ` Mike Hearn

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='CANEZrP0FS5CZaqEEwCZM-nfPB9D2TfC_moX3BE+TEnfWtc=aOg@mail.gmail.com' \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mcaldwell@swipeclock.com \
    --cc=timo.hanke@web.de \
    /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