boringssl/include
David Benjamin 38c20fe8d5 Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.

To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)

08805fe279 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.

Instead, we do the following:

- There is no actual need to minimize n, p, and q, but we have minimized
  copies in the BN_MONT_CTXs, so use those.

- Store additional copies of d, dmp1, and dmq1, at the cost of more
  memory used. These copies have the correct width and are private,
  unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
  operations to use them.

- Move the frozen bit out of rsa->flags, as that too was historically
  accessible without locking.

(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)

Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 22:17:11 +00:00
..
openssl Fix threading issues with RSA freeze_private_key. 2018-02-09 22:17:11 +00:00