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>
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>
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
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>
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)
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/9681)
kang1024