Theoretical Scenarios of Core Dev Team Compromising Bitcoin

[josiahgarber]

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]

Start by checking out http://gitian.org
And 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]

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]

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]

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]

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.

[corebob]

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/conformal

The 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]

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.

[cr1776]

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]

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]

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/conformal

The 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]

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/conformal

The 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]

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.

[BurtW]

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.

[Qoheleth]

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.

[behindtext]

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]

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/conformal

The 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 

[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.

[kjj]

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?

Code: (key.cpp)

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

[behindtext]

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?

Code: (key.cpp)

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

if 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