summaryrefslogtreecommitdiffstats
path: root/crypto/bn/bn_lib.c
diff options
context:
space:
mode:
authorNicola Tuveri <nic.tuv@gmail.com>2020-01-21 17:00:41 +0200
committerNicola Tuveri <nic.tuv@gmail.com>2020-02-18 19:11:10 +0200
commit0401d766afcd022748763f5614188301c9856c6e (patch)
tree431a6821fdf75535db61869afe48a95a6b7e82e7 /crypto/bn/bn_lib.c
parenta377871db10afcdfb080c79f3245baf441fe07fc (diff)
[EC] harden EC_KEY against leaks from memory accesses
We should never leak the bit length of the secret scalar in the key, so we always set the `BN_FLG_CONSTTIME` flag on the internal `BIGNUM` holding the secret scalar. This is important also because `BN_dup()` (and `BN_copy()`) do not propagate the `BN_FLG_CONSTTIME` flag from the source `BIGNUM`, and this brings an extra risk of inadvertently losing the flag, even when the called specifically set it. The propagation has been turned on and off a few times in the past years because in some conditions has shown unintended consequences in some code paths, so at the moment we can't fix this in the BN layer. In `EC_KEY_set_private_key()` we can work around the propagation by manually setting the flag after `BN_dup()` as we know for sure that inside the EC module the `BN_FLG_CONSTTIME` is always treated correctly and should not generate unintended consequences. Setting the `BN_FLG_CONSTTIME` flag alone is never enough, we also have to preallocate the `BIGNUM` internal buffer to a fixed public size big enough that operations performed during the processing never trigger a realloc which would leak the size of the scalar through memory accesses. Fixed Length ------------ The order of the large prime subgroup of the curve is our choice for a fixed public size, as that is generally the upper bound for generating a private key in EC cryptosystems and should fit all valid secret scalars. For preallocating the `BIGNUM` storage we look at the number of "words" required for the internal representation of the order, and we preallocate 2 extra "words" in case any of the subsequent processing might temporarily overflow the order length. Future work ----------- A separate commit addresses further hardening of `BN_copy()` (and indirectly `BN_dup()`). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10631)
Diffstat (limited to 'crypto/bn/bn_lib.c')
0 files changed, 0 insertions, 0 deletions