Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
I really beg to differ on this one. If you're an Ubuntu user who is behind only one distro (quantal) you're stuck on version 0.6.2 with no updates since 2012 (yes, that means on May 15th you'll be lost). For those still on Debian Squeeze (ie barely out of date), you get 0.3.24! Yes, 0.3.24 including every issue we've fixed since (https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures) and bitcoin is not available in wheezy. Those are just the two I bothered to look up, but, additionally, nearly every distro I know of links bitcoin against libdb5.1 (latest Ubuntu, Arch, etc) which means wallets run once with those packages will never be usable an "official" Bitcoin build ever again. I can't necessarily fault them for this since 4.8 is quite old, but its certainly not "doing mostly a pretty good job" Matt On Mon, 2013-05-06 at 23:48 -0500, Petr Praus wrote: > I think it's worth noting that quite a large portion of Linux users > probably get the mainline Bitcoin client from the packages. I think > Bitcoin package maintainers are doing mostly a pretty good job :) -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
> 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 Yes, it would be nice to have SSL but that requires finding alternative file hosting. > I guess its the least of the concerns but I believe Damgards is better. Unfortunately we don't have any choice in what to use. There's no way on Android to change the signing key after deployment, so we can either split the existing key or do nothing. There is a quorum-of-developers signing system using gitian and reproducible builds, but as noted by Gregory, the problem is that people don't check the signatures (even ignoring the web of trust aspect which raises the complexity much higher). This sort of thing works best when combined with an auto update engine or other kind of software distribution platform. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
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 -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
> Seems like the website redesign managed to hide the signatures pretty > good. They're in the release announcements in any case, but that > should be fixed. Even when they were prominently placed, practically > no one checked them. As a result they are mostly security theater 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. The signatures are useful for verifying the integrity of our mirrors. The verify-bitcoin.sh script does this. Unfortunately it's not good enough. I run it daily and from time to time it fails and says the hashes don't match, which I assume means we may have a corrupted mirror somewhere or the script itself is flaky. But the output is too sparse to investigate. I modified it to print more data and am waiting for it to fail again, unfortunately, I can't make it fail on demand. Anyway. I've been thinking about this problem a fair bit. It's easier to solve on some platforms than on others. On Android, the Bitcoin Wallet app is protected by a few things: 1) Once installed, the device will only accept updates that were signed by the same key as the original. So the auto update mechanism is secure (including I believe against an attack by the store operator, which is usually Google). 2) It appears at the top of the Play Store when you search for "Bitcoin". Unfortunately the Store is somewhat gameable at the moment, but that's getting fixed and more importantly over the long term, app store operators have the right incentives to crack down on gaming of search results. This combined with the reviews, ratings and social recommendations of real users provides a series of signals that are hard for an attacker/phisher to replicate. You can say to someone "Go get the app called Bitcoin Wallet by Andreas Schildbach from the store" and the chances they get the right thing, signed by the right person, are very high. 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. 4) The OS sandboxes apps from each other. That sandbox doesn't have a great track record outside of Google-controlled devices because OEMs and carriers don't have the right incentives to actually ship OS security updates, but it's still a lot better than nothing and hopefully over time these issues will get resolved. All together this means users on phones and tablets have a somewhat convincing security solution that fights against phishing and malware. On MacOS X the binaries are signed under the legal identity of the Bitcoin Foundation. Jim has started signing MultiBit with his legal identity too (this is required to make Gatekeeper happy on recent versions of MacOS). Unsigned binaries will not run by default on 10.8, but anyone with a developer certificate can sign any binary. So whilst a hacked bitcoin.org or a phishing site can distribute malware, at least on OS X 10.8 it will require the user to override the built in security systems, or it will require the malware author to steal a developer certificate - probably not very hard but definitely raises the bar. On Windows antivirus companies operate what is effectively a form of binary whitelisting. The new MultiBit release triggered AV warnings for a few days until it got enough reputation to stop triggering. The goal of these systems is to fight polymorphic viruses and they understand code signing. If you reliably sign your binaries, positive binary reputation accrues to your signing identity and not the binary itself, so you can release updates and not get harassed. 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. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing lis
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
I think it's worth noting that quite a large portion of Linux users probably get the mainline Bitcoin client from the packages. I think Bitcoin package maintainers are doing mostly a pretty good job :) On 6 May 2013 18:13, Gregory Maxwell wrote: > On Mon, May 6, 2013 at 3:51 PM, Adam Back wrote: > > Maybe I could hack a pool to co-opt it into my netsplit and do the work > for > > me, or segment enough of the network to have some miners in it, and they > do > > the work. > > Or you can just let it mine honestly and take the Bitcoins. This is > fast (doesn't require weeks of them somehow not noticing that they're > isolated), and yields the values I listed as 'costs' if you would have > otherwise been able to use it to mine the difficulty down to 1. Cost > is just as much foregone income from the alternative attack you could > have done instead. > > > nor even topological, nor even > > particularly long-lived. > > At least for attacks that drive the difficulty down it does. > > If you want to talk about abusing a pool or creating a partition in > order to create short reorgs— I agree, those don't have to be long > lived and you can find many messages where I've written on that > subject. > > It's inconsiderate to propose one attack and when I respond to it > changing the attack out from under me. :( I would have responded > entirely differently if you'd proposed people segmenting the network > and creating short reorgs instead of mining the difficulty down. > > > Do you know if there is any downwards limit on difficulty? I know it > takes > > going slow for a long and noticeable time, but I am just curious on the > > theoretical limit. > > Every 2016 blocks can at most lower the difficulty by a factor of 4, > thats where the log4 (number of 2016 groups needed) and 4^n (factor in > cost reduction for each group) come from in the formulas I gave > previously. > > > I dont see the signatures. > > > http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download > > The signatures can't be inside the tarball because they sign the tarball. > > Seems like the website redesign managed to hide the signatures pretty > good. They're in the release announcements in any case, but that > should be fixed. Even when they were prominently placed, practically > no one checked them. As a result they are mostly security theater in > practice :(, — so— unfortunately, is SSL: there are many CA's who will > give anyone a cert with your name on it who can give them a couple > hundred bucks and MITM HTTP (not HTTPS!) between the CA's > authentication server and your webserver. Bitcoin.org is hosted by > github, even if it had SSL and even if the CA infrastructure weren't a > joke, the number of ways to compromise that hosting enviroment would > IMO make SSL mostly a false sense of security. > > The gpg signatures and gitian downloader signatures provide good > security if actually used, solving the "getting people to use them" > problem is an open question. > > And I agree, this stuff is a bigger issue than many other things like > mining the difficulty down. > > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
On Mon, May 6, 2013 at 3:51 PM, Adam Back wrote: > Maybe I could hack a pool to co-opt it into my netsplit and do the work for > me, or segment enough of the network to have some miners in it, and they do > the work. Or you can just let it mine honestly and take the Bitcoins. This is fast (doesn't require weeks of them somehow not noticing that they're isolated), and yields the values I listed as 'costs' if you would have otherwise been able to use it to mine the difficulty down to 1. Cost is just as much foregone income from the alternative attack you could have done instead. > nor even topological, nor even > particularly long-lived. At least for attacks that drive the difficulty down it does. If you want to talk about abusing a pool or creating a partition in order to create short reorgs— I agree, those don't have to be long lived and you can find many messages where I've written on that subject. It's inconsiderate to propose one attack and when I respond to it changing the attack out from under me. :( I would have responded entirely differently if you'd proposed people segmenting the network and creating short reorgs instead of mining the difficulty down. > Do you know if there is any downwards limit on difficulty? I know it takes > going slow for a long and noticeable time, but I am just curious on the > theoretical limit. Every 2016 blocks can at most lower the difficulty by a factor of 4, thats where the log4 (number of 2016 groups needed) and 4^n (factor in cost reduction for each group) come from in the formulas I gave previously. > I dont see the signatures. http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download The signatures can't be inside the tarball because they sign the tarball. Seems like the website redesign managed to hide the signatures pretty good. They're in the release announcements in any case, but that should be fixed. Even when they were prominently placed, practically no one checked them. As a result they are mostly security theater in practice :(, — so— unfortunately, is SSL: there are many CA's who will give anyone a cert with your name on it who can give them a couple hundred bucks and MITM HTTP (not HTTPS!) between the CA's authentication server and your webserver. Bitcoin.org is hosted by github, even if it had SSL and even if the CA infrastructure weren't a joke, the number of ways to compromise that hosting enviroment would IMO make SSL mostly a false sense of security. The gpg signatures and gitian downloader signatures provide good security if actually used, solving the "getting people to use them" problem is an open question. And I agree, this stuff is a bigger issue than many other things like mining the difficulty down. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
