[openssl-dev] Potential timing problems in OpenSSL RSA implementation
hanno at hboeck.de
Thu Dec 14 09:50:23 UTC 2017
As many have probably seen some people (including me) recently published
the so-called ROBOT attack , which is the re-birth of the old
Bleichenbacher attack against RSA in TLS.
We mostly focussed on non-timing issues and OpenSSL is not among the
vulnerable implementations. However during various conversations I
learned something about timing problems that affects OpenSSL (but very
likely also almost every other TLS library out there).
The problem is the use of the bignum library, which is variable size.
This means that numbers with leading zeros will take up slightly less
space and thus could cause a timing signal. A more detailed description
For RSA this means if the result of an RSA operation has one or several
leading zeros this means copying around the data will be slightly
faster. Thus an attacker can learn something about the decrypted value.
In the end this could be turned into an attack very similar to a
I'd like to stress that this is highly speculative, it may very well be
that this is not exploitable in any practical way. But I thought it's
important enough that it should be public knowledge. (Also "This leaves
a small timing channel, [...] but it is not believed to be large
enough to be exploitable" said TLS 1.2 when it described what later
Fixing this would likely require changing the bignum library in a
way that it knows fixed size types that allow e.g. treating a 256 byte
number in the same way as a 255 byte number.
the top-level RSA-decrypt for OpenSSL 1.0.2's TLS impl. It calls
RSA_private_decrypt, which ends up here
Note that that function calls
to convert from the resulting BIGNUM to a big-endian buffer. That
works based on the number of bytes in the BIGNUM. Since BIGNUMs can
never have a most-significant zero limb, if the RSA result starts with
32 (or 64) leading zero bits, there'll be a timing signal there. Also,
if it starts with 8 leading zero bits, there'll be a timing signal in
BN_bn2bin. BoringSSL solves
latter problem, but not the former.
mail/jabber: hanno at hboeck.de
More information about the openssl-dev