- Mar 11, 2019
-
-
Richard Levitte authored
Adding a provider means creating an internal provier object and adding it to the store. This allows the addition of built in providers, be it in the OpenSSL libraries or in any application. "Loading" a provider is defined broadly. A built in provider is already "loaded" in essence and only needs activating, while a provider in a dynamically loadable module requires actually loading the module itself. In this API, "loading" a provider does both. Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
-
Richard Levitte authored
The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by:
-
Richard Levitte authored
These will be used to point out general OpenSSL modules directory. ENGINE modules are kept apart for backward compatibility. Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8417)
-
Rich Salz authored
Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by:
-
Rich Salz authored
This does no harm, and ensures that the inclusion isn't mistakenly removed in the generated *err.h where it's actually needed. Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
- Mar 10, 2019
-
-
A. Schulze authored
CLA: trivial Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8447)
-
Darren Tucker authored
All other instances are OPENSSL_NO_ENGINE without the trailing "S". Fixes build when configured with no-engine. CLA: trivial Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
-
- Mar 08, 2019
-
-
Tomas Mraz authored
Reviewed-by:
-
Matt Caswell authored
The argument to this function is declared const in the header file. However the implementation did not have this. This issue is only visible when using enable-zlib. Reviewed-by:
-
- Mar 07, 2019
-
-
Bernd Edlinger authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/8365)
-
Bernd Edlinger authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Bernd Edlinger authored
of RSA_private_decrypt/RSA_public_encrypt. Reviewed-by:
-
Bernd Edlinger authored
Fixes #8364 and #8357 Reviewed-by:
-
Bernd Edlinger authored
Fixes #8416 Reviewed-by:
-
Matt Caswell authored
The previous commit fixed an underflow that may occur in ecp_nistp521.c. This commit adds a test for that condition. It is heavily based on an original test harness by Billy Brumley. Reviewed-by:
-
Matt Caswell authored
The function felem_diff_128_64 in ecp_nistp521.c substracts the number |in| from |out| mod p. In order to avoid underflow it first adds 32p mod p (which is equivalent to 0 mod p) to |out|. The comments and variable naming suggest that the original author intended to add 64p mod p. In fact it has been shown that with certain unusual co-ordinates it is possible to cause an underflow in this function when only adding 32p mod p while performing a point double operation. By changing this to 64p mod p the underflow is avoided. It turns out to be quite difficult to construct points that satisfy the underflow criteria although this has been done and the underflow demonstrated. However none of these points are actually on the curve. Finding points that satisfy the underflow criteria and are also *on* the curve is considered significantly more difficult. For this reason we do not believe that this issue is currently practically exploitable and therefore no CVE has been assigned. This only impacts builds using the enable-ec_nistp_64_gcc_128 Configure option. With thanks to Bo-Yin Yang, Billy Brumley and Dr Liu for their significant help in investigating this issue. Reviewed-by:
-
- Mar 06, 2019
-
-
Shane Lontis authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8393)
-
David von Oheimb authored
constify *_dup() and *i2d_*() and related functions as far as possible, introducing DECLARE_ASN1_DUP_FUNCTION Reviewed-by:
-
Matt Caswell authored
Correctly describe the maximum IV length. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. CVE-2019-1543 Fixes #8345 Reviewed-by:
-
Richard Levitte authored
The trace API doesn't know that the BIOs we give it, let alone those we attach to callbacks as 'void *data', need to be cleaned up. This must be done in the application. To ensure this cleanup is done as late as possible, use atexit(). Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
Richard Levitte authored
Co-authored-by:
-
