From: Adam Back <adam@cypherspace•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
Date: Tue, 7 May 2013 13:07:40 +0200 [thread overview]
Message-ID: <20130507110740.GA10449@netbook.cypherspace.org> (raw)
In-Reply-To: <CANEZrP1unq_36p0_VJ6CnHof2Sxb4B8go3BK6tPzEMbSLQBBtg@mail.gmail.com>
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
next prev parent reply other threads:[~2013-05-07 11:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20 ` Jeff Garzik
2013-05-06 16:34 ` Mike Hearn
2013-05-06 16:37 ` Peter Todd
2013-05-06 16:47 ` Mike Hearn
2013-05-06 17:19 ` Peter Todd
2013-05-06 17:25 ` Jeff Garzik
2013-05-06 17:42 ` Gregory Maxwell
2013-05-06 17:53 ` Peter Todd
2013-05-06 18:01 ` Gregory Maxwell
2013-05-06 18:19 ` Peter Todd
2013-05-06 18:32 ` Adam Back
2013-05-06 19:08 ` Peter Todd
2013-05-06 19:50 ` Adam Back
2013-05-06 20:43 ` Peter Todd
2013-05-06 23:44 ` Peter Todd
2013-05-07 9:00 ` Mike Hearn
2013-05-09 0:57 ` John Dillon
2013-05-06 18:04 ` Adam Back
2013-05-06 18:25 ` Gregory Maxwell
2013-05-06 22:51 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13 ` Gregory Maxwell
2013-05-07 4:48 ` Petr Praus
2013-05-07 21:07 ` Matt Corallo
2013-05-07 9:17 ` Mike Hearn
2013-05-07 11:07 ` Adam Back [this message]
2013-05-07 12:04 ` 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=20130507110740.GA10449@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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