EVP_DigestInit_ex forced following of the legacy path if ctx->pctx is
set (meaning we've actually been called via EVP_DigestSignInit_ex).
There is some code in the legacy path that calls the
EVP_PKEY_CTRL_DIGESTINIT ctrl on the pctx. Not going down the legacy path
if ctx->pctx is set means that ctrl message will neve get sent. However,
it turns out that all algs that understand that ctrl also set the
EVP_MD_CTX_FLAG_NO_INIT flag which forces legacy anyway. Therefore the
ctx->pctx check is not required and can be removed.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10082)
Otherwise a mem leak can occur since EVP_MD_free() calls
EVP_MD_CTX_reset() which then clears the contents of the ctx.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
This resets the fields of the EVP_MD_CTX and means we can no longer
make calls using the EVP_MD_CTX, such as to query parameters.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
If doing an EVP_DigestSign*() or EVP_DigestVerify*() operation we use
the embedded pctx for communication with the provider. Any MD params need
to use that ctx instead.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
This flag is still relevant even for non-legacy code so we should check
it where appropriate.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10029)
So far, these two funtions have depended on legacy EVP_CIPHER
implementations to be able to do their work. This change adapts them
to work with provided implementations as well, in one of two possible
ways:
1. If the implementation's set_asn1_parameters or get_asn1_parameters
function pointers are non-NULL, this is a legacy implementation,
and that function is called.
2. Otherwise, if the cipher doesn't have EVP_CIPH_FLAG_CUSTOM_ASN1
set, the default AlgorithmIdentifier parameter code in libcrypto
is executed.
3. Otherwise, if the cipher is a provided implementation, the ASN1
type structure is converted to a DER blob which is then passed to
the implementation as a parameter (param_to_asn1) or the DER blob
is retrieved from the implementation as a parameter and converted
locally to a ASN1_TYPE (asn1_to_param).
With this, the old flag EVP_CIPH_FLAG_DEFAULT_ASN1 has become
irrelevant and is simply ignored.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10008)
Several EVP_PKEY_xxxx functions return 0 and a negative value for
indicating errors. Some places call these functions with a zero return
value check only, which misses the check for the negative scenarios.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10055)
Unset data defaults to the empty string ("") or 0.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9948)
All instances of EVP_*_CTX_gettable_params functions have been renamed
to EVP_*_gettable_ctx_params. Except for the EVP_MD ones which were changed
already.
These functions do not take EVP_*_CTX arguments so their prior naming was
misleading.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10052)
Make the include guards consistent by renaming them systematically according
to the naming conventions below
For the public header files (in the 'include/openssl' directory), the guard
names try to match the path specified in the include directives, with
all letters converted to upper case and '/' and '.' replaced by '_'. For the
private header files files, an extra 'OSSL_' is added as prefix.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Implement SP800-108 section 5.1 with HMAC intended for use in Kerberos.
Add test vectors from RFC 8009.
Adds error codes PROV_R_INVALID_MAC and PROV_R_MISSING_MAC.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9924)
Also includes CRMF (RFC 4211) and HTTP transfer (RFC 6712)
CMP and CRMF API is added to libcrypto, and the "cmp" app to the openssl CLI.
Adds extensive man pages and tests. Integration into build scripts.
Incremental pull request based on OpenSSL commit 8869ad4a39 of 2019-04-02
4th chunk: CMP context/parameters and utilities
in crypto/cmp/cmp_ctx.c, crypto/cmp/cmp_util.c, and related files
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9107)
This makes the legacy provider available regardless of building conditions.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9637)
using PCC and KDSA instructions.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10004)
of instruction parameter blocks.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10004)
EVP_MD_CTX_gettable_params() and EVP_MD_CTX_settable_params() were
confusingly named because they did not take an EVP_MD_CTX parameter.
In addition we add the functions EVP_MD_gettable_ctx_params() and
EVP_MD_settable_ctx_params() which do the same thing but are passed
an EVP_MD object instead.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9998)
The supported variants are
- SmtpUTF8Name
- xmppAddr
- MS UPN
- SRVName
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9965)
With multiple names, it's no longer viable to just grab the "first" in
the set and use that to find the legacy NID. Instead, all names for
an algorithm must be checked, and if we encounter more than one NID
asssociated with those names, we consider it an error and make that
method unloadable.
This ensures that all methods that do have an internal NID associated
will get that NID in their structure, thereby ensuring that other
parts of libcrypto that haven't gone away from using NIDs for
comparison will continue to work as expected.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9969)
The issue was encountered when testing parallel builds of OpenSSL on
Windows using `jom` instead of `nmake`. The builds persistently failed
with the following error message because the generated file "buildinf.h"
did not exist yet.
crypto\info.c(15): fatal error C1083:
cannot open include file: "buildinf.h": No such file or directory
Apparently this error does not occur on Linux because `make` parallelizes
the builds differently such that `crypto\cversion.c`, which has an
explicit dependency on `buildinf.h`, gets compiled first. Also, the
include dependency was added only recently in commit 096978f099.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9960)
It either makes the flow of control simpler and more obvious, or it is
just a "cleanup" so that the editing scripts will find and fixup things.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9441)
With some provider implementations, there are underlying ciphers,
digests and macs. For some of them, the name was retrieved from the
method, but since the methods do not store those any more, we add
different mechanics.
For code that needs to pass on the name of a cipher or diges via
parameters, we simply locally store the name that was used when
fetching said cipher or digest. This will ensure that any underlying
code that needs to fetch that same cipher or digest does so with the
exact same name instead of any random name from the set of names
associated with the algorithm.
For code that needs to check what kind of algorithm was passed, we
provide EVP_{type}_is_a(), that returns true if the given method has
the given name as one of its names.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
They now generally conform to the following argument sequence:
script.pl "$(PERLASM_SCHEME)" [ C preprocessor arguments ... ] \
$(PROCESSOR) <output file>
However, in the spirit of being able to use these scripts manually,
they also allow for no argument, or for only the flavour, or for only
the output file. This is done by only using the last argument as
output file if it's a file (it has an extension), and only using the
first argument as flavour if it isn't a file (it doesn't have an
extension).
While we're at it, we make all $xlate calls the same, i.e. the $output
argument is always quoted, and we always die on error when trying to
start $xlate.
There's a perl lesson in this, regarding operator priority...
This will always succeed, even when it fails:
open FOO, "something" || die "ERR: $!";
The reason is that '||' has higher priority than list operators (a
function is essentially a list operator and gobbles up everything
following it that isn't lower priority), and since a non-empty string
is always true, so that ends up being exactly the same as:
open FOO, "something";
This, however, will fail if "something" can't be opened:
open FOO, "something" or die "ERR: $!";
The reason is that 'or' has lower priority that list operators,
i.e. it's performed after the 'open' call.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9884)
