Setting the SipHash hash size and setting its key is done with two
independent functions... and yet, the internals depend on both.
Unfortunately, the function to change the size wasn't adapted for the
possibility that the key was set first, with a different hash size.
This changes the hash setting function to fix the internal values
(which is easy, fortunately) according to the hash size.
evpmac.txt value for digestsize:8 is also corrected.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7613)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/7599)
Rather than relying only on mandatory default digests, add a way for
the EVP_PKEY to individually report whether each digest algorithm is
supported.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7408)
ASN1_PKEY_CTRL_DEFAULT_MD_NID is documented to return 2 for a mandatory
digest algorithm, when the key can't support any others. That isn't true
here, so return 1 instead.
Partially fixes#7348
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7408)
Commit c7504aeb64 (pr #6432) fixed a regression for applications in
chroot environments, which compensated the fact that the new OpenSSL CSPRNG
(based on the NIST DRBG) now reseeds periodically, which the previous
one didn't. Now the reseeding could fail in the chroot environment if the
DEVRANDOM devices were not present anymore and no other entropy source
(e.g. getrandom()) was available.
The solution was to keep the file handles for the DEVRANDOM devices open
by default. In fact, the fix did more than this, it opened the DEVRANDOM
devices early and unconditionally in rand_pool_init(), which had the
unwanted side effect that the devices were opened (and kept open) even
in cases when they were not used at all, for example when the getrandom()
system call was available. Due to a bug (issue #7419) this even happened
when the feature was disabled by the application.
This commit removes the unconditional opening of all DEVRANDOM devices.
They will now only be opened (and kept open) on first use. In particular,
if getrandom() is available, the handles will not be opened unnecessarily.
This change does not introduce a regression for applications compiled for
libcrypto 1.1.0, because the SSLEAY RNG also seeds on first use. So in the
above constellation the CSPRNG will only be properly seeded if it is happens
before the forking and chrooting.
Fixes#7419
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7437)
... to make the intended use more clear and differentiate
it from the data member "adin_pool".
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7575)
We kept a number of arrays of directory names to keep track of exactly
which directories to look for build.info. Some of these had the extra
function to hold the directories to actually build.
With the added SUBDIRS keyword, these arrays are no longer needed.
The logic for skipping certain directories needs to be kept, though.
That is now very much simplified, and is made opportunistic.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7558)
Remove GMAC demo program because it has been superceded by the EVP MAC one
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7548)
If engine building fails for some reason, we must make sure to close
the /dev/crypto handle.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7506)
We opened /dev/crypto once for each session, which is quite unnecessary.
With this change, we open /dev/crypto once at engine init, and close
it on unload.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7506)
Copying an EVP_MD_CTX, including the implementation local bits, is a
necessary operation. In this case, though, it's the same as
initializing the local bits to be "copied to".
Fixes#7495
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7506)
The EVP_PKEY methods for CMAC and HMAC needed a rework, although it
wasn't much change apart from name changes.
This also meant that EVP_PKEY_new_CMAC_key() needed an adjustment.
(the possibility to rewrite this function to work with any MAC is yet
to be explored)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7484)
dsa_builtin_paramgen2 expects the L parameter to be greater than N,
otherwise the generation will get stuck in an infinite loop.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7493)
These functions are generalizations of EVP_PKEY_CTX_str2ctrl() and
EVP_PKEY_CTX_hex2ctrl(). They will parse the value, and then pass the
parsed result and length to a callback that knows exactly how to pass
them on to a main _ctrl function, along with a context structure
pointer.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7393)
The MAC EVP_PKEY implementations are currently implemented for each
MAC. However, with the EVP_MAC API, only one such implementation is
needed.
This implementation takes into account the differences between HMAC
and CMAC implementations, and observes that all other current MAC
implementations seem to follow the HMAC model.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7393)
We currently implement EVP MAC methods as EVP_PKEY methods. This
change creates a separate EVP API for MACs, to replace the current
EVP_PKEY ones.
A note about this EVP API and how it interfaces with underlying MAC
implementations:
Other EVP APIs pass the EVP API context down to implementations, and
it can be observed that the implementations use the pointer to their
own private data almost exclusively. The EVP_MAC API deviates from
that pattern by passing the pointer to the implementation's private
data directly, and thereby deny the implementations access to the
EVP_MAC context structure. This change is made to provide a clearer
separation between the EVP library itself and the implementations of
its supported algorithm classes.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7393)
Preallocate an extra limb for some of the big numbers to avoid a reallocation
that can potentially provide a side channel.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7486)
Avoid a timing attack that leaks information via a side channel that
triggers when a BN is resized. Increasing the size of the BNs
prior to doing anything with them suppresses the attack.
Thanks due to Samuel Weiser for finding and locating this.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7486)
There is a side channel attack against the division used to calculate one of
the modulo inverses in the DSA algorithm. This change takes advantage of the
primality of the modulo and Fermat's little theorem to calculate the inverse
without leaking information.
Thanks to Samuel Weiser for finding and reporting this.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7487)
Found by Coverity Scan
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7511)
The Name Constraints extension contains GeneralSubtree values
indicating included or excluded subtrees. It is defined as:
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
RFC 5280 further specifies:
Within this profile, the minimum and maximum fields are not used with
any name forms, thus, the minimum MUST be zero, and maximum MUST be
absent.
Because the minimum fields has DEFAULT 0, and certificates should be
encoded using DER, the situation where minimum = 0 occurs in a
certificate should not arise. Nevertheless, it does arise. For
example, I have seen certificates issued by Microsoft programs that
contain GeneralSubtree values encoded thus.
Enhance the Name Constraints matching routine to handle the case
where minimum is specified. If present, it must be zero. The
maximum field remains prohibited.
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7039)
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7474)
Commit 5b4cb385c1 (#7382) introduced a bug which had the effect
that RAND_add()/RAND_seed() failed for buffer sizes less than
32 bytes. The reason was that now the added random data was used
exlusively as entropy source for reseeding. When the random input
was too short or contained not enough entropy, the DRBG failed
without querying the available entropy sources.
This commit makes drbg_add() act smarter: it checks the entropy
requirements explicitely. If the random input fails this check,
it won't be added as entropy input, but only as additional data.
More precisely, the behaviour depends on whether an os entropy
source was configured (which is the default on most os):
- If an os entropy source is avaible then we declare the buffer
content as additional data by setting randomness to zero and
trigger a regular reseeding.
- If no os entropy source is available, a reseeding will fail
inevitably. So drbg_add() uses a trick to mix the buffer contents
into the DRBG state without forcing a reseeding: it generates a
dummy random byte, using the buffer content as additional data.
Related-to: #7449
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7456)
