Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Are there any evidence (other than not being cracked so far) that the Bitcoin protocol is secure? "How secure" is it?

(I realize that this might not qualify as a meaningful question - feel free to edit if you can improve it. Also, if you liked this question, you might like the Bitcoin Proposal.)

share|improve this question
    
Now that Bitcoin SE is open, should this question be moved there? –  ripper234 Jan 2 '12 at 7:39
add comment

3 Answers 3

up vote 21 down vote accepted

There are several uses of cryptographic algorithms in the protocol.

Accounts/Transactions

To move money from one account to another, you need to collect some data (the previous transaction(s) which got you the money, the target account, the amount you want to transfer) and sign them, using the private key which belongs to your account.

For this signature Bitcoin uses the ECDSA algorithm.

If I can fake your signature, I can also steal your money.

The (public) addresses of the accounts are given as address = version || hash || checksum, where version = 0 (one byte), hash = RIPEMD-160(SHA-256(public-key)) and checksum = first 4 bytes of SHA-256(SHA-256(version || hash)). (The checksum mainly protects against transmission errors.)

If I can somehow generate a private key whose corresponding public key has the same SHA-256 hash as your one, it will have the same address, and I can steal your money. If I can create a fitting private key for your public key, this is also possible.

For now, there is no known attack at the ECDSA algorithm (and I think even with second-preimage attacks at SHA-2 to find a second public key with same hash, you would need an attack at ECDSA to get a useful private key).

It is much easier for now to use a trojan or such to steal the actual private key of the owner. (But this would be off-topic here.)

The Block chain

For a transaction to be deemed valid, it has to be included in the block chain, e.g. in one of the blocks consisting this chain.

To create this block, a miner uses a Merkle tree of hashes, which refer the individual transactions included in this block, the previous block, and some other data. This tree uses SHA-256, too.

A block is considered valid (e.g. other peers will accept it, and build their own blocks on it) if the hash of the header is lower than some number (the "target"). This can be reached by manipulating one part of the block, the nonce value, calculating the hash, and repeating until one is lucky hitting the right nonce to make this block valid.

If there are several valid blocks running around (which are not descendants of each other), "good" miners will usually build on the one with the longest chain.

So, how could we cheat here?

If we can break SHA-2, e.g. by finding a faster way to get the right nonce than trying many of them, we can generate the blocks faster than everyone else. This would mean that we will get all of the mined coins, at first. Having a monopole, we can also effectively decide which transactions to include and which ones not (this could be a denial-of-service for competitors who want to transmit money).

I'm not sure if we could in fact include bogus transactions this way (or by other SHA-2 breaks means) in our Merkle tree - I think the receivers of a blocks should still check if its transactions have actually a valid signature.

For now, no such break of SHA-2 is known.

share|improve this answer
1  
SHA-265 should be SHA-256, I guess. And is it really RIPEMD-160(SHA-256(public-key))+SHA-256(SHA-256(public-key)) with one RIPEMD-160 and three SHA-256? Is + addition, concatenation, or XOR ? –  fgrieu Aug 25 '11 at 7:34
1  
Good catch. I meant concatenation, but it shows that I misread the specification here - the second+third SHA-265 are applied on the output of RIPEMD-160, not on the original key, and one will only take the first four bytes of the result. (I'll update this.) –  Paŭlo Ebermann Aug 25 '11 at 11:43
    
The cascade RIPEMD-160(SHA-256(..)) seems adequate. Using two hashes to build a checksum is strange, but of course this is not a security issue. –  fgrieu Aug 25 '11 at 12:24
add comment

Most of what the bitcoin system does consists of using well-known algorithms for their intended purposes. It is unlikely that there will be a fundamental or algorithmic problem in these parts of the system.

There may be a software bug in the reference client, of course. There once was such a bug -- an overflow bug that allowed people to create transactions that spent absurd numbers of bitcoins, effectively creating them without limits. Once this was detected, a new client was deployed and the corrupt blocks were rejected, effectively undoing all transactions after the first buggy transaction.

While this fixed the problem, it does point out one weakness: software bugs could result in large sections of the block chain being 'undone' as if those transactions never occurred. One workaround to this is to store all transactions that sent coins to you. If they're ever undone, you can then resubmit them. Assuming the person sending the coins to you didn't intend a double-spend attack, the transactions should still be valid. So that should mitigate the risk, assuming the person exploiting the bug wasn't also trying to specifically double-spend coins to you and someone else.

The bitcoin system does do one thing in a very fundamentally unique way, that is the way it is determined which blocks are part of the official public hash chain. This does have some known weaknesses, such as the 51% attack which allows someone who controls more than half the hashing power in the network to launch double-spending attacks or deny any transactions he wishes.

It may, of course, also have completely unknown attacks. It's pretty hard to assess that risk.

share|improve this answer
add comment

There are a number of known attacks that can occur right at the point of block formation. The most recent one, transaction malleability, wasn't really the reason for Mt Gox's demise, but it surely created some problems (and for the most part has been fixed). Unfortunately there is a theoretical, but pretty convincing theory, about what has been called cartel or selfish mining attack, that works with much less than 51% of the hashing power. Clearly switching the 'proof of work' can perhaps subvert the attacker, but that is not built into the code. Currently there are no 'parachutes' inside of bitcoin in case these attacks are made.

share|improve this answer
    
In fact malleability is not an "attack" in the sense of causing any cryptographic breaks. Software which was not written with malleability in mind recognized malleated transactions as double-spends, so the presence of a malleating node caused some confusion and denial-of-service. Mt. Gox's problems were independent of malleability. I have a writeup describing the situation (before Gox's insolvency became known) here: download.wpsoftware.net/bitcoin/malleability-faq.pdf –  Andrew Poelstra Mar 21 at 16:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.