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://bitcointalksearch.org/topic/new-vulnerability-know-your-peer-public-addresses-in-14-minutes-135856 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.
Topic: Fixed vulnerability explanation: Why the signature cache is a DoS protection. (Read 2659 times)
January 14, 2013, 12:01:22 PM
January 14, 2013, 09:23:44 AM
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.
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.
Jump to: