Bitcoin Forum
April 25, 2014, 03:49:02 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Fixed vulnerability explanation: Why the signature cache is a DoS protection.  (Read 907 times)
Sergio_Demian_Lerner
Sr. Member
****
expert
Offline Offline

Activity: 470


View Profile WWW

Ignore
January 14, 2013, 02:23:44 PM
 #1

I read a transcript of  #bitcoin-dev (http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/11/09) where jgarzik and, Sipa debated whether the signature cache was a performance optimization or a DoS protection and why.
The sig cache is both of them. But the sig cache was included before performance was a problem because of the DoS protection requirement.

The following attack against versions prior 0.6.3, e-mailed to Gavin on May-2012, explains it:

1. The attacker creates a transaction that pays 0.01 BTC to 100 different addresses. (The attacker must have 1 BTC). To avoid paying fees, the attacker can divide the transaction into slices, each one below 1 kilobyte.The attacker broadcasts the transactions and waits for confirmation.

2. Afterwards the attacker builds transactions grabbing 100 of his own prevouts and adding an additional prevout that he does not own.  This prevout is a coinbase that has not been matured (it does not need to have a valid signature, since the method exit point is before the script verification). To create many fake transactions, the order of the first 100 inputs is randomized.

3. The attacker sends these transactions to the victim. The transaction size would be around 18 Kbytes. The transaction would take around 0.36 seconds to arrive (with a 50 Kbytes/sec connection).

4. The victim's client app will go with the transaction straight through ConnectInputs() and successfully connect the first 100, and then fail to connect the last. The time required for this check in an average PC is approximately 100 * 4 msec = 400 msec  (an estimation). Then the attacker can hang the vitims app by sending these fake transactions at a rate of around 3 per second. The number of inputs used for the attack is arbitrary (can be as low as 10, giving 10! unique possible transactions).

Note that if the connection bandwidth is higher, then the attack is stronger. If the victim's CPU is slower, then also the attack also get stronger.

I proposed the solution of a signature cache to Gavin at that time. It turned out that Satoshi himself had thought about adding the sig cache, but I think it was mainly for performance reasons.

Best regards,
 Sergio.
1398397742
Hero Member
*
Offline Offline

Posts: 1398397742

View Profile Personal Message (Offline)

Ignore
1398397742
Reply with quote  #2

1398397742
Report to moderator
1398397742
Hero Member
*
Offline Offline

Posts: 1398397742

View Profile Personal Message (Offline)

Ignore
1398397742
Reply with quote  #2

1398397742
Report to moderator
Unbeatable Service & Product Support
Grab Your Miners at GAWMiners.com
Order Before April 25th to receive
Double your Hashing Power for 1 week!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398397742
Hero Member
*
Offline Offline

Posts: 1398397742

View Profile Personal Message (Offline)

Ignore
1398397742
Reply with quote  #2

1398397742
Report to moderator
Sergio_Demian_Lerner
Sr. Member
****
expert
Offline Offline

Activity: 470


View Profile WWW

Ignore
January 14, 2013, 05:01:22 PM
 #2

Also, signature verification (that take a long time and can be repeatedly requested by an attacker), can be used as an oracle to distinguish between two or more different transaction processing results. Without the cache, for instance, attacks like this https://bitcointalk.org/index.php?topic=135856.0 can be executed faster, since the time it takes to process a transaction can be used to locate the exact prevout that fails, in a transaction with thousands of inputs. The cache tries to mitigate the timing side-channel.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!