d319205007
Our technique to perform the reduction only works for balanced key sizes. For unbalanced keys, we fall back to variable-time logic. Instead, fall back earlier to the non-CRT codepath, which is still secure, just slower. This also aligns with the advice here: https://github.com/HACS-workshop/spectre-mitigations/blob/master/crypto_guidelines.md#1-do-not-conditionally-choose-between-constant-and-non-constant-time Update-Note: This is a performance hit (some keys will run 3x slower), but only for keys with different-sized primes. I believe the Windows crypto APIs will not accept such keys at all. There are two scenarios to be concerned with for RSA performance: 1. Performance of reasonably-generated keys. Keys that BoringSSL or anyone else reasonable generates will all be balanced, so this change does not affect them. 2. Worst-case performance for DoS purposes. This CL does not change the worst-case performance for RSA at a given bit size. In fact, it improves it slightly. A sufficiently unbalanced RSA key is as slow as not doing CRT at all. In both cases, this change does not affect performance. The affected keys are pathologically-generated ones that were not quite pathological enough. Bug: 235 Change-Id: Ie298dabb549ab9108fa9374aa86ebffe8b6c6c88 Reviewed-on: https://boringssl-review.googlesource.com/27504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> |
||
|---|---|---|
| .. | ||
| blinding.c | ||
| internal.h | ||
| padding.c | ||
| rsa_impl.c | ||
| rsa.c | ||