There is no need to change the message and it's not desirable to do so.
Libsecp256k1 has context randomization available, as well as the nonce function aux randomness input. Either should be enough to mitigate this attack even if its vulnerable in the first place.
Making an application where an attacker can force you to make thousands of signatures while they time you is also not a great idea.
Topic: Libsecp256k1 and Hertzbleed (Read 19 times)
Someone who is making a signed message function can include some random bytes inside the message to mitigate this kind of attack, but in the case of signed transactions, what is available? Perhaps adjusting the change output amounts by a few satoshis would introduce enough randomness in the transaction to defeat the manipulation caused by frequency scaling?
Each UTXO is unique, so shouldn't it count as "different" message? CMIIW.
It's an old vulnerability, but take a look at this: https://crypto.stackexchange.com/questions/100649/is-the-elliptic-curve-cryptography-library-libsecp256k1-not-susceptible-to-the-h
The executive summary is that Hertzbleed exploits frequency scaling in x86 cpus - eg. running at 2.1 GHz or 1.8 GHz instead of 3GHz - and this can cause the wall time to change, which allows for manipulation of algorithms relying on the time, in particular RNGs and stuff like that.
Theoretically, Libsecp256k1 and therefore Bitcoin Core, Electrum, and other wallets that use this library, are vulnerable to this kind of attack, but there's a curious statement inside the answer that states that:
Someone who is making a signed message function can include some random bytes inside the message to mitigate this kind of attack, but in the case of signed transactions, what is available? Perhaps adjusting the change output amounts by a few satoshis would introduce enough randomness in the transaction to defeat the manipulation caused by frequency scaling?
The executive summary is that Hertzbleed exploits frequency scaling in x86 cpus - eg. running at 2.1 GHz or 1.8 GHz instead of 3GHz - and this can cause the wall time to change, which allows for manipulation of algorithms relying on the time, in particular RNGs and stuff like that.
Theoretically, Libsecp256k1 and therefore Bitcoin Core, Electrum, and other wallets that use this library, are vulnerable to this kind of attack, but there's a curious statement inside the answer that states that:
Quote
The attack is challenging and requires the attacker to perform a very large number of signatures on the same message, so some software using it may be effectively protected by automatically including randomness in the message that they're signing, or by having rate limits on the interface that the attacker uses. In particular, I don't know whether the Bitcoin software itself is be vulnerable.
Someone who is making a signed message function can include some random bytes inside the message to mitigate this kind of attack, but in the case of signed transactions, what is available? Perhaps adjusting the change output amounts by a few satoshis would introduce enough randomness in the transaction to defeat the manipulation caused by frequency scaling?
Jump to: