- 09 9月, 2019 19 次提交
-
-
由 Billy Brumley 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/9821)
-
由 Bernd Edlinger 提交于
crypto/rand/rand_win.c(70) : error C2065: 'BCRYPT_USE_SYSTEM_PREFERRED_RNG' : undeclared identifier Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9827)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
An EVP_PKEY can be used for multiple different algorithm operations. Only one can be used at a time, so we move those into a union. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
We add new functions for getting parameters and discovering the gettable and settable parameters. We also make EVP_PKEY_CTX_get_signature_md() a function and implement it in terms of the new functions. This enables applications to discover the set of parameters that are supported for a given algorithm implementation. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
It is valid for a pub_key and priv_key to be missing from a DH "key". Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
Documentation for EVP_SIGNATURE_*() as well as EVP_PKEY_sign_init_ex(), EVP_PKEY_verify_init_ex() and EVP_PKEY_verify_recover_init_ex(). Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Matt Caswell 提交于
This makes EVP_PKEY_sign and EVP_PKEY_sign_init provider aware. It also introduces the new type EVP_SIGNATURE to represent signature algorithms. This also automatically makes the EVP_Sign* APIs provider aware because they use EVP_Digest* (which is already provider aware) and EVP_PKEY_sign(_init) under the covers. At this stage there are no signature algorithms in any providers. That will come in the following commits. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9753)
-
由 Bernd Edlinger 提交于
so results were undefined. Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9796)
-
由 Bernd Edlinger 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9796)
-
由 Bernd Edlinger 提交于
The check was missing in DH_check and DH_check_params. [extended tests] Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9796)
-
由 Nicola Tuveri 提交于
- Replace a `TEST_true()` with `!TEST_false()` to avoid reporting confusing errors - We tend to use `if (!TEST_foo() || !TEST_bar())` and it's a bit confusing to switch to `if(!(TEST_foo() && TEST_bar()))`: replace it with the more common style Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9813)
-
由 Nicola Tuveri 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9813)
-
由 Jakub Zelenka 提交于
Reviewed-by: NPaul Yang <kaishen.yy@antfin.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9825)
-
由 Nicola Tuveri 提交于
Description ----------- Upon `EC_GROUP_new_from_ecparameters()` check if the parameters match any of the built-in curves. If that is the case, return a new `EC_GROUP_new_by_curve_name()` object instead of the explicit parameters `EC_GROUP`. This affects all users of `EC_GROUP_new_from_ecparameters()`: - direct calls to `EC_GROUP_new_from_ecparameters()` - direct calls to `EC_GROUP_new_from_ecpkparameters()` with an explicit parameters argument - ASN.1 parsing of explicit parameters keys (as it eventually ends up calling `EC_GROUP_new_from_ecpkparameters()`) A parsed explicit parameter key will still be marked with the `OPENSSL_EC_EXPLICIT_CURVE` ASN.1 flag on load, so, unless programmatically forced otherwise, if the key is eventually serialized the output will still be encoded with explicit parameters, even if internally it is treated as a named curve `EC_GROUP`. Before this change, creating any `EC_GROUP` object using `EC_GROUP_new_from_ecparameters()`, yielded an object associated with the default generic `EC_METHOD`, but this was never guaranteed in the documentation. After this commit, users of the library that intentionally want to create an `EC_GROUP` object using a specific `EC_METHOD` can still explicitly call `EC_GROUP_new(foo_method)` and then manually set the curve parameters using `EC_GROUP_set_*()`. Motivation ---------- This has obvious performance benefits for the built-in curves with specialized `EC_METHOD`s and subtle but important security benefits: - the specialized methods have better security hardening than the generic implementations - optional fields in the parameter encoding, like the `cofactor`, cannot be leveraged by an attacker to force execution of the less secure code-paths for single point scalar multiplication - in general, this leads to reducing the attack surface Check the manuscript at https://arxiv.org/abs/1909.01785 for an in depth analysis of the issues related to this commit. It should be noted that `libssl` does not allow to negotiate explicit parameters (as per RFC 8422), so it is not directly affected by the consequences of using explicit parameters that this commit fixes. On the other hand, we detected external applications and users in the wild that use explicit parameters by default (and sometimes using 0 as the cofactor value, which is technically not a valid value per the specification, but is tolerated by parsers for wider compatibility given that the field is optional). These external users of `libcrypto` are exposed to these vulnerabilities and their security will benefit from this commit. Related commits --------------- While this commit is beneficial for users using built-in curves and explicit parameters encoding for serialized keys, commit b783beea (and its equivalents for the 1.0.2, 1.1.0 and 1.1.1 stable branches) fixes the consequences of the invalid cofactor values more in general also for other curves (CVE-2019-1547). The following list covers commits in `master` that are related to the vulnerabilities presented in the manuscript motivating this commit: - d2baf88c [crypto/rsa] Set the constant-time flag in multi-prime RSA too - 311e903d [crypto/asn1] Fix multiple SCA vulnerabilities during RSA key validation. - b783beea [crypto/ec] for ECC parameters with NULL or zero cofactor, compute it - 724339ff Fix SCA vulnerability when using PVK and MSBLOB key formats Note that the PRs that contributed the listed commits also include other commits providing related testing and documentation, in addition to links to PRs and commits backporting the fixes to the 1.0.2, 1.1.0 and 1.1.1 branches. Responsible Disclosure ---------------------- This and the other issues presented in https://arxiv.org/abs/1909.01785 were reported by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya and Billy Bob Brumley from the NISEC group at Tampere University, FINLAND. The OpenSSL Security Team evaluated the security risk for this vulnerability as low, and encouraged to propose fixes using public Pull Requests. _______________________________________________________________________________ Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9808)
-
由 Richard Levitte 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/9812)
-
- 08 9月, 2019 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
While gcc ignores unknown options of the type '-Wno-xxx', clang by default issues a warning [-Wunknown-warning-option] (see [3]), which together with '-Werror' causes the build to fail. This turned out to be a problem on the 1.0.2 stable branch in the case of the '-Wextended-offsetof' option, which was removed in version 6.0.0, but needs to be kept here in order to support older clang versions, too (see #9446). Incidentally, master and 1.1.1 branch already contained the -Wno-unknown-warning-option option. Due to its special role and its importance, this commit adds an explaining commit message and moves the option to the front. [extended tests] Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9447)
-
- 07 9月, 2019 20 次提交
-
-
由 Billy Brumley 提交于
This is a forward port from https://github.com/openssl/openssl/pull/9781 of the CHANGES entry for the functionality added in https://github.com/openssl/openssl/pull/9727 (cherry picked from commit 4b965086cb56c24cb5d2197fc04869b95f209a11) Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9797)
-
由 Billy Brumley 提交于
This is a forward port from https://github.com/openssl/openssl/pull/9781 for the test logic introduced by https://github.com/openssl/openssl/pull/9727 As @mattcaswell commented (https://github.com/openssl/openssl/pull/9781#discussion_r321621541): > These `TEST_true` calls should be `!TEST_false` because we are > *expecting* a failure. > The difference is that the test framework will print error details if > the test doesn't give the expected answer. > So by using `TEST_true` instead of `!TEST_false` we'll get error > details printed, but the test will succeed anyway. (cherry picked from commit e8aafc891d9bd7fa1cce0401d858ef842f09b49e) Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9797)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9770)
-
由 Nicola Tuveri 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9511)
-
由 Nicola Tuveri 提交于
Replace flip_endian() by using the little endian specific BN_bn2lebinpad() and BN_lebin2bn(). Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9511)
-
由 Nicola Tuveri 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9511)
-
由 Nicola Tuveri 提交于
This issue was partially addressed by commit 972c87df, which hardened its callee BN_num_bits_word() to avoid leaking the most-significant word of its argument via branching and memory access pattern. The commit message also reported: > There are a few places where BN_num_bits is called on an input where > the bit length is also secret. This does *not* fully resolve those > cases as we still only look at the top word. BN_num_bits() is called directly or indirectly (e.g., through BN_num_bytes() or BN_bn2binpad() ) in various parts of the `crypto/ec` code, notably in all the currently supported implementations of scalar multiplication (in the generic path through ec_scalar_mul_ladder() as well as in dedicated methods like ecp_nistp{224,256,521}.c and ecp_nistz256.c). Under the right conditions, a motivated SCA attacker could retrieve the secret bitlength of a secret nonce through this vulnerability, potentially leading, ultimately, to recover a long-term secret key. With this commit, exclusively for BIGNUMs that are flagged with BN_FLG_CONSTTIME, instead of accessing only bn->top, all the limbs of the BIGNUM are accessed up to bn->dmax and bitwise masking is used to avoid branching. Memory access pattern still leaks bn->dmax, the size of the lazily allocated buffer for representing the BIGNUM, which is inevitable with the current BIGNUM architecture: reading past bn->dmax would be an out-of-bound read. As such, it's the caller responsibility to ensure that bn->dmax does not leak secret information, by explicitly expanding the internal BIGNUM buffer to a public value sufficient to avoid any lazy reallocation while manipulating it: this should be already done at the top level alongside setting the BN_FLG_CONSTTIME. Thanks to David Schrammel and Samuel Weiser for reporting this issue through responsible disclosure. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9511)
-
由 Nicola Tuveri 提交于
BN_bn2bin() is not constant-time and leaks the number of bits in the processed BIGNUM. The specialized methods in ecp_nistp224.c, ecp_nistp256.c and ecp_nistp521.c internally used BN_bn2bin() to convert scalars into the internal fixed length representation. This can leak during ECDSA/ECDH key generation or handling the nonce while generating an ECDSA signature, when using these implementations. The amount and risk of leaked information useful for a SCA attack varies for each of the three curves, as it depends mainly on the ratio between the bitlength of the curve subgroup order (governing the size of the secret nonce/key) and the limb size for the internal BIGNUM representation (which depends on the compilation target architecture). To fix this, we replace BN_bn2bin() with BN_bn2binpad(), bounding the output length to the width of the internal representation buffer: this length is public. Internally the final implementation of both BN_bn2binpad() and BN_bn2bin() already has masking in place to avoid leaking bn->top through memory access patterns. Memory access pattern still leaks bn->dmax, the size of the lazily allocated buffer for representing the BIGNUM, which is inevitable with the current BIGNUM architecture: reading past bn->dmax would be an out-of-bound read. As such, it's the caller responsibility to ensure that bn->dmax does not leak secret information, by explicitly expanding the internal BIGNUM buffer to a public value sufficient to avoid any lazy reallocation while manipulating it: this is already done at the top level alongside setting the BN_FLG_CONSTTIME. Finally, the internal implementation of BN_bn2binpad() indirectly calls BN_num_bits() via BN_num_bytes(): the current implementation of BN_num_bits() can leak information to a SCA attacker, and is addressed in the next commit. Thanks to David Schrammel and Samuel Weiser for reporting this issue through responsible disclosure. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9511)
-