Yes, I was.  I just wanted to point out that this is the most easy way to crack Bitcoin for goverments.


In almost all countries market manipulation is forbidden. It is prohibited in the United States under Section 9(a)(2).

Then why there is no link to the fingerprint in the Bitcoin.org main page? Why is Bitcoin running on http and not on https anyway?
The fingerprint is only accessible through sourceforge.org (SHASUMS.asc) which is also not secured by http.
You see, it's very easy to forge the binary, the public key and the fingerprint.

My own research says that it's quite easy and cheap to hire 5000 virtual IPs and, with some time, manage to be connected to every other Bitcoin node.

IMHO

The best government attack is to legally forbid Bitcoin and force ISPs to block Bitcoin traffic. Then Bitcoin would start a cat and mouse race to obfuscate the protocol data/port and that would hurt Bitcoin and prevent a wider adoption of the system.
This attack probably costs a few hundred USD.

The best private company attack is to earn BTC by market manipulation. This attack probably costs 1M+ USD to control the coin.

The best crybecriminal attack is to exploit vulnerabilities added on purpose to steal BTC from nodes. This attack probably costs 50K - 200K USD and may include bribery to one of the core devs, github or sourceforge.net programmers or ISP workers. Probably the easiest way is by doing a man-in-the-middle attack of Windows binary downloads, since nobody checks fingerprints.

The best gray hat hacker attack is to find ways to DoS the network in order to manipulate the coin price. This attack probably costs 10K - 20K USD.

Right. It seems at a first glance that the signature verification would stop the ACK from being sent.

Still the attack can be executed using a timing attack. It's easy to detect if 100 RSA blocks are being decrypted or just only two. You send another message right after the Bleichenbacher message. If it takes one second to process, then 100 blocks have been decrypted. If it takes 100 msec, then only two blocks have been decrypted.
I'm sure there are still other ways to detect the correct/incorrect PKCS padding and carry the attack.

When a crypto protocol shows many vulnerabilities, then is better to make a pause and re-design carefully from scratch than to start patching.

I recommend you that you first write a technical paper on the crypto protocol, and send it to some researchers for them to analyze. If they say is ok, then go on and implement it. I offer my free advise to read the paper and give it some thought.

Last, there is still another vulnerability in the anonymization logic: If a node X receives a message and immediately sends an ACK then an attacker Z connected to X can detect that X is the receiver of the message.

To deter this attack nodes should continuously send messages at a fixed rate, creating new ones (with no destination) when no new message is received. Other solution is that nodes should be protected with Tor at all times. I will post about this in the bitmessage forum.


Best regards,
 Sergio.

PS: I never meant to say that the idea is bad. Go ahead and improve it!

I think the protocol can be secured but first some things would need to be done:

1. Much better documentation of the inner workings of the message structure / cryptographic functions

This information is missing from the White paper and is crucial to understand the protocol.

2. Find a Security researcher to develop a proven encryption/signature design.

Either you hire it or you find a one that would do it for free but it must be a guy with deep crypto knowledge.

3. Clean up the source code. Refactor and comment. Isolate security critical parts.

It's a bit messy and does not help in understanding the inner workings of the protocol.

4. RSA is not itself the problem. OAEP padding would have been be much better. But hybrid encryption with chaining is a must.

I suggest using the Integrated Encryption Scheme (DLIES or ECIES).

Good luck!

 Sergio.

Completely broken security of Bitmessage...

Check my blog post: http://bitslog.wordpress.com/2012/11/30/bitmessage-completely-broken-crypto/

If  you check https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures you will see that the time a vulnerability is disclosed from the time it is reported is over 6 month. Also note that vulns are fixed very fast, but people do not try to upgrade. I wonder why.

Some time ago I asked some cloud computing companies if they would let me hire a single virtual CPU with 4000 external IPv4 addresses. One of them said "no problem". And it was very cheap indeed.

I'm following Gavin idea of using the current percentages of versions found in http://luke.dashjr.org/programs/bitcoin/files/charts and published in https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures to decide if a vulnerability should be disclosed or not. Gavin has used the 80% rule before. If the number of non-vulnerable nodes is greater than %80, then the vulnerability is disclosed. But today I've read that there some folks in Swiss Federal Institute of Technology Zurich, that have put on-line 4000 nodes running the latest version of the Satoshi client overnight (or nodes that pretend to be that version). So suddenly, almost all the network seems to have upgraded. In reality, I think that very few existing nodes have upgraded, but many new updated nodes have appear.

The BitcoinTalk.org user Cdecker is in charge of this experiment, but I'm unsure if he will continue to support this supernode after his experiment is finished. If he decides to finish it, this will mean that th "update" percentages will suddenly drop again, possibly below the desired 80% threshold, so the network will be exposed.

Also, there the possibility that Cdecker is preparing an attack: he is trying to speed up the disclosure of the vulnerabilities, in order to attack afterwards. (nothing personal Cdecker!)

This is not exactly the "Cancer nodes" attack described in https://en.bitcoin.it/wiki/Weaknesses. It's more a social engineering attack.

My proposal would be to measure the existent versions by taking a single IP address per /16 (x.y.0.0) block, so the statistics are less biased and cannot be easily manipulated.

Maybe luke can add another beautiful pie graphs that filters IPs addresses as I described.

What do you think?

Mike, don't forget to implement all the DoS checks Satoshi client has implemented. (Check https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks)


For instance, each time you receive an alert you process it with processAlert(), without checking for duplicates. Checking the alert requires CPU and possibly GUI resources to show the alert to the user.

A malicious user may attack your application by continuously sending repeated alerts

Best regards, Sergio.

Both Bitcoinj and BitcoinSharp are very good starting points. BitcoinSharp is outdated and requires some modifications to get it working (I posted the modifications some time ago). I like BitcoinSharp because it does not require you to get involved in Makefiles or Maven. Just use the Microsoft Express IDE.
I've been also doing tests using Bitcoinj using Eclipse IDE for Java without problems.

Impressive mixture of C++, macros, COM and C#. Good job!

I wonder who many people are required to maintain such source code.

Please Ufasoft stay tunned to the disclosure of (still undisclosed) Satoshi client vulnerabilities, since some of them may also apply to Ufasoft Coin.

Best regards, Sergio.

IMHO, No.
The only difference between TxA and TxB is the signature and the public key, and both are removed before the hash is calculated.

I don't think so. Check https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png

The script scriptSig is completely removed from the transaction when the hash is performed. It's replaced by a part of the previous scriptPubKey.

Because Grau's supernode is still not in production, I will publish the details of this vulnerability.

I also decided to publish it in this thread (an not in supernode source repository) because it's interesting how vulnerabilities are hidden in the code.

Supernode implements a signature cache, like Satoshi client. The data structure to hold the cache is

private Set<String> validSignatureCache;

To check if a signature is on the cache, the code does:

StringBuffer c = new StringBuffer ();
         c.append (new String (Hex.encode (sig), "US-ASCII"));
         c.append (new String (Hex.encode (pubkey), "US-ASCII"));
         c.append (new String (Hex.encode (hash), "US-ASCII"));
         cacheKey = c.toString ();
         if ( validSignatureCache.contains (cacheKey) )
         {
            return true;
         }


The problem is that the fields (sig,pubkey,hash) are concatenated without a separator, so it's possible to "move" bytes from sig to pubkey an viceversa.

POSSIBLE ATTACK

1) The attacker creates one non-standard transactions tx1 with one output 0 whose scriptPubKey is: OP_CHECKSIG
(Tx1 is sent directly to a miner, and included in a block)

2) The attacker then creates a correct transaction TxA that spends Tx1 whose scriptSig is: <sig> <pubKey>
This transaction must be very large and not include any fees, so it's not included in a block by miners.

When bitsofproof supernode receives TxA by a peer it validates the signature (which is correct) and it adds the (sig|pubkey|hash) to the cache.

3) The attacker creates a transaction TxB similar to TxA in every field except for the scriptSig, which becomes: <sig'> <pubKey'>
Where <sig'> = <sig'> | RirstByte(<pubKey'>)
and <pubKey'> = RemoveFirstByte(<pubKey'>)

4) The attacker mines a block including TxB.

5) The block is sent to the supernode. Because  (sig|pubkey|hash) is in the signature cache of the application, this node accepts the block as valid.

But no other node accepts this block, because TxB has clearly an invalid signature

Maybe there is an easy way to attack using this vulnerability.

POSSIBLE SOLUTION

Add some separators:

c.append (new String (Hex.encode (sig), "US-ASCII"));
c.append ("|");
c.append (new String (Hex.encode (pubkey), "US-ASCII"));
c.append ("|");
c.append (new String (Hex.encode (hash), "US-ASCII"));


Best regards,
 Sergio Lerner

Minor (unconfirmed) DoS Security vulnerability: the "unconfirmed" table is implemented over a HashMap whose key is the hash of the transaction (as a string).

I'm unsure reading your code if the attacker can submit two unconfirmed transactions that spend the same inputs, but in that case it would be easy for an attacker to flood the unconfirmed HashMap with entries that map to the same hash bucket, degenerating to linear access complexity.

It would be better to switch to a TreeMap data structure.

Thanks. I noted that the wiki does not show the "Relay Until" field of the alert.

What is the purpose of having two distinct fields Relay Until / expiration?

I know, the client was Bitcoinj, probably outdated. But are there any OTHER alert for any other client version going around and not expired?

When I connect my node to the network I receive this alert message:

Alert received id: 1015
content: 01000000506eb24f000000004c9e935100000000f7030000f50300000000000000979e000000881 300000040555247454e543a20757067726164652072657175697265642c2073656520687474703a 2f2f626974636f696e2e6f72672f646f7320666f722064657461696c7300
signature: 3046022100c7994c5b0a8f5c84f714c54d30e251b55d5e9c733177fc81115375a6f7ca691002210 0a93dc6e50cc58e512b29e522fb63a3428eabb2977930c2d4c6bfb9a2904533da
version: 1
relayUntil: Tue May 15 11:55:12 GFT 2012
expiration: Wed May 15 11:40:12 GFT 2013
cancel: 1013
expiration: Wed May 15 11:40:12 GFT 2013
minVer: 0
maxVer: 40599
priority: 5000
comment:
statusBar: URGENT: upgrade required, see http://bitcoin.org/dos for details
reserved:

Are there any other active alerts in the network ?

Grau, I've updated the https://en.bitcoin.it/wiki/Weaknesses wiki to reflect current Satoshi client protections against DoS.

Be sure you include at least the most important ones in bitsofproof supernode before it goes to production.

These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:

•    Does not forward orphan transactions/blocks
•    Does not forward double-spend transactions
•    Restrict the maximum number of signature checks a transaction input may request
•    Continuous rate-limit of free transactions to mitigate 'penny-flooding'
•    Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.
•    Permanently ban IP addresses that misbehave for a time lapse (24 hours default)
•    Limit the number of stored orphan transactions (10000 by default)
•     Use a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions
•    Limit the number of stored signature in the signature cache (50000 signatures by default)
•    Tries to catch errors in transactions before the time consuming signature verifications.
•    Penalize peers that send us lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
•    In orphan/signature caches: when removing an item, evict a random entry.
•    Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.
•    Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
•    In RPC: Only send a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.
•    In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.
•    In GUI: Limit URI length to prevent a DoS against the QR-Code dialog

Best regards, Sergio.

This should be probably discussed in another thread... it is another under-analyzed important subject...

My estimation is that fee price can be modeled by an equation like this:

Average fee per transaction =
  a0*Mining_Electricity_Cost  + a1*Mining_Hardware_Cost + a2*Avg_Transaction_Size + a3*Avg_Verification_Time
  - a4*Mining_Block_reward

What I've done to reduce fees in my alternate cryptocoin is to reduce average transaction size (80 bytes average), reduce Verification time (0.1 msec average).

I don't know how to reduce electricity cost of mining, except for Proof-Of-Stake proposals.
Wasn't there a paper that analyzed Bitcoin future fee price? What does it says?

Best regards, Sergio.