The author&#x27;s paper has the technical details not present in the article:<p><a href="https:&#x2F;&#x2F;people.redhat.com&#x2F;~fweimer&#x2F;rsa-crt-leaks.pdf" rel="nofollow">https:&#x2F;&#x2F;people.redhat.com&#x2F;~fweimer&#x2F;rsa-crt-leaks.pdf</a><p>and some interesting remarks:<p>&quot;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.&quot;<p>And from the conclusion:<p>&quot;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.&quot;