We still build with crypto-mdebug-backtrace enabled in a few ci jobs,
but it does nothing.
With the upcoming merge of feature/removesslv3, the code changes there
prevent the use of this option (i.e. enabling it results in
configuration failure).
It seems the most sensible thing to do here, given we have a major
release is to eliminate the option entirely, as it hasn't done anything
since 1.0.2.
Fixesopenssl/project#1763
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/29380)
We would like to be able to test our memory failure paths, but forcing
malloc to return NULL at certain points in time.
This test does that, by running a sepcific workload n+1 time. In this
case the workload is a simple ssl handshake.
We run 1 test which sets our malloc wrapper into record mode, in which
it just acts as a pass through to the system malloc call and records the
number of times it was called.
Then we run a second test, which does the same handshake N times, where
N is the number of times malloc was called in the previous test. For
each iteration in i=0..N we fail the ith malloc operation.
We don't check for functional failures in the second test (as we expect
failures), we just want to make sure that (a) we don't crash and (b)
asan doesn't report any errors.
Currently, we get _lots_ of asan failures, but we can use this test to
log issues for that and fix those up.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28078)
Coveralls is capable of reporting not only covered lines in a build, but
also the number of times a given branch was taken vs. not taken. This
will help us identify locations where we might make better use of the
openssl_likely and openssl_unlikely macros to optimize branch prediction
when building openssl
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/27839)
One of the ways we can optimize our builds is with profile guided
optimization. This entails doing several things:
1) Building with --coverage
2) Running an application against the openssl library from step (1) to
generate profile data
3) rebuilding openssl using the input profile from step (2) to optimize
the build.
This new build configuration will let developers use the profiled data
to see what type of optimizations might be possible, as well as giving
end users the ability to squeeze a bit more performance out of openssl
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/27839)
Recently updated to fedora 42, which includes an updated gcc, which
triggers a new warning:
test/afalgtest.c:44:9: error: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (18 chars into 17 available) [-Werror=unterminated-string-initialization]
44 | "\x53\x69\x6e\x67\x6c\x65\x20\x62\x6c\x6f\x63\x6b\x20\x6d\x73\x67"
The warning occurs because in some locations we create char buffers of
length X, and fill it with X bytes of data, truncating the NULL
terminator.
We could fix it by adding the nonstring attribute, but given that:
1) Adding attributes might impact other platforms that don't understand the
attribute.
2) We often create char buffers that don't expect a NULL terminator.
3) Converting the unsigned char arrays to uint8_t, or other types that
could be interpreted as non-strings has no impact, only applying the
nonstring attribute silences the warning.
It seems more sensible to just disable the warning entirely
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27490)
The way we're currently handling SAN URIs does not allow for userinfo,
meaning the name constraint check on such URIs will fail. Fix this by
skipping over the userinfo component:
authority = [ userinfo "@" ] host [ ":" port ]
(per RFC 3986).
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25861)
This introduces support for ML-KEM-512 and ML-KEM-1024 using the same
underlying implementation parameterised by a few macros for the
associated types and constants.
KAT tests are added for ML-KEM 512 and 1024, to complement the previous
tests for ML-KEM-768.
MLKEM{512,768,1024} TLS "group" codepoints are updated to match the
final IANA assigments and to make the additional KEMs known to the TLS
layer.
The pure-QC MLKEMs are not in the default list of supported groups, and
need to be explicitly enabled by the application. Future work will
introduce support for hybrids, and for more fine-grained policy of
which keyshares a client should send by default, and when a server
should request (HRR) a new mutually-supported group that was not
sent.
Tests for ML-KEM key exchange added to sslapitest to make sure that our
TLS client MLKEM{512,768,1024} implementations interoperate with our TLS
server, and that MLKEM* are not negotiated in TLS 1.2.
Tests also added to excercise non-derandomised ML-KEM APIs, both
directly (bypassing the provider layer), and through the generic EVP KEM
API (exercising the provider). These make sure that RNG input is used
correctly (KAT tests bypass the RNG by specifying seeds).
The API interface to the provider takes an "const ML_KEM_VINFO" pointer,
(obtained from ossl_ml_kem_get_vinfo()). This checks input and output
buffer sizes before passing control to internal code that assumes
correctly sized (for each variant) buffers.
The original BoringSSL API was refactored to eliminate the opaque
public/private key structure wrappers, since these structures are an
internal detail between libcrypto and the provider, they are not part of
the public (EVP) API.
New "clangover" counter-measures added, refined with much appreciated
input from David Benjamin (Chromium).
The internal steps of "encrypt_cpa" were reordered to reduce the
working-set size of the algorithm, now needs space for just two
temporary "vectors" rather than three. The "decap" function now process
the decrypted message in one call, rather than three separate calls to
scalar_decode_1, scalar_decompress and scalar_add.
Some loops were unrolled, improving performance of en/decapsulate
(pre-expanded vectors and matrix) by around 5%.
To handle, however unlikely, the SHA3 primitives not behaving like
"pure" functions and failing, the implementation of `decap` was modifed:
- To use the KDF to compute the Fujisaki-Okamoto (FO) failure secret
first thing, and if that fails, bail out returning an error, a shared
secret is still returned at random from the RNG, but it is OK for the
caller to not use it.
- If any of the subsequently used hash primitives fail, use the computed
FO failure secret (OK, despite no longer constant-time) and return
success (otherwise the RNG would replace the result).
- We quite reasonably assume that chosen-ciphertext attacks (of the
correct length) cannot cause hash functions to fail in a manner the
depends on the private key content.
Support for ML-KEM-512 required adding a centered binomial distribution
helper function to deal with η_1 == 3 in just that variant.
Some additional comments were added to highlight how the code relates to
the ML-KEM specification in FIPS 203.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26172)
Based on code from BoringSSL covered under Google CCLA
Original code at https://boringssl.googlesource.com/boringssl/+/HEAD/crypto/mlkem
- VSCode automatic formatting (andrewd@openssl.org)
- Just do some basic formatting to make diffs easier to read later: convert
from 2 to 4 spaces, add newlines after function declarations, and move
function open curly brace to new line (andrewd@openssl.org)
- Move variable init to beginning of each function (andrewd@openssl.org)
- Replace CBB API
- Fixing up constants and parameter lists
- Replace BORINGSSL_keccak calls with EVP calls
- Added library symbols and low-level test case
- Switch boringssl constant time routines for OpenSSL ones
- Data type assertion and negative test added
- Moved mlkem.h to include/crypto
- Changed function naming to be in line with ossl convention
- Remove Google license terms based on CCLA
- Add constant_time_lt_32
- Convert asserts to ossl_asserts where possible
- Add bssl keccak, pubK recreation, formatting
- Add provider interface to utilize mlkem768 code enabling TLS1.3 use
- Revert to OpenSSL DigestXOF
- Use EVP_MD_xof() to determine digest finalisation (pauli@openssl.org)
- Change APIs to return error codes; reference new IANA number; move static asserts
to one place
- Remove boringssl keccak for good
- Fix coding style and return value checks
- ANSI C compatibility changes
- Remove static cache objects
- All internal retval functions used leading to some new retval functions
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25848)
The key generation algorithm requires a significant portion of the many
algorithms present in FIPS 204.
This work is derived from the BoringSSL code located at
https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/mldsa/mldsa.cc
Instead of c++ templates it uses an ML_DSA_PARAMS object to store constants such as k & l.
To perform hash operations a temporary EVP_MD_CTX object is used, which is supplied with a
prefetched EVP_MD shake128 or shake256 object that reside in the ML_DSA_KEY object.
The ML_DSA_KEY object stores the encoded public and/or private key
whenever a key is loaded or generated. A public key is always present
if the private key component exists.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26127)
In the webinar we are currently producing on debugging openssl
applications, we talk about ways to allow debugable binaries without
having to ship all the debug DWARF information to production systems.
Add an optional target to do that DWARF separation to aid users
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25174)
FIPS providers need to specify identifiable names and versions. Allow
to customize the fips provider name prefix, via VERSION.dat which
already allows to customize version & buildinfo. With this patch
in-place it removes the need of patching code to set customized
provider name.
E.g. echo FIPS_VENDOR=ACME >> VERSION.dat, results in
```
$ OPENSSL_CONF=fips-and-base.cnf ../util/wrap.pl ../apps/openssl list -providers --verbose
Providers:
base
name: OpenSSL Base Provider
version: 3.4.0
status: active
build info: 3.4.0-dev
gettable provider parameters:
name: pointer to a UTF8 encoded string (arbitrary size)
version: pointer to a UTF8 encoded string (arbitrary size)
buildinfo: pointer to a UTF8 encoded string (arbitrary size)
status: integer (arbitrary size)
fips
name: ACME FIPS Provider for OpenSSL
version: 3.4.0
status: active
build info: 3.4.0-dev
gettable provider parameters:
name: pointer to a UTF8 encoded string (arbitrary size)
version: pointer to a UTF8 encoded string (arbitrary size)
buildinfo: pointer to a UTF8 encoded string (arbitrary size)
status: integer (arbitrary size)
security-checks: integer (arbitrary size)
tls1-prf-ems-check: integer (arbitrary size)
drbg-no-trunc-md: integer (arbitrary size)
```
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24368)
This entropy source can be used instead of SEED-SRC. Sample
openssl.cnf configuration is provided. It is built as a separate
provider, because it is likely to require less frequent updates than
fips provider. The same build likely can span multiple generations of
FIPS 140 standard revisions.
Note that rand-instances currently chain from public/private instances
to primary, prior to consuming the seed. Thus currently a unique ESV
needs to be obtained, and resue of jitterentropy.a certificate is not
possible as is. Separately a patch will be sent to allow for
unchaining public/private RAND instances for the purpose of reusing
ESV.
Also I do wonder if it makes sense to create a fips variant of stock
SEED-SRC entropy source, which in addition to using getrandom() also
verifies that the kernel is operating in FIPS mode and thus is likely
a validated entropy source. As in on Linux, check that
/proc/sys/crypto/fips_enabled is set to 1, and similar checks on
Windows / MacOS and so on.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24844)
- add test vectors for tls1_3 integrity-only ciphers
- recmethod_local.h: add new member for MAC
- tls13_meth.c: add MAC only to tls 1.3
- tls13_enc.c: extend function to add MAC only
- ssl_local.h: add ssl_cipher_get_evp_md_mac()
- s3_lib.c: add the new ciphers and add #ifndef OPENSSL_NO_INTEGRITY_ONLY_CIPHERS
- ssl_ciph.c : add ssl_cipher_get_evp_md_mac() and use it
- tls13secretstest.c: add dummy test function
- Configure: add integrity-only-ciphers option
- document the new ciphers
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22903)
