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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZfkO-0004up-JC for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 11:07:52 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.44 as permitted sender) client-ip=74.125.83.44; envelope-from=adam.back@gmail.com; helo=mail-ee0-f44.google.com; Received: from mail-ee0-f44.google.com ([74.125.83.44]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UZfkN-0007wb-Ab for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 11:07:52 +0000 Received: by mail-ee0-f44.google.com with SMTP id t10so241571eei.3 for ; Tue, 07 May 2013 04:07:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-hashcash:x-hashcash:x-hashcash:x-hashcash; bh=xME/4lTz+NoxxjOGXAs07r8Wm7HJ+nt8VeY16yLjTCM=; b=iWyxIUMF/hM4sZclHHeF58tu1BG9ZPVJZesMAL9pRHEuF6ygOd4ZdNACRas+mMIf66 1FTvPiBjMJMjGyFZp+LhXSCc5vDcNFPi3V1i5m95btfXRxLIRneov6/aXzI9JYx3mvWy LODR3HmYxG+wWJ4EJKXFq7GSOr6zhPeSKcZBACVcIX9/nJ1VaJwLXHAAJ83YCIt+5Her BDm9U5c3frz+nfRRP7SI6+cRAxt215kjVfTYmUm/yOwX/gppuFEaThJpEknp3hC7gFEZ BQzY2kttZmzLOd9N7D88DMASwQZ6DJA6x1/uDAAJ4hMNmuZQmCzVH9tpZnhyCEVzw8QM VpCg== X-Received: by 10.14.172.197 with SMTP id t45mr4219854eel.37.1367924864893; Tue, 07 May 2013 04:07:44 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id bp51sm36710313eeb.5.2013.05.07.04.07.43 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 04:07:44 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id C30D12E0619; Tue, 7 May 2013 13:07:41 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Tue, 7 May 2013 13:07:40 +0200 Date: Tue, 7 May 2013 13:07:40 +0200 From: Adam Back To: Mike Hearn Message-ID: <20130507110740.GA10449@netbook.cypherspace.org> References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> <20130506180418.GA3797@netbook.cypherspace.org> <20130506225146.GA6657@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:130507:mike@plan99.net::KVZv1xB65avanZ59:002f34 X-Hashcash: 1:20:130507:gmaxwell@gmail.com::yeke8Q8S3O4Z1l1y:0000000000000000000 0000000000000000000000001AXv X-Hashcash: 1:20:130507:bitcoin-development@lists.sourceforge.net::k9Lzj1CaoAMP+ zLb:000000000000000000001fEv X-Hashcash: 1:20:130507:adam@cypherspace.org::hn+wbq+aQaSaONqa:00000000000000000 0000000000000000000000000dwt X-Spam-Score: -1.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 (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information X-Headers-End: 1UZfkN-0007wb-Ab Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) 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: Tue, 07 May 2013 11:07:52 -0000 Well its a bit more hopeful than that :) On Tue, May 07, 2013 at 11:17:17AM +0200, Mike Hearn wrote: >> Seems like the website redesign managed to hide the signatures pretty >> good. > >Security theater indeed - even if people check the signatures, where >did they get the identities of the signers/developers from? Oh right, >the same website that served them the binary. If they are PGP signatures, they can check the PGP WoT; its not that hopeless some us eg have our keys in Ross Anderson's PGP Global Trust Register, a PGP and CA key fingerprint book. http://www.cl.cam.ac.uk/research/security/Trust-Register/index.html Probably most of the CA keys expired, but many of the PGP keys didnt. So to the extent that those people take PGP WoT seriously, and the main developers names and email addresses are known and scattered around hundreds of web mailing list archives etc there is some trust anchor. And even without a PGP WoT connection, if the website had SSL enabled, they can trust the binaries its sending to the extent that it is securely maintained, and to the limit of the CA security weakest link (modulo sub-CA malfeasance, and all the certification domain ownership laxness you or someone mentioned in another mail). That there are limitations in it doesnt mean you should not avail of the (moderately crummy) state of the art! And that is tied back to the domain itself hwich is very mnemonic and referenced widely in print, tv, websites etc. >3) I never got around to trying it, but the threshold RSA library I >obtained is theoretically capable of splitting the RSA keys used to >protect updates. I've talked to Andreas about this a little bit, and I >think he's open to the idea of splitting the Android signing key so it >requires a quorum of developers to release an update. This is Shoup >threshold RSA, not a Shamir secret share of the key bits. I guess its the least of the concerns but I believe Damgards is better. Another possibility is threshold DSA (which is built using Damgards Paillier additively homomorphic cryptosystem extension) and discrete log schemes are easier to setup with zero-trust. Other simpler discrete log signatures ie Schnorr are much easier to work with (threshold DSA is a mite complicated), but NIST tweaked Schnorr to create DSA, and the rest is history. The trust n-1 of n is good enough for signatures because anyway that is above the assurance of the signature. >On Linux we're actually the most exposed. It has by far the worst >situation of all - a culture in which man-in-the-middle attacks by >package maintainers are not only common but actively encouraged. The >Debian OpenSSL fiasco showed the critical danger this can place people >in. I believe we should have a health warning on the website telling >people to only get binaries from us unless they are on a distribution >that we are verifying doesn't apply any patches. But that's a ton of >work and I long ago burned out on the politics of Linux software >distribution. Well before I tried the download I had downloaded and compiled a few versions from git. But to get a stable and experience the non-programmer view I did first try "yum install bitcoin" and then "yum whatprovides bitcoin" on fedora 18 with +rpmfusion and there appeared to be no package! I didnt find the signature on the source either or I would've checked. Other ways you could get usefully get assurance of the source is multiple people signing the release, with an asserted meaning being - I checked the patches that went into this and I see nothing malicious. It might help if one or more of the signer were pseudonymous even (eg Satoshi if willing) because you cant coerce legally, nor physically a pseudonymous person because you cant find them. Its a lot of pressure on open secure coding process when there is $1bil value protected by the integrity of the code. (It seems the most likely avenue to bypass that maybe simply the attacker to just become a committer and slip the 0-day past the review process. There were in the past modest-impact and plausible looking mistakes in PGP discovered after sometime.) Adam