Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Due to short-circuiting we only need to check "cipher" for NULL once.

PR#699
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Add a status return value instead of void.
Add some sanity checks on reference counter value.
Update the docs.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

No code change
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

- Missing checks for allocation failure.
- releasing memory in few missing error paths
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

The default ASN.1 handling can be used for SEED. This also makes
CMS work with SEED.

PR#4504
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

CVE-2016-2107

MR: #2572

With the EVP_EncodeUpdate function it is the caller's responsibility to
determine how big the output buffer should be. The function writes the
amount actually used to |*outl|. However this could go negative with a
sufficiently large value for |inl|. We add a check for this error
condition.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

An overflow can occur in the EVP_EncodeUpdate function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption. Due to the very large amounts of data involved this will most
likely result in a crash.

Internally to OpenSSL the EVP_EncodeUpdate function is primarly used by the
PEM_write_bio* family of functions. These are mainly used within the
OpenSSL command line applications, so any application which processes
data from an untrusted source and outputs it as a PEM file should be
considered vulnerable to this issue.

User applications that call these APIs directly with large amounts of
untrusted data may also be vulnerable.

Issue reported by Guido Vranken.

CVE-2016-2105
Reviewed-by: NRichard Levitte <levitte@openssl.org>

An overflow can occur in the EVP_EncryptUpdate function. If an attacker is
able to supply very large amounts of input data after a previous call to
EVP_EncryptUpdate with a partial block then a length check can overflow
resulting in a heap corruption.

Following an analysis of all OpenSSL internal usage of the
EVP_EncryptUpdate function all usage is one of two forms.

The first form is like this:
EVP_EncryptInit()
EVP_EncryptUpdate()

i.e. where the EVP_EncryptUpdate() call is known to be the first called
function after an EVP_EncryptInit(), and therefore that specific call
must be safe.

The second form is where the length passed to EVP_EncryptUpdate() can be
seen from the code to be some small value and therefore there is no
possibility of an overflow.

Since all instances are one of these two forms, I believe that there can
be no overflows in internal code due to this problem.

It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate()
in certain code paths. Also EVP_CipherUpdate() is a synonym for
EVP_EncryptUpdate(). Therefore I have checked all instances of these
calls too, and came to the same conclusion, i.e. there are no instances
in internal usage where an overflow could occur.

This could still represent a security issue for end user code that calls
this function directly.

CVE-2016-2106

Issue reported by Guido Vranken.
Reviewed-by: NTim Hudson <tjh@openssl.org>

This macro was defined by no-longer-supported __MWERKS__ compiler.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Currently we can get all block ciphers with
	EVP_get_cipherbyname("<alg_name>-<block-mode-name>")
for example, by names "aes-128-ecb" or "des-ede-cbc".
I found a problem with des-ede-ecb and des-ede3-ecb ciphers as
they can be accessed only with names:
	EVP_get_cipherbyname("des-ede")
	EVP_get_cipherbyname("des-ede3")
It breaks the general concept.

In this patch I add aliases which allow to use names:
	EVP_get_cipherbyname("des-ede-ecb")
	EVP_get_cipherbyname("des-ede3-ecb")
in addition to the currently used names.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

The Unix build was the last to retain the classic build scheme.  The
new unified scheme has matured enough, even though some details may
need polishing.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Give the API new names, document it.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Make OBJ_name_cmp internal
Rename idea_xxx to IDEA_xxx
Rename get_rfc_xxx to BN_get_rfc_xxx
Rename v3_addr and v3_asid functions to X509v3_...
Reviewed-by: NRichard Levitte <levitte@openssl.org>

no-sha is no longer an option so remove OPENSSL_NO_SHA guards.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

no-aes is no longer a Configure option and therefore the OPENSSL_NO_AES
guards can be removed.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

The check_defer() function was used to ensure that EVP_cleanup() was always
called before OBJ_cleanup(). The new cleanup code ensures this so it is
no longer needed.

Remove obj_cleanup() call in OID config module: it is not needed
any more either.
Reviewed-by: NMatt Caswell <matt@openssl.org>

There is a preference for suffixes to indicate that a function is internal
rather than prefixes. Note: the suffix is only required to disambiguate
internal functions and public symbols with the same name (but different
case)
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

There was a lot of naming inconsistency, so we try and standardise on
one form.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

OBJ_cleanup() should not be called expicitly - we should leave
auto-deinit to clean this up instead.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

EVP_cleanup() should not be called expicitly - we should leave
auto-deinit to clean this up instead.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Move the the BIO_METHOD and BIO structures into internal header files,
provide appropriate accessor methods and update all internal code to use
the new accessors where appropriate.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

BIO_new, etc., don't need a non-const BIO_METHOD. This allows all the
built-in method tables to live in .rodata.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Fix compilation with --strict-warnings and no-seed
Reviewed-by: NRich Salz <rsalz@openssl.org>

This removes all scripts that deal with MINFO as well, since that's
only used by mk1mf.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Don't have #error statements in header files, but instead wrap
the contents of that file in #ifndef OPENSSL_NO_xxx
This means it is now always safe to include the header file.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

There were a couple of CMAC references without OPENSSL_NO_CMAC guards.
Reviewed-by: NRich Salz <rsalz@openssl.org>

OCB is AEAD capable but was not marked as such with the
EVP_CIPH_FLAG_AEAD_CIPHER flag.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

There is a potential double free in EVP_DigestInit_ex. This is believed
to be reached only as a result of programmer error - but we should fix it
anyway.

Issue reported by Guido Vranken.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

crypto/evp/e_aes.c and crypto/modes/gcm128.c include ppc_arch.h, which
is located in crypto/, so add that as extra include directory for them.

Issue reported by Jeffrey Walton <noloader@gmail.com>
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>