josiahgarber (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 82
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 01:58:40 PM |
|
What are some possible scenarios of how the core dev team could intentionally or unintentionally compromise Bitcoin?
Just curious to know possible scenarios where the core dev team would be able to compromise the integrity of Bitcoin.
It's not that I don't trust the team, I do. I just want to learn more about Bitcoin's potential vulnerabilities.
|
|
|
|
cr1776
Legendary
Offline
Activity: 4144
Merit: 1307
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 02:33:40 PM |
|
Start by checking out http://gitian.orgAnd git :-) What are some possible scenarios of how the core dev team could intentionally or unintentionally compromise Bitcoin?
Just curious to know possible scenarios where the core dev team would be able to compromise the integrity of Bitcoin.
It's not that I don't trust the team, I do. I just want to learn more about Bitcoin's potential vulnerabilities.
|
|
|
|
corebob
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 02:54:14 PM |
|
I noticed that the btcd daemon implements its own faster version of SHA256
Even if I have no reason not to believe so, my first though was, could it have a backdoor?
|
|
|
|
drawingthesun
Legendary
Offline
Activity: 1176
Merit: 1015
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 03:05:07 PM |
|
I noticed that the btcd daemon implements its own faster version of SHA256
Even if I have no reason not to believe so, my first though was, could it have a backdoor?
Can you put the code for the respective SHA implementations side by side to see what the difference is?
|
|
|
|
corebob
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 03:37:29 PM |
|
I noticed that the btcd daemon implements its own faster version of SHA256
Even if I have no reason not to believe so, my first though was, could it have a backdoor?
Can you put the code for the respective SHA implementations side by side to see what the difference is? I'll see if I can make a diff out of it and post it here when I get the time
|
|
|
|
Qoheleth
Legendary
Offline
Activity: 960
Merit: 1028
Spurn wild goose chases. Seek that which endures.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 03:50:11 PM |
|
The most obvious attack is putting in a stealth bug that poisons key generation. If there's some secret data that lets you figure out people's private keys with much higher likelihood than brute force, well, those "lost wallets" aren't so lost anymore, now are they? I noticed that the btcd daemon implements its own faster version of SHA256
Even if I have no reason not to believe so, my first though was, could it have a backdoor?
It wouldn't do them any good, if it did. Mining is done on FPGAs these days; to the extent that the bitcoind SHA256 differed from the "canonical" one, we would already be seeing chainsplits ten times as ugly as the BerkeleyDB debacle back in March.
|
If there is something that will make Bitcoin succeed, it is growth of utility - greater quantity and variety of goods and services offered for BTC. If there is something that will make Bitcoin fail, it is the prevalence of users convinced that BTC is a magic box that will turn them into millionaires, and of the con-artists who have followed them here to devour them.
|
|
|
corebob
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:01:08 PM |
|
The most obvious attack is putting in a stealth bug that poisons key generation. If there's some secret data that lets you figure out people's private keys with much higher likelihood than brute force, well, those "lost wallets" aren't so lost anymore, now are they? I noticed that the btcd daemon implements its own faster version of SHA256
Even if I have no reason not to believe so, my first though was, could it have a backdoor?
It wouldn't do them any good, if it did. Mining is done on FPGAs these days; to the extent that the bitcoind SHA256 differed from the "canonical" one, we would already be seeing chainsplits ten times as ugly as the BerkeleyDB debacle back in March. Sounds good enough. Just for reference: Code for the fastsha256 can be found here https://github.com/conformalThe original that comes with Go http://golang.org/src/pkg/crypto/sha256/They are quite different so comparing them won't be that easy from just looking at the code. The fastsha256 also appears to be using inline assembly for amd64
|
|
|
|
BurtW
Legendary
Offline
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:13:14 PM |
|
The single largest threat to the survival of Bitcoin today is the overt and covert attacks on the fungibility of Bitcoin. If Bitcoin is not fungible then it is not a form of money. It becomes a collectible with all the problems inherent in a collectibles market:
The need for an authority or authorities to tell you the value of each Bitcoin based on criteria set by outside influences with their own political, economic and social engineering agendas.
The need for and infrastructure to check with this central authority, or worse yet multiple authorities, every single time you do a transaction - so you don't get stuck with less than desirable coins. Or even worse, the need to check in with a very complex market to value the coins on a “sliding scale”, if presented with less than desirable coins, so you can accept them at a discounted value.
Fragmentation of the market for Bitcoins: a white market for the coins deemed clean by the authority or authorities and a black market for the less desirable, listed coins.
The core developers could consciously or inadvertently either maintain or destroy the fungible property of Bitcoin.
Help: implement BIP32 as soon as possible in all clients in order to allow all periodic payments to be done in a fungibility supportive way.
Hinder: anything in the clients that helps in the formation, propagation or checking of any kind, color or flavor of lists of Bitcoins.
|
Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
|
|
|
cr1776
Legendary
Offline
Activity: 4144
Merit: 1307
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 11:50:44 PM |
|
I agree. A stratification of the market would be detrimental to bitcoin in general. And Subtle bugs like the android rng bug that weaken private keys that go undetected would be problematic. The single largest threat to the survival of Bitcoin today is the overt and covert attacks on the fungibility of Bitcoin. If Bitcoin is not fungible then it is not a form of money. It becomes a collectible with all the problems inherent in a collectibles market:
The need for an authority or authorities to tell you the value of each Bitcoin based on criteria set by outside influences with their own political, economic and social engineering agendas.
The need for and infrastructure to check with this central authority, or worse yet multiple authorities, every single time you do a transaction - so you don't get stuck with less than desirable coins. Or even worse, the need to check in with a very complex market to value the coins on a “sliding scale”, if presented with less than desirable coins, so you can accept them at a discounted value.
Fragmentation of the market for Bitcoins: a white market for the coins deemed clean by the authority or authorities and a black market for the less desirable, listed coins.
The core developers could consciously or inadvertently either maintain or destroy the fungible property of Bitcoin.
Help: implement BIP32 as soon as possible in all clients in order to allow all periodic payments to be done in a fungibility supportive way.
Hinder: anything in the clients that helps in the formation, propagation or checking of any kind, color or flavor of lists of Bitcoins.
|
|
|
|
genjix
Legendary
Offline
Activity: 1232
Merit: 1076
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 21, 2013, 10:41:17 AM |
|
It's not only bugs but the values of the programmers and how they mold the software. For instance there are deep issues in the protocol where the decision is not always clear (and the community is ignorant of them). If you work for a corporation, your choices are going to be different to the guy running black markets and doing p2p trades. You just both value different feature sets and the software optimised in a different way. From this article: https://letstalkbitcoin.com/the-regulation-of-bitcoin/"If development is too centralized, with a small core infrastructure, then businesses will put real pressure to have features that destroy the integrity of the Bitcoin network. The excuse will be to protect themselves from liability. Self-censorship. And what they demand does not have to be protocol changes. They will demand features in the software they use. Software which remains compatible with the network, but works against the interests of individuals, small businesses and the black market. The possible malicious scenarios are endless. Stuff like p2p blacklists to create a ‘legitimate’ walled garden, or tracking technologies like large databases of IP addresses to triangulate where transactions came from. At the other end of the spectrum, is putting development effort into diversifying the ecosystem to protect against censorship and proxy relay nodes, anonymizing mixers, small privacy tweaks and other technologies. That’s where developers who believe in Bitcoin should devote time to. Corporations are powerful enough. To developers: serve your community."
|
|
|
|
behindtext
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 22, 2013, 02:56:46 AM |
|
The most obvious attack is putting in a stealth bug that poisons key generation. If there's some secret data that lets you figure out people's private keys with much higher likelihood than brute force, well, those "lost wallets" aren't so lost anymore, now are they? I noticed that the btcd daemon implements its own faster version of SHA256
Even if I have no reason not to believe so, my first though was, could it have a backdoor?
It wouldn't do them any good, if it did. Mining is done on FPGAs these days; to the extent that the bitcoind SHA256 differed from the "canonical" one, we would already be seeing chainsplits ten times as ugly as the BerkeleyDB debacle back in March. Sounds good enough. Just for reference: Code for the fastsha256 can be found here https://github.com/conformalThe original that comes with Go http://golang.org/src/pkg/crypto/sha256/They are quite different so comparing them won't be that easy from just looking at the code. The fastsha256 also appears to be using inline assembly for amd64 yes, fastsha256 is indeed done in go assembly. it takes ~17,000 ns to run vs ~40,000 for go crypto package's sha256. sipa's libsecp256k1 uses the same method - do it in assembly. we just did it to be faster. at the moment, sha256 is not a serious bottleneck. if you feel strongly enough about not using assembly, we could have it use the standard crypto by default.
|
|
|
|
behindtext
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 22, 2013, 05:38:49 PM |
|
I noticed that the btcd daemon implements its own faster version of SHA256 Even if I have no reason not to believe so, my first though was, could it have a backdoor? ... Sounds good enough. Just for reference: Code for the fastsha256 can be found here https://github.com/conformalThe original that comes with Go http://golang.org/src/pkg/crypto/sha256/They are quite different so comparing them won't be that easy from just looking at the code. The fastsha256 also appears to be using inline assembly for amd64 yes, fastsha256 is indeed done in go assembly. it takes ~17,000 ns to run vs ~40,000 for go crypto package's sha256. sipa's libsecp256k1 uses the same method - do it in assembly. we just did it to be faster. at the moment, sha256 is not a serious bottleneck. if you feel strongly enough about not using assembly, we could have it use the standard crypto by default. i just checked with my devs and this go asm is actually from one of google's golang devs, Joel Sing. this code will be in release 1.3 of golang, so soon enough all go users will have this asm for sha256. since it's going to be in go 1.3, we're leaving it in until go 1.3 is released in the near-ish future.
|
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1099
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 22, 2013, 07:15:10 PM |
|
The most obvious attack is putting in a stealth bug that poisons key generation
That's not very stealthy. You would immediately notice money not going where it is supposed to go. And magic constants are rare in the bitcoin source code, so "send money to XXX address" would stick out as obvious. You would have to be far more subtle than that.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
BurtW
Legendary
Offline
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 22, 2013, 07:25:19 PM |
|
The most obvious attack is putting in a stealth bug that poisons key generation
That's not very stealthy. You would immediately notice money not going where it is supposed to go. And magic constants are rare in the bitcoin source code, so "send money to XXX address" would stick out as obvious. You would have to be far more subtle than that. I think they meant a subtle change to the random number generation which caused a stealth change to the key pair generation allowing someone to more easily crack the keys that get generated.
|
Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
|
|
|
Qoheleth
Legendary
Offline
Activity: 960
Merit: 1028
Spurn wild goose chases. Seek that which endures.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 22, 2013, 08:04:02 PM |
|
The most obvious attack is putting in a stealth bug that poisons key generation
That's not very stealthy. You would immediately notice money not going where it is supposed to go. And magic constants are rare in the bitcoin source code, so "send money to XXX address" would stick out as obvious. You would have to be far more subtle than that. I think they meant a subtle change to the random number generation which caused a stealth change to the key pair generation allowing someone to more easily crack the keys that get generated. Yeah, this. The attack is to poison the code that randomly generates keypairs, so that the private keys are easier to crack in some non-obvious way. Then all you need to do is look around for addresses you have reason to believe are lost/abandoned, crack their private key, and loot the coins stored there.
|
If there is something that will make Bitcoin succeed, it is growth of utility - greater quantity and variety of goods and services offered for BTC. If there is something that will make Bitcoin fail, it is the prevalence of users convinced that BTC is a magic box that will turn them into millionaires, and of the con-artists who have followed them here to devour them.
|
|
|
behindtext
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 22, 2013, 08:40:58 PM |
|
The most obvious attack is putting in a stealth bug that poisons key generation
That's not very stealthy. You would immediately notice money not going where it is supposed to go. And magic constants are rare in the bitcoin source code, so "send money to XXX address" would stick out as obvious. You would have to be far more subtle than that. ++ for an example of subtle PRNG bugs that can lead to crypto being blown, see cryptocat. small, hard-to-detect biases in PRNG can easily lead to weak keypairs.
|
|
|
|
corebob
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 22, 2013, 10:22:34 PM |
|
The most obvious attack is putting in a stealth bug that poisons key generation. If there's some secret data that lets you figure out people's private keys with much higher likelihood than brute force, well, those "lost wallets" aren't so lost anymore, now are they? I noticed that the btcd daemon implements its own faster version of SHA256
Even if I have no reason not to believe so, my first though was, could it have a backdoor?
It wouldn't do them any good, if it did. Mining is done on FPGAs these days; to the extent that the bitcoind SHA256 differed from the "canonical" one, we would already be seeing chainsplits ten times as ugly as the BerkeleyDB debacle back in March. Sounds good enough. Just for reference: Code for the fastsha256 can be found here https://github.com/conformalThe original that comes with Go http://golang.org/src/pkg/crypto/sha256/They are quite different so comparing them won't be that easy from just looking at the code. The fastsha256 also appears to be using inline assembly for amd64 yes, fastsha256 is indeed done in go assembly. it takes ~17,000 ns to run vs ~40,000 for go crypto package's sha256. sipa's libsecp256k1 uses the same method - do it in assembly. we just did it to be faster. at the moment, sha256 is not a serious bottleneck. if you feel strongly enough about not using assembly, we could have it use the standard crypto by default. Not at all. I'm sure assembly can be reviewed just as easily. By the way, is it the assembler that comes with the C compiler (pulled by cgo) that does the actual assembly? edit: I just read your second post regarding this. I guess it will all be taken care of by whatever compiler/assembler compiling go itself. To the extent I am able to consider the quality of your projects, they look really good. Great stuff ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
|
BurtW
Legendary
Offline
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 23, 2013, 01:06:27 AM Last edit: November 23, 2013, 04:52:16 AM by BurtW |
|
As far as any SHA is concerned the implemenation is not really an issue. Every single implementation of any SHA must produce exactly the same results as every other SHA implementation, every single time. If your SHA implementation does not produce exactly the same results as the reference implemenation then it is broken.
|
Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 23, 2013, 01:26:06 AM |
|
The most obvious attack is putting in a stealth bug that poisons key generation
That's not very stealthy. You would immediately notice money not going where it is supposed to go. And magic constants are rare in the bitcoin source code, so "send money to XXX address" would stick out as obvious. You would have to be far more subtle than that. I think they meant a subtle change to the random number generation which caused a stealth change to the key pair generation allowing someone to more easily crack the keys that get generated. Want to see the code that generates new keys? void CKey::MakeNewKey(bool fCompressed) { if (!EC_KEY_generate_key(pkey)) throw key_error("CKey::MakeNewKey() : EC_KEY_generate_key failed"); if (fCompressed) SetCompressedPubKey(); fSet = true; }
Good luck messing that up. Note: EC_KEY_generate_key() is an openssl call
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
behindtext
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 23, 2013, 01:31:08 PM |
|
I think they meant a subtle change to the random number generation which caused a stealth change to the key pair generation allowing someone to more easily crack the keys that get generated.
Want to see the code that generates new keys? void CKey::MakeNewKey(bool fCompressed) { if (!EC_KEY_generate_key(pkey)) throw key_error("CKey::MakeNewKey() : EC_KEY_generate_key failed"); if (fCompressed) SetCompressedPubKey(); fSet = true; }
Good luck messing that up. Note: EC_KEY_generate_key() is an openssl callif there is any funny business with the PRNG, it's on the openssl or OS side. if any of you have had the "pleasure" of looking at the openssl code, you'll know what i mean. for a fun little flashback, have a read about marco's experience with openssl code from 2009 - http://www.peereboom.us/assl/assl/html/openssl.html
|
|
|
|
|