Provide backwards-compatiblity for functions, macros and include
files if OPENSSL_API_COMPAT is either not defined or defined less
than the version number of the release in which the feature was
deprecated.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

Continuing from previous commit ensure our style is consistent for malloc
return checks.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

All instances of SSLeay (any combination of case) were replaced with
the case-equivalent OpenSSL.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

There are header files in crypto/ that are used by a number of crypto/
submodules.  Move those to crypto/include/internal and adapt the
affected source code and Makefiles.

The header files that got moved are:

crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: NRich Salz <rsalz@openssl.org>

Add OPENSSL_clear_free which merges cleanse and free.
(Names was picked to be similar to BN_clear_free, etc.)
Removed OPENSSL_freeFunc macro.
Fixed the small simple ones that are left:
        CRYPTO_free CRYPTO_free_locked OPENSSL_free_locked
Reviewed-by: NRichard Levitte <levitte@openssl.org>

The justification for RAND_pseudo_bytes is somewhat dubious, and the reality
is that it is frequently being misused. RAND_bytes and RAND_pseudo_bytes in
the default implementation both end up calling ssleay_rand_bytes. Both may
return -1 in an error condition. If there is insufficient entropy then
both will return 0, but RAND_bytes will additionally add an error to the
error queue. They both return 1 on success.
Therefore the fundamental difference between the two is that one will add an
error to the error queue with insufficient entory whilst the other will not.
Frequently there are constructions of this form:

if(RAND_pseudo_bytes(...) <= 1)
	goto err;

In the above form insufficient entropy is treated as an error anyway, so
RAND_bytes is probably the better form to use.

This form is also seen:
if(!RAND_pseudo_bytes(...))
	goto err;

This is technically not correct at all since a -1 return value is
incorrectly handled - but this form will also treat insufficient entropy as
an error.

Within libssl it is required that you have correctly seeded your entropy
pool and so there seems little benefit in using RAND_pseudo_bytes.
Similarly in libcrypto many operations also require a correctly seeded
entropy pool and so in most interesting cases you would be better off
using RAND_bytes anyway. There is a significant risk of RAND_pseudo_bytes
being incorrectly used in scenarios where security can be compromised by
insufficient entropy.

If you are not using the default implementation, then most engines use the
same function to implement RAND_bytes and RAND_pseudo_bytes in any case.

Given its misuse, limited benefit, and potential to compromise security,
RAND_pseudo_bytes has been deprecated.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

If available rdrand is used as an additional entropy source for the
PRNG and for additional input in FIPS mode.

Reported by: Tomas Mraz <tmraz@redhat.com>

Treat a NULL value passed to drbg_free_entropy callback as non-op. This
can happen if the call to fips_get_entropy fails.

FIPS library to fail. Applications that want to set the FIPS rand method can do
so explicitly and presumably they know what they are doing...

callback.

Handle case where no multiple of the block size is in the interval
[min_len, max_len].

to specify a "block length".

Set FIPS RAND_METHOD at same time as OpenSSL RAND_METHOD.

now use an internal RAND_METHOD. All dependencies to OpenSSL standard
PRNG are now removed: it is the applications resposibility to setup
the FIPS PRNG and initalise it.

Initial OpenSSL RAND_init_fips() function that will setup the DRBG
for the "FIPS capable OpenSSL".

need a whole new PRNG for FIPS).

1. avoid use of ERR_peek().

2. If compiling with FIPS use small FIPS EVP and disable ENGINE

knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.

Note: the RAND_bytes() manual page says:
 RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf.
It does not talk about using the previous contents of buf so we are working
as documented.

PR: 287

ENGINE surgery. DH, DSA, RAND, and RSA now use *both* "method" and ENGINE
pointers to manage their hooking with ENGINE. Previously their use of
"method" pointers was replaced by use of ENGINE references. See
crypto/engine/README for details.

Also, remove the ENGINE iterations from evp_test - even when the
cipher/digest code is committed in, this functionality would require a
different set of API calls.

Fix memory leak when RAND is used: need to cleanup
RANDs ENGINE reference in ENGINE_cleanup().

ENGINE code does not return a default, set an error.

Previously RAND_get_rand_method was returning a non-const pointer, but it
should be const. As with all other such cases, METHOD pointers are stored and
returned as "const". The only methods one should be able to alter are methods
"local" to the relevant code, in which case a non-const handle to the methods
should already exist.

This change has been forced by the constifying of the ENGINE code (before
which RAND_METHOD was the only method pointer in an ENGINE structure that was
not constant).

At the same time, add VMS support for Rijndael.

instead of 'unsigned' counters.
Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp.

Partially submitted by Yoram Meroz <yoram@mail.idrive.com>.

are not guaranteed to be unpredictable.

returns int (1 = ok, 0 = not seeded). New function RAND_add() is the
same as RAND_seed() but takes an estimate of the entropy as an additional
argument.

This will soon be complemented with MacOS specific source code files and
INSTALL.MacOS.

I (Andy) have decided to get rid of a number of #include <sys/types.h>.
I've verified it's ok (both by examining /usr/include/*.h and compiling)
on a number of Unix platforms. Unfortunately I don't have Windows box
to verify this on. I really appreciate if somebody could try to compile
it and contact me a.s.a.p. in case a problem occurs.

Submitted by: Roy Wood <roy@centricsystems.ca>
Reviewed by: Andy Polyakov <appro@fy.chalmers.se>

Submitted by:
Reviewed by:
PR: