commit | ad5cfdf541a6df141bc257122f28c708dd6133c7 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Sat Jan 20 15:56:53 2018 -0500 |
committer | Adam Langley <agl@google.com> | Fri Feb 02 18:03:46 2018 +0000 |
tree | f5d34656cc131d55275889ae5537541ebe4a8bd5 | |
parent | 884086e0e28aad7efe418d9ed7459912e6683fbb [diff] |
Add initial support for non-minimal BIGNUMs. Thanks to Andres Erbsen for extremely helpful suggestions on how finally plug this long-standing hole! OpenSSL BIGNUMs are currently minimal-width, which means they cannot be constant-time. We'll need to either excise BIGNUM from RSA and EC or somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to handle non-minimal word widths is probably simpler. The main constraint is BIGNUM's large "calculator" API surface. One could, in theory, do arbitrary math on RSA components, which means all public functions must tolerate non-minimal inputs. This is also useful for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is silly. As a first step, fix comparison-type functions that were assuming minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only until the rest of the library is fixed. bn->top is now a loose upper bound we carry around. It does not affect numerical results, only performance and secrecy. This is a departure from the original meaning, and compiler help in auditing everything is nice, so the final change in this series will rename bn->top to bn->width. Thus these new functions are named per "width", not "top". Looking further ahead, how are output BIGNUM widths determined? There's three notions of correctness here: 1. Do I compute the right answer for all widths? 2. Do I handle secret data in constant time? 3. Does my memory usage not balloon absurdly? For (1), a BIGNUM function must give the same answer for all input widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be wider than |m| by way of leading zeres. The simplest approach is to write code in a width-agnostic way and rely on functions to accept all widths. Where functions need to look at bn->d, we'll a few helper functions to smooth over funny widths. For (2), (1) is little cumbersome. Consider constant-time modular addition. A sane type system would guarantee input widths match. But C is weak here, and bifurcating the internals is a lot of work. Thus, at least for now, I do not propose we move RSA's internal computation out of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to stack-allocate, curves were already specialized, and EC only has two types with many operations on those types. None of these apply to RSA. We've got numbers mod n, mod p, mod q, and their corresponding exponents, each of which is used for basically one operation.) Instead, constant-time BIGNUM functions will output non-minimal widths. This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul, constant-time[*] would dictate r->top = a->top + b->top. A calculator repeatedly multiplying by one would then run out of memory. Those we'll split into a private BN_mul_fixed for crypto, leaving BN_mul for calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top. [*] BN_mul is not constant-time for other reasons, but that will be fixed separately. Bug: 232 Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069 Reviewed-on: https://boringssl-review.googlesource.com/25244 Reviewed-by: Adam Langley <agl@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: