[Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

Adam Back adam at cypherspace.org
Tue May 7 11:07:40 UTC 2013


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




More information about the bitcoin-dev mailing list