- May 22, 2019
-
-
Patrick Steuer authored
67c81ec311 forgot about s390x Signed-off-by:
Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8971) (cherry picked from commit 887e22dd8b6f054e39b2d20fc8870eaba7fc61a8)
-
- May 21, 2019
-
-
Matt Caswell authored
This reverts commit dcb982d792d6064ed3493e79749208d8c257ff04. This change is causing extended tests to fail. [extended tests] Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8964) (cherry picked from commit 2c23689402f1894861519d0c1ad762a3e52f4677)
-
- May 08, 2019
-
-
Tobias Nießen authored
This change allows to pass the authentication tag after specifying the AAD in CCM mode. This is already true for the other two supported AEAD modes (GCM and OCB) and it seems appropriate to match the behavior. GCM and OCB also support to set the tag at any point before the call to `EVP_*Final`, but this won't work for CCM due to a restriction imposed by section 2.6 of RFC3610: The tag must be set before actually decrypting data. This commit also adds a test case for setting the tag after supplying plaintext length and AAD. Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7243) (cherry picked from commit 67c81ec311d696464bdbf4c6d6f8a887a3ddf9f8)
-
- Apr 10, 2019
-
-
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:
-
- Apr 06, 2019
-
-
Bernd Edlinger authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8620) (cherry picked from commit 8cf85d48)
-
- Mar 27, 2019
-
-
Matt Caswell authored
Fixes #8567 Reviewed-by:
-
Matt Caswell authored
We treat that as automatic success. Other EVP_*Update functions already do this (e.g. EVP_EncryptUpdate, EVP_DecryptUpdate etc). EVP_EncodeUpdate is a bit of an anomoly. That treats 0 byte input length as an error. Fixes #8576 Reviewed-by:
-
- Mar 21, 2019
-
-
Dmitry Belyavskiy authored
Reviewed-by:
-
- Mar 06, 2019
-
-
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:
-
- Dec 22, 2018
-
-
Shreya Bhandare authored
CLA: trivial Function EVP_PKEY_size has been modified to take a const parameter Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/7892) (cherry picked from commit 47ec2367ebf6082abb103e66e609feb5c128d358)
-
- Dec 10, 2018
-
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
- Nov 20, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
- Oct 02, 2018
-
-
Matt Caswell authored
Check some return values on some functions. Reviewed-by:
-
- Sep 21, 2018
-
-
agnosticdev authored
Reviewed-by:
-
- Sep 13, 2018
-
-
Paul Yang authored
Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/7209)
-
- Sep 11, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
- Sep 07, 2018
-
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
zero-length ID is allowed, but it's not allowed to skip the ID. Fixes: #6534 Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Thus users can use this function to set customized EVP_PKEY_CTX to EVP_MD_CTX structure. Reviewed-by:
-
- Sep 06, 2018
-
-
Pauli authored
Put a NULL check back in to avoid dereferencing the NULL pointer. Reviewed-by:
-
- Sep 05, 2018
-
-
Shane Lontis authored
Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by:
-
- Aug 07, 2018
-
-
Andy Polyakov authored
In some cases it's about redundant check for return value, in some cases it's about replacing check for -1 with comparison to 0. Otherwise compiler might generate redundant check for <-1. [Even formatting and readability fixes.] Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6860)
-
- Aug 06, 2018
-
-
Patrick Steuer authored
Signed-off-by:
Andy Polyakov <appro@openssl.org> Reviewed-by:
-
- Aug 03, 2018
-
-
Dr. Matthias St. Pierre authored
Fixes #6800 Replaces #5418 This commit reverts commit 7876dbff and moves the check for a zero-length input down the callstack into sha3_update(). Reviewed-by:
-
- Aug 01, 2018
-
-
Pauli authored
Reviewed-by:
-
- Jul 12, 2018
-
-
Patrick Steuer authored
Reviewed-by:
-
- Jul 06, 2018
-
-
Andy Polyakov authored
Improvement coefficients vary with TLS fragment length and platform, on most Intel processors maximum improvement is ~50%, while on Ryzen - 80%. The "secret" is new dedicated ChaCha20_128 code path and vectorized xor helpers. Reviewed-by:
-
- Jun 29, 2018
-
-
Andy Polyakov authored
Inputs not longer than 64 bytes are processed ~10% faster, longer lengths not divisble by 64, e.g. 255, up to ~20%. Unfortunately it's impossible to measure with apps/speed.c, -aead benchmarks TLS-like call sequence, but not exact. It took specially crafted code path... Reviewed-by:
-
- Jun 20, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
- Jun 19, 2018
-
-
Jack Lloyd authored
Use EVP_PKEY_set_alias_type to access Reviewed-by:
-
Jack Lloyd authored
Reviewed-by:
-
- Jun 18, 2018
-
-
David von Oheimb authored
Reviewed-by:
-
- Jun 08, 2018
-
-
Matt Caswell authored
Only applies to algorithms that support it. Both raw private and public keys can be obtained for X25519, Ed25519, X448, Ed448. Raw private keys only can be obtained for HMAC, Poly1305 and SipHash Fixes #6259 Reviewed-by:
-
- Jun 03, 2018
-
-
Andy Polyakov authored
Even though calls can be viewed as styling improvement, they do come with cost. It's not big cost and shows only on short inputs, but it is measurable, 2-3% on some platforms. Reviewed-by:
-
- Apr 17, 2018
-
-
Richard Levitte authored
Reviewed-by:
-
- Apr 13, 2018
-
-
Matt Caswell authored
Historically we used to implement standalone base64 code for SRP. This was replaced by commit 3d3f21aa with the standard base64 processing code. However, the SRP base64 code was designed to be compatible with other SRP libraries (notably libsrp, but also others) that use a variant of standard base64. Specifically a different alphabet is used and no padding '=' characters are used. Instead 0 padding is added to the front of the string. By changing to standard base64 we change the behaviour of the API which may impact interoperability. It also means that SRP verifier files created prior to 1.1.1 would not be readable in 1.1.1 and vice versa. Instead we expand our standard base64 processing with the capability to be able to read and generate the SRP base64 variant. Reviewed-by:
-
Matt Caswell authored
Previously they were using EVP_EncodeBlock/EVP_DecodeBlock. These are low level functions that do not handle padding characters. This was causing the SRP code to fail. One side effect of using EVP_EncodeUpdate is that it inserts newlines which is not what we need in SRP so we add a flag to avoid that. Reviewed-by:
-
