Note a flag needed to be added since some ssl tests fail if they output any error
(even if the error is ignored). Only ciphers that handle the GET_IV_LEN control set this flag.

Fixes #8330
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9499)

Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7113)

zero-length ID is allowed, but it's not allowed to skip the ID.

Fixes: #6534
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7113)

Thus users can use this function to set customized EVP_PKEY_CTX to
EVP_MD_CTX structure.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7113)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6538)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6217)

Since return is inconsistent, I removed unnecessary parentheses and
unified them.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4541)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2134)

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

We had the function EVP_CIPHER_CTX_cipher_data which is newly added for
1.1.0. As we now also need an EVP_CIPHER_CTX_set_cipher_data it makes
more sense for the former to be called EVP_CIPHER_CTX_get_cipher_data.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Implement aes128-cbc as a pipeline capable cipher in the dasync engine.
As dasync is just a dummy engine, it actually just performs the parallel
encrypts/decrypts in serial.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Don't cast malloc-family return values.
Also found some places where (a) blank line was missing; and (b)
the *wrong* return value was checked.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

This was done by the following
        find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
        print unless $. == 1 && m@/\* .*\.[ch] \*/@;
        close ARGV if eof; # Close file to reset $.

And then some hand-editing of other files.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

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

We follow the method used for EVP_MD.
Also, move all the internal EVP_CIPHER building macros from evp_locl.h
to evp_int.h.  This will benefit our builtin EVP_CIPHERs.
Reviewed-by: NRich Salz <rsalz@openssl.org>

EVP_CIPHER_CTX_flags was returning the flags of its associated
EVP_CIPHER.  However, EVP_CIPHER_CTX has flags of its own, so this
function is quite confusing and therefore error prone.
Reviewed-by: NRich Salz <rsalz@openssl.org>

New functions:

- EVP_CIPHER_CTX_encrypting()
- EVP_CIPHER_CTX_iv()
- EVP_CIPHER_CTX_iv_noconst()
- EVP_CIPHER_CTX_original_iv()
- EVP_CIPHER_CTX_buf_noconst()
- EVP_CIPHER_CTX_num()
- EVP_CIPHER_CTX_set_num()
- EVP_CIPHER_CTX_cipher_data()
- EVP_CIPHER_CTX_new_cipher_data()

Note that the accessors / writers for iv, buf and num may go away, as
those rather belong in the implementation's own structure (cipher_data)
when the implementation would affect them (that would be the case when
they are flagged EVP_CIPH_CUSTOM_IV or EVP_CIPH_FLAG_CUSTOM_CIPHER).
Reviewed-by: NRich Salz <rsalz@openssl.org>

This moves the definition to crypto/include/internal/evp_int.h and
defines all the necessary method creators, destructors, writers and
accessors.  The name standard for the latter is inspired from the
corresponding functions to manipulate UI methods.
Reviewed-by: NRich Salz <rsalz@openssl.org>

This moves the definitionto crypto/evp/evp_locl.h, along with a few
associated accessor macros.  A few accessor/writer functions added.
Reviewed-by: NRich Salz <rsalz@openssl.org>

RFC5753 requires that we omit parameters for AES key wrap and set them
to NULL for 3DES wrap. OpenSSL decrypt uses the received algorithm
parameters so can transparently handle either form.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

PR#3974
PR#3975
Reviewed-by: NMatt Caswell <matt@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>

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

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

Check and set AlgorithmIdenfier parameters for key wrap algorithms.
Currently these just set parameters to NULL.

Set EVP_CIPH_FLAG_FIPS on approved ciphers.

Support "default ASN1" flag which avoids need for ASN1 dependencies in FIPS
code.

Include some defines to redirect operations to a "tiny EVP" implementation
in some FIPS source files.

Change m_sha1.c to use EVP_PKEY_NULL_method: the EVP_MD sign/verify functions
are not used in OpenSSL 1.0 and later for SHA1 and SHA2 ciphers: the EVP_PKEY
API is used instead.

later.

Add Triple DES CFB1 and CFB8 to algorithm list and NID translation.

test for them!

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.

Submitted by: Tracy Camp <tracyx.e.camp@intel.com>

Add the corresponding AES parts while I'm at it.
make update

I have tried to convert 'len' type variable declarations to unsigned as a
means to address these warnings when appropriate, but when in doubt I have
used casts in the comparisons instead. The better solution (that would get
us all lynched by API users) would be to go through and convert all the
function prototypes and structure definitions to use unsigned variables
except when signed is necessary. The proliferation of (signed) "int" for
strictly non-negative uses is unfortunate.