[acqq]

The author's paper has the technical details not present in the article:

https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf

and some interesting remarks:

"The OpenSSL case is slightly complicated because this library performs a verification and re-computes the signature without the CRT optimization if a fault has been detected. We believe that this poses no immediate danger—Lenstra’s attack on RSACRT certainly does not work even if a second fault occurs because of the unoptimized second computation. Depending on the nature of the faults, this could conceivably still reveal the key over time, but several thousand faulty signatures are needed for current key sizes [1, 8], each one preceded by an RSA-CRT fault. As shown in [8], it is possible to construct a faulty CPU which indeed leaks keys in this way, which is why there are some lingering concerns about the reliability of the OpenSSL hardening."

And from the conclusion:

"In the short term, implementing a checked RSACRT signing operation, like NSS or even OpenSSL already do (despite some theoretical concerns about the effectiveness in the case of OpenSSL), seems a very reasonable hardening measure. Longer term, TLS should perhaps switch to a non-deterministic signature scheme like RSASSA-PSS. However, none of these measures will help those operators who have been using unchecked RSA-CRT implementations for years, and are now wondering if their RSA private keys have already leaked."