- 18 Apr, 2019 1 commit
-
-
Simo Sorce authored
Signed-off-by:
Simo Sorce <simo@redhat.com> Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8774)
-
- 17 Apr, 2019 4 commits
-
-
Andy Polyakov authored
The change is triggered by ThunderX2 where 3+1 was slower than scalar code path, but it helps all processors [to handle <512 inputs]. Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Pauli authored
Reviewed-by:
-
- 16 Apr, 2019 5 commits
-
-
Tomas Mraz authored
Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
Tomas Mraz authored
Reviewed-by:
-
Tomas Mraz authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Tomas Mraz authored
Reviewed-by:
-
- 15 Apr, 2019 4 commits
-
-
Kurt Roeckx authored
The callback should be called with 1 when a Miller-Rabin round marked the candidate as probably prime. Reviewed-by: -
Richard Levitte authored
The clang documentation in all sanitizers we currently use says this: When linking shared libraries, the {flavor}Sanitizer run-time is not linked, so -Wl,-z,defs may cause link errors (don’t use it with {flavor}Sanitizer) (in our case, {flavor} is one of Address, Memory, or UndefinedBehavior) Therefore, we turn off that particular flag specifically when using the sanitizers. Fixes #8735 Reviewed-by: -
Richard Levitte authored
Forward declare the dispatched functions using typedefs from core_numbers.h. This will ensure that they have correct signatures. Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8747)
-
Richard Levitte authored
This allows the provider digest_final operation to check that it doesn't over-run the output buffer. The EVP_DigestFinal_ex function doesn't take that same parameter, so it will have to assume that the user provided a properly sized buffer, but this leaves better room for future enhancements of the public API. Reviewed-by:
-
- 14 Apr, 2019 2 commits
-
-
David Benjamin authored
The rep parameter takes an int in C, but the assembly implementation looks at the upper bits. While it's unlikely to happen here, where all calls pass a constant, in other scenarios x86_64 compilers will leave arbitrary values in the upper half. Fix this by making the C prototype match the assembly. (This aspect of the calling convention implies smaller-than-word arguments in assembly functions should be avoided. There are far fewer things to test if everything consistently takes word-sized arguments.) This was found as part of ABI testing work in BoringSSL. Reviewed-by:
-
Bernd Edlinger authored
This happens in ec_key_simple_check_key and EC_GROUP_check. Since the the group order is not a secret scalar, it is unnecessary to use coordinate blinding. Fixes: #8731 Reviewed-by:
-
- 12 Apr, 2019 7 commits
-
-
Joshua Lock authored
A couple of minor tweaks to match the style introduced in #7854: - BIO_connect: remove line break to make more grep friendly - SSL_CTX_new: harmoise the format of the HISTORY section Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
Joshua Lock authored
SEE ALSO before HISTORY is the more common pattern in OpenSSL manual pages and seems to be the prevalent order based on sampling my system manual pages. Fixes #8631 Reviewed-by:
-
Joshua Lock authored
Check that the HISTORY section is located after the SEE ALSO section, this is a much more frequent order in OpenSSL manual pages (and UNIX manual pages in general). Also check that SEE ALSO comes after EXAMPLES, so that the tool can ensure the correct manual section sequence. Reviewed-by:
-
Joshua Lock authored
Change to check_section_location(), a generic function to ensure that section SECTION appears before section BEFORE in the man pages. Reviewed-by:
-
Matt Caswell authored
These undocumented functions were never integrated into the EVP layer and implement the AES Infinite Garble Extension (IGE) mode and AES Bi-directional IGE mode. These modes were never formally standardised and usage of these functions is believed to be very small. In particular AES_bi_ige_encrypt() has a known bug. It accepts 2 AES keys, but only one is ever used. The security implications are believed to be minimal, but this issue was never fixed for backwards compatibility reasons. Reviewed-by:
-
Bernd Edlinger authored
usage: openssl speed -cmac aes128 Reviewed-by:
-
Pauli authored
Refer to NIST SP 800-90C section 5.4 "Prediction Resistance.l" This requires the seed sources to be approved as entropy sources, after which they should be considered live sources as per section 5.3.2 "Live Entropy Source Availability." Reviewed-by:
-
- 11 Apr, 2019 5 commits
-
-
Shane Lontis authored
Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
Nicola Tuveri authored
This fixes the "verifying the alias" case. Actually, while working on it, I realized that conceptually we were testing the 2 different behaviours of `EC_GROUP_check_named_curve()` at the same time, and actually not in the proper way. I think it's fair to assume that overwriting the curve name for an existing group with `NID_undef` could lead to the unexpected behaviour we were observing and working around. Thus I decided to separate the lookup test in a dedicated simpler test that does what the documentation of `EC_GROUP_check_named_curve()` suggests: the lookup functionality is meant to find a name for a group generated with explicit parameters. In case an alternative alias is returned by the lookup instead of the expected nid, to avoid doing comparisons between `EC_GROUP`s with different `EC_METHOD`s, the workaround is to retrieve the `ECPARAMETERS` of the "alias group" and create a new explicit parameters group to use in `EC_GROUP_cmp()`. Reviewed-by:
-
Nicola Tuveri authored
Setting arbitrary `p`, `a` or `b` with `EC_GROUP_set_curve()` might fail for some `EC_GROUP`s, depending on the internal `EC_METHOD` implementation, hence the block of tests verifying that `EC_GROUP_check_named_curve()` fails when any of the curve parameters is changed is modified to run only if the previous `EC_GROUP_set_curve()` call succeeds. `ERR_set_mark()` and `ERR_pop_to_mark()` are used to avoid littering the thread error stack with unrelated errors happened during `EC_GROUP_set_curve()`. Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
- 10 Apr, 2019 6 commits
-
-
Shane Lontis authored
Used to check that a test fails in fips mode i.e. ok_nofips(run(...)) Reviewed-by:
-
Pauli authored
Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Jakub Wilk authored
CLA: trivial Reviewed-by:
-
Richard Levitte authored
Even with custome ciphers, the combination in == NULL && inl == 0 should not be passed down to the backend cipher function. The reason is that these are the values passed by EVP_*Final, and some of the backend cipher functions do check for these to see if a "final" call is made. Fixes #8675 Reviewed-by:
-
- 09 Apr, 2019 6 commits
-
-
Paul Yang authored
This commit makes the X509_set_sm2_id to 'set0' behaviour, which means the memory management is passed to X509 and user doesn't need to free the sm2_id parameter later. API name also changes to X509_set0_sm2_id. Document and test case are also updated. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
When the purpose is to pass parameters to a setter function, that setter function needs to know the size of the data passed. This remains true for the pointer data types as well. Reviewed-by:
-
Matt Caswell authored
If using a custom X509_LOOKUP_METHOD then calls to X509_STORE_CTX_get_by_subject may crash due to an incorrectly initialised X509_OBJECT being passed to the callback get_by_subject function. Fixes #8673 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
When we attempt to fetch a method with a given NID we will ask the providers for it if we don't already know about it. During that process we may be told about other methods with a different NID. We need to make sure we don't confuse the two. Reviewed-by:
-
