a63d0ad40d
If the caller asked for the base to be treated as secret, we should provide that. Allowing unbounded inputs is not compatible with being constant-time. Additionally, this aligns with the guidance 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: BN_mod_exp_mont_consttime and BN_mod_exp_mont now require inputs be fully reduced. I believe current callers tolerate this. Additionally, due to a quirk of how certain operations were ordered, using (publicly) zero exponent tolerated a NULL BN_CTX while other exponents required non-NULL BN_CTX. Non-NULL BN_CTX is now required uniformly. This is unlikely to cause problems. Any call site where the exponent is always zero should just be replaced with BN_value_one(). Change-Id: I7c941953ea05f36dc2754facb9f4cf83a6789c61 Reviewed-on: https://boringssl-review.googlesource.com/27665 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Steven Valdez <svaldez@google.com> |
||
---|---|---|
.. | ||
asm | ||
add.c | ||
bn_test_to_fuzzer.go | ||
bn_test.cc | ||
bn_tests.txt | ||
bn.c | ||
bytes.c | ||
check_bn_tests.go | ||
cmp.c | ||
ctx.c | ||
div.c | ||
exponentiation.c | ||
gcd.c | ||
generic.c | ||
internal.h | ||
jacobi.c | ||
montgomery_inv.c | ||
montgomery.c | ||
mul.c | ||
prime.c | ||
random.c | ||
rsaz_exp.c | ||
rsaz_exp.h | ||
shift.c | ||
sqrt.c |