- Mar 20, 2019
-
-
Richard Levitte authored
Great effort has been made to make initialization more configurable. However, the behavior of OPENSSL_config() was lost in the process, having it suddenly generate errors it didn't previously, which is not how it's documented to behave. A simple setting of default flags fixes this problem. Fixes #8528 Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8533) (cherry picked from commit 905c9a72)
-
Shane Lontis authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8532) (cherry picked from commit 138ef774)
-
- Mar 19, 2019
-
-
Matt Caswell authored
DSA can accept other digests other than SHA1. EC ignores the digest option altogether. Fixes #8425 Reviewed-by:
-
Vitezslav Cizek authored
The ecdh_c array is allocated of the same size as ecdh_choices, whose size depends on whether the support for binary curves is enabled or not. (The same goes for ecdsa_c). On systems without SIGALRM, ecdh_c is indexed by predefined constants intended for representing the index of the ciphers in the ecdh_choices array. However, in case of NO_EC2M some of the #defined constants won't match and would actually access the ecdh_c out-of-bounds. Use enum instead of a macro to define the curve indexes so they're within the bounds of the ecdh_c array. Reviewed-by:
-
Vitezslav Cizek authored
openssl speed doesn't take into account that the library could be compiled without the support for the binary curves and happily uses them, which results in EC_GROUP_new_by_curve_name() errors. Reviewed-by:
-
Dr. Matthias St. Pierre authored
The indentation in the Configure file is currently very strange when viewed in an editor with a tab width of four spaces, because it has mixed tab-and-whitespace indentation, which was apparently done with a tab width of eight spaces. This commit converts all tabs to spaces using expand(1) with default settings. To verify that there are only whitespace changes, use git show --ignore-space-change <this commit> Reviewed-by: -
Hua Zhang authored
There are some compiling errors for mips32r6 and mips64r6: crypto/bn/bn-mips.S:56: Error: opcode not supported on this processor: mips2 (mips2) `mulu $1,$12,$7' crypto/mips_arch.h: Assembler messages: crypto/mips_arch.h:15: Error: junk at end of line, first unrecognized character is `&' Signed-off-by:
Hua Zhang <hua.zhang1974@hotmail.com> Reviewed-by:
-
Richard Levitte authored
Fixes #8495 Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8496) (cherry picked from commit 2864df8f)
-
Shane Lontis authored
Reviewed-by:
-
- Mar 18, 2019
-
-
Bernd Edlinger authored
The secret point R can be recovered from S using the equation R = S - P. The X and Z coordinates should be sufficient for that. Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Daniel Axtens authored
There are two copy-paste errors in handling CTR mode. When dealing with a 2 or 3 block tail, the code branches to the CBC decryption exit path, rather than to the CTR exit path. This can lead to data corruption: in the Linux kernel we have a copy of this file, and the bug leads to corruption of the IV, which leads to data corruption when we call the encryption function again later to encrypt subsequent blocks. Originally reported to the Linux kernel by Ondrej Mosnáček <omosnacek@gmail.com> CLA: trivial Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> Reviewed-by:
-
- Mar 15, 2019
-
-
Dr. Matthias St. Pierre authored
Fixes #8487 Amends #7230 Reviewed-by:
-
- Mar 13, 2019
-
-
Nicola Tuveri authored
Fixes #8462 (cherry picked from commit 81d61a62faa809e6c51f5fc2b86fb0d31146fd5e) Reviewed-by:
-
Matt Caswell authored
Also make various changes to bring the file into line with current coding style. Fixes #8456 Reviewed-by:
-
- Mar 11, 2019
-
-
Shane Lontis authored
Reviewed-by:
-
- Mar 10, 2019
-
-
A. Schulze authored
CLA: trivial Reviewed-by:
-
- Mar 07, 2019
-
-
Bernd Edlinger authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/8365) (cherry picked from commit f0e4a860d0b350e10a1ee3898445cac85af8ea16)
-
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:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/8405) (cherry picked from commit 6855b496)
-
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...
-
- Mar 06, 2019
-
-
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:
-
- Mar 05, 2019
-
-
Matt Caswell authored
Sessions must be immutable once they can be shared with multiple threads. We were breaking that rule by writing the ticket index into it during the handshake. This can lead to incorrect behaviour, including failed connections in multi-threaded environments. Reported by David Benjamin. Reviewed-by:
-
- Mar 04, 2019
-
-
Vitezslav Cizek authored
GNU strerror_r may return either a pointer to a string that the function stores in buf, or a pointer to some (immutable) static string in which case buf is unused. In such a case we need to set buf manually. Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
- Mar 01, 2019
-
-
Bernd Edlinger authored
Use select to wait for /dev/random in readable state, but do not actually read anything from /dev/random, use /dev/urandom first. Use linux define __NR_getrandom instead of the glibc define SYS_getrandom, in case the kernel headers are more current than the glibc headers. Fixes #8215 Reviewed-by:
-
Shigeki Ohtsu authored
Generate asm files with Makefile rules. From: - https://github.com/nodejs/node/commit/0d9a86c7cb3566b22becc656691282402f5026c0 Reviewed-by:
-
- Feb 28, 2019
-
-
Richard Levitte authored
CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS, and LDLIBS (cherry picked from commit 8e7984e5783877c58cddc7b4e668401580ab4467) Reviewed-by:
-
Richard Levitte authored
For C, -ansi is equivalent to -std=c90 For C++, -ansi is equivalent to -std=c++98 We also place -ansi in CPPFLAGS instead of the usual command line config, to avoid getting it when linking (clang complains) (cherry picked from commit 874f785988c17991051d36a0407a87b36c463a94) Reviewed-by:
-
Richard Levitte authored
Some of the devteam flags are not for C++ (cherry picked from commit e373c70a3e535b560f6b6bade914a724aa975c55) Reviewed-by:
-
Richard Levitte authored
This ensures that we don't mistakenly use C++ keywords anywhere public. Related to #8313 (cherry picked from commit 9f27d4bf32c0465270e1922365b21825a0f7a42a) Reviewed-by:
-
Richard Levitte authored
This makes `--strict-warnings` into a compiler pseudo-option, i.e. it gets treated the same way as any other compiler option given on the configuration command line, but is retroactively replaced by actual compiler warning options, depending on what compiler is used. This makes it easier to see in what order options are given to the compiler from the configuration command line, i.e. this: ./config -Wall --strict-warnings would give the compiler flags in the same order as they're given, i.e.: -Wall -Werror -Wno-whatever ... instead of what we got previously: -Werror -Wno-whatever ... -Wall (cherry picked from commit fcee53948b7f9a5951d42f4ee321e706ea6b4b84) Reviewed-by:
-
- Feb 27, 2019
-
-
Shane Lontis authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
