Looking at libgcrypt's patch [1], it looks like the mitigation technique they're using is to blind the private key and message hash with a random number before performing point addition, and then unblinding the result of the point addition. This unfortunately requires an extra 3 point multiplication operations, so it probably isn't a good solution where performance is critical.<p>According to the article, the private key information is leaked through memory caches, so it looks like libgcrypt's solution just ensures that the data written to memory caches is random, rather than leaking the private key.<p>Also according to the article, libsecp256k1 isn't vulnerable, and they still only do 2 point multiplications [2] (compared to libgcrypt's 5 point multiplications). So it <i>is</i> possible to mitigate this attack efficiently.<p>[1] <a href="https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000426.html" rel="nofollow">https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/0004...</a><p>[2] <a href="https://github.com/bitcoin-core/secp256k1/blob/master/src/ecdsa_impl.h#L271" rel="nofollow">https://github.com/bitcoin-core/secp256k1/blob/master/src/ec...</a>