Change ML-KEM and ML-DSA from enabled-by-default to disabled-by-default.
Replace negative guards (OPENSSL_NO_ML_KEM/ML_DSA) with positive opt-in
guards (OPENSSL_ML_KEM/ML_DSA) across all provider and encoder/decoder code.
Users must explicitly enable via Configure options:
./Configure ... enable-ml-kem enable-ml-dsa
Configure changes:
- Add ml-kem/ml-dsa to %disabled hash with 'default' reason
- Skip OPENSSL_NO_ macro generation for these features
- Define OPENSSL_ML_KEM/ML_DSA when user enables them
Signed-off-by: kang1024 <yangjiankang3@huawei.com>
Port ML-KEM (FIPS 203) and ML-DSA (FIPS 204) post-quantum cryptography
from OpenSSL 3.5.6 to OpenSSL 3.0.9 with API compatibility adaptations.
Key compatibility shims:
- Add include/openssl/byteorder.h (OPENSSL_load/store_u{16,32,64}_le)
- Add include/internal/fips.h (ossl_fips_self_testing() inline stub)
- Map EVP_DigestSqueeze() to EVP_DigestFinalXOF() + large buffer
- Map EVP_MD_xof() to EVP_MD flags check
- Map OSSL_FUNC_SIGNATURE_SIGN/VERIFY_MESSAGE_INIT dispatch IDs to
existing SIGN_INIT/VERIFY_INIT (2/4)
- Map EVP_PKEY_sign/verify_message_init() to sign/verify_init_ex()
- Add OSSL_SIGNATURE_PARAM_MU constant
- Add OSSL_FUNC typedef + OSSL_DISPATCH_END macro
- Use correct NID names (NID_id_alg_ml_dsa_44 vs NID_ML_DSA_44)
Provider registrations:
- ML-KEM KEM, ML-KEM/ML-DSA keymgmt, ML-DSA signature providers
- ML-KEM/ML-DSA encoders/decoders (der/pem/text for pub/priv/pkcs8)
- ML-KEM TLS group capabilities
Build system fixes:
- Add providers/common/provider_ctx.c with get_param/bool_param stubs
- Fix DER build.info $COMMON variable override order
- Fix decode_der2key.c PROV_CTX vs OSSL_LIB_CTX type mismatch (6 calls)
- Link ML tests against libcrypto.a (not .so) for internal symbols
- Remove references to missing der_ml_kem_{gen,key}.c
Adapt BUILD.gn for OpenHarmony:
- Add 18 new source files across three build sections (libcommon, libdefault,
crypto_source) to support ML-KEM/ML-DSA in the OpenHarmony/OHOS build system.
Test infrastructure:
- Add 3 test recipes (evp_extra_ml_kem, internal_ml_kem, ml_dsa)
- Add #include "internal/nelem.h" for OSSL_NELEM in test files
- Add LABELED_BUF_PRINT_WIDTH definition for codec text output
All 253 tests pass (3374 test cases), 0 compilation warnings.
Signed-off-by: kang1024 <yangjiankang3@huawei.com>
There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In particular
the NIST P-521 curve is affected. To be able to measure this leak, the
attacker process must either be located in the same physical computer or
must have a very fast network connection with low latency.
Attacks on ECDSA nonce are also known as Minerva attack.
Fixes CVE-2024-13176
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26429)
(cherry picked from commit 63c40a66c5dc287485705d06122d3a6e74a6a203)
Signed-off-by: lcc <lichaochen@huawei.com>
And create a new BN_generate_dsa_nonce() that corrects the BIGNUM top.
We do this to avoid leaking fixed top numbers via the public API.
Also add a slight optimization in ossl_bn_gen_dsa_nonce_fixed_top()
and make it LE/BE agnostic.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(cherry picked from commit 9c85f6cd2d6debe5ef6ef475ff4bf17e0985f7a2)
(Merged from https://github.com/openssl/openssl/pull/24317)
(cherry picked from commit fdc3efc371be43d5092bb19823e084f54541cbe3)
Signed-off-by: lcc <lichaochen@huawei.com>
If a malformed config file is provided such as the following:
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
= provider_sect
The config parsing library will crash overflowing the stack, as it
recursively parses the same provider_sect ad nauseum.
Prevent this by maintaing a list of visited nodes as we recurse through
referenced sections, and erroring out in the event we visit any given
section node more than once.
Note, adding the test for this revealed that our diagnostic code
inadvertently pops recorded errors off the error stack because
provider_conf_load returns success even in the event that a
configuration parse failed. The call path to provider_conf_load has been
updated in this commit to address that shortcoming, allowing recorded
errors to be visibile to calling applications.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/23120)
Signed-off-by: hhhFun <fanghaojie@huawei.com>
We already check for an excessively large P in DH_generate_key(), but not in
DH_check_pub_key(), and none of them check for an excessively large Q.
This change adds all the missing excessive size checks of P and Q.
It's to be noted that behaviours surrounding excessively sized P and Q
differ. DH_check() raises an error on the excessively sized P, but only
sets a flag for the excessively sized Q. This behaviour is mimicked in
DH_check_pub_key().
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22518)
(cherry picked from commit ddeb4b6c6d527e54ce9a99cba785c0f7776e54b6)
Signed-off-by: code4lala <fengziteng2@huawei.com>
The DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus
value even if it is excessively large.
There is already a maximum DH modulus size (10,000 bits) over which
OpenSSL will not generate or derive keys. DH_check() will however still
perform various tests for validity on such a large modulus. We introduce a
new maximum (32,768) over which DH_check() will just fail.
An application that calls DH_check() and supplies a key or parameters
obtained from an untrusted source could be vulnerable to a Denial of
Service attack.
The function DH_check() is itself called by a number of other OpenSSL
functions. An application calling any of those other functions may
similarly be affected. The other functions affected by this are
DH_check_ex() and EVP_PKEY_param_check().
CVE-2023-3446
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)
(cherry picked from commit 9e0094e2aa1b3428a12d5095132f133c078d3c3d)
Signed-off-by: code4lala <fengziteng2@huawei.com>
Change-Id: I76f59e2c6292e3719b65242bfe2ad2ba44923320
The DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus
value even if it is excessively large.
There is already a maximum DH modulus size (10,000 bits) over which
OpenSSL will not generate or derive keys. DH_check() will however still
perform various tests for validity on such a large modulus. We introduce a
new maximum (32,768) over which DH_check() will just fail.
An application that calls DH_check() and supplies a key or parameters
obtained from an untrusted source could be vulnerable to a Denial of
Service attack.
The function DH_check() is itself called by a number of other OpenSSL
functions. An application calling any of those other functions may
similarly be affected. The other functions affected by this are
DH_check_ex() and EVP_PKEY_param_check().
CVE-2023-3446
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)
(cherry picked from commit 9e0094e2aa1b3428a12d5095132f133c078d3c3d)
Signed-off-by: code4lala <fengziteng2@huawei.com>
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA
padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
Patch written by Dmitry Belyavsky and Hubert Kario
CVE-2022-4304
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Signed-off-by: code4lala <fengziteng2@huawei.com>
Change-Id: Ib81f15484fa3374bf5f50baece50bb36d105d6d7
Fixes CVE-2023-0217
When attempting to do a BN_Copy of params->p there was no NULL check.
Since BN_copy does not check for NULL this is a NULL reference.
As an aside BN_cmp() does do a NULL check, so there are other checks
that fail because a NULL is passed. A more general check for NULL params
has been added for both FFC public and private key validation instead.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Signed-off-by: code4lala <fengziteng2@huawei.com>
Change-Id: I7086365d9f51b6f36fcfb79a45d36f8d032e1f22
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA
padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
Patch written by Dmitry Belyavsky and Hubert Kario
CVE-2022-4304
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Signed-off-by: code4lala <fengziteng2@huawei.com>
The server-side ChangeCipherState processing stores the new cipher
in the SSL_SESSION object, so that the new state can be used if
this session gets resumed. However, writing to the session is only
thread-safe for initial handshakes, as at other times the session
object may be in a shared cache and in use by another thread at the
same time. Reflect this invariant in the code by only writing to
s->session->cipher when it is currently NULL (we do not cache sessions
with no cipher). The code prior to this change would never actually
change the (non-NULL) cipher value in a session object, since our
server enforces that (pre-TLS-1.3) resumptions use the exact same
cipher as the initial connection, and non-abbreviated renegotiations
have produced a new session object before we get to this point.
Regardless, include logic to detect such a condition and abort the
handshake if it occurs, to avoid any risk of inadvertently using
the wrong cipher on a connection.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10943)
(cherry picked from commit 2e3ec2e1578977fca830a47fd7f521e290540e6d)
If we hit an EOF while reading in libssl then we will report an error
back to the application (SSL_ERROR_SYSCALL) but errno will be 0. We add
an error to the stack (which means we instead return SSL_ERROR_SSL) and
therefore give a hint as to what went wrong.
Contains a partial fix for #10880
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/10882)
RAND_get_rand_method() can return a NULL method pointer in the case of a
malloc failure, so don't dereference it without a check.
Reported-by: Zu-Ming Jiang (detected by FIFUZZ)
Fixes#10480
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10490)
EVP_PKEY_CTRL_DSA_PARAMGEN_Q_BITS and EVP_PKEY_CTRL_DSA_PARAMGEN_MD are only
exposed from EVP_PKEY_CTX_ctrl, which means callers must write more error-prone
code (see also issue #1319). Add the missing wrapper macros and document them.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit a97faad76a1be22eadd6c1a39972ad5e095d9e80)
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10094)
Make the include guards consistent by renaming them systematically according
to the naming conventions below
The public header files (in the 'include/openssl' directory) are not changed
in 1.1.1, because it is a stable release.
For the private header files files, the guard names try to match the path
specified in the include directives, with all letters converted to upper case
and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
kang1024