While CCM is available in earlier versions, we only use it with
OpenSSL 1.1.0 and newer because the generic control variables are not
available before and we default to GCM for them.
Closesstrongswan/strongswan#353.
If we pass a pointer to NULL, the memory allocated by OpenSSL has to be
freed with OPENSSL_free(). Otherwise, this can lead to random
crashes/freezes for Windows builds as seen on AppVeyor. To not
complicate things for callers of this macro, we allocate our own memory,
which we already do for other i2d_* calls.
If no valid key is configured (e.g. because it's inadvertently uninitialized),
we should not just reuse the previous key.
The `key_set` flag is not necessary anymore because a non-NULL key is set
during initialization since 6b347d5232 ("openssl: Ensure underlying hash
algorithm is available during HMAC init").
Apparently, we should use OPENSSL_free() to release memory allocated by
OpenSSL. While it generally maps to free() that's apparently not the
case on Windows, where the ECP test vectors caused `ACCESS_VIOLATION
exception` crashes (not always the same vector).
Fixes: 74e02ff5e6 ("openssl: Mainly use EVP interface for ECDH")
Functions like ECDH_compute_key() will be removed with OpenSSL 3 (which
will require additional changes as other functions will be deprecated or
removed too).
ECDH_compute_key() was not used because it only gives x-coordinate of
the result. However, the default setting, as per the errata mentioned,
is to use x-coordinate only.
Use ECDH_compute_key() for this setting as it additionally allows HW
offload of the computation using dynamic engine feature in OpenSSL.
EC_POINT_mul() doesn't allow HW offload.
Signed-off-by: Mahantesh Salimath <[email protected]>
The x509 plugin accepted CRL signers since forever, to be precise, since
dffb176f2b ("CRLSign keyUsage or CA basicConstraint are sufficient
for CRL validation")).
References #3529.
OpenSSL currently doesn't support squeezing bytes out of an XOF multiple
times. Unfortunately, EVP_DigestFinalXOF() completely resets the context
and later calls not simply fail, they cause a null-pointer dereference in
libcrypto. This fixes the crash at the cost of repeating initializing
the whole state and allocating too much data for subsequent calls.
There is an open issue and PR that might add a function that allows
squeezing more data from an XOF in a future version of OpenSSL.
Doing this for the self-signed check also (i.e. if this and issuer are
the same) is particularly useful if the issuer uses a different key type.
Otherwise, we'd try to verify the signature with an incompatible key
that would result in a log message.
Fixes#3357.
Without this we only would learn that the algorithm isn't actually
available (e.g. due to FIPS mode) when set_key() is called later, so there
isn't any automatic fallback to other implementations.
Fixes#3284.
According to the documentation, it's generally not necessary to manually
seed OpenSSL's DRBG (and it actually can cause the daemon to lock up
during start up on systems with low entropy if OpenSSL is already trying
to seed it itself and holds the lock). While that might already have been
the case with earlier versions, it's not explicitly stated in their
documentation. So we keep the code for these versions.
The functional reference created by ENGINE_init() was never released,
only the structural one created by ENGINE_by_id(). The functional
reference includes an implicit structural reference, which is also
released by ENGINE_finish().
Closesstrongswan/strongswan#119.
OpenSSL 1.1.1 introduces DRGBs and provides two sources (same security
profile etc. but separate internal state), which allows us to use one for
RNG_WEAK (e.g. for nonces that are directly publicly visible) and the other
for stronger random data like keys.
While X25519 was already added with 1.1.0a, its use would be a lot more
complicated, as the helpers like EVP_PKEY_new_raw_public_key() were only
added in 1.1.1, which also added X448.
In theory we should treat any parameters and the identifier itself as
restriction to only use the key to create signatures accordingly (e.g.
only use RSA with PSS padding or even use specific hash algorithms).
But that's currently tricky as we'd have to store and pass this information
along with our private keys (i.e. use PKCS#8 to store them and change the
builder calls to pass along the identifier and parameters). That would
require quite some work.
Adrian-Ken Rueegsegger