From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UVNCn-0008BK-RL for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 14:31:25 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.46 as permitted sender) client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f46.google.com; Received: from mail-oa0-f46.google.com ([209.85.219.46]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UVNCk-0004d7-2Y for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 14:31:25 +0000 Received: by mail-oa0-f46.google.com with SMTP id k3so2875893oag.5 for ; Thu, 25 Apr 2013 07:31:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.97.168 with SMTP id eb8mr16111229obb.89.1366900276683; Thu, 25 Apr 2013 07:31:16 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Thu, 25 Apr 2013 07:31:16 -0700 (PDT) In-Reply-To: References: <20130425095855.GA30535@crunch> <20130425102853.GA31573@crunch> Date: Thu, 25 Apr 2013 16:31:16 +0200 X-Google-Sender-Auth: wrwYOXmrHsJrQjZmkDfMvWANFNk Message-ID: From: Mike Hearn To: Mike Caldwell Content-Type: multipart/alternative; boundary=047d7b2e41e66f6aea04db304552 X-Spam-Score: -0.5 (/) 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.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UVNCk-0004d7-2Y Cc: Bitcoin Dev , "timo.hanke@web.de" Subject: Re: [Bitcoin-development] Cold Signing Payment Requests 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: Thu, 25 Apr 2013 14:31:26 -0000 --047d7b2e41e66f6aea04db304552 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell 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. --047d7b2e41e66f6aea04db304552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 h= ave signed. =C2=A0The same general concept could be used to keep signing ke= ys off the web server.=C2=A0

Mike

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

The assumptio= n 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 t= he list in the first place. The most obvious way is to go to=C2=A0https://www.casascius.com/=C2=A0and cli= ck "My PGP key" -> but we already failed at this point if your= web server was hacked. I'd have to learn about your cryptographic iden= tity via some other secure channel, but usually that doesn't exist.

Being able to survive web server hacks is i= ntuitively attractive because web servers tend to be so insecure. But unfor= tunately there doesn't seem to be any good way to do this with todays i= nfrastructure because for most businesses, their website is=C2=A0the= ir identity, and if a hacker controls that they it's very hard for anyo= ne (including CAs) to know that something has gone wrong.

I think there are some simple mitigat= ions 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 &q= uot;You have never paid this recipient before" instead of "You ha= ve 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 p= hishing using confusible domains - this could help with that too, and it= 9;s easy to implement. Of course it means you get reset whenever your certi= ficate expires and has to be renewed, and crying wolf is often worse than d= oing nothing at all. So that's an issue.

With time there might be more complex solut= ions available, like extensions to X.509/CA infrastructure (if bitcoin stay= s 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, yo= u're trading under your own name, so signing the key list under your le= gal identity is really the best solution. It's just not easily availabl= e right now.
--047d7b2e41e66f6aea04db304552--