Recently ci on master has been failing:
https://github.com/openssl/openssl/actions/runs/14234051502/job/39919663876
Its occuring because the s390 gcc compiler is complaining about various
functions attempting to write past the end of an array.
However, I can find no case in which we actually do so in this case.
The problem resolves when we either:
1) Disable the stringop-overflow warning
or
2) disable all loop unrolling optimizations with fno-loop-nest-optimize
Given that asan doesn't report any out of bounds errors on s390 when
built with case (1), and case (2) can be a significant performance hit,
coupled with the fact that gcc on any other platform avoids the same
issue (s390 is stuck on gcc 12, instead of gcc 16 where the other
platforms are), I think the right thing to do is just disable the
warning here
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27253)
We need to temporarily disable this as we have a build break in CI:
https://github.com/openssl/openssl/actions/runs/14192630435
Its occuring because gost-engine depends on libprov, which requires a
minimum version cmake-3.0. The update of github runners to cmake-4.0
causes a bail out as cmake 4.0 no longers supports cmake 3.0 syntax.
Libprov is fixed now, but gost-engine needs to update its libprov
submodule, and then we need to update the gost-engine submodule. Until
thats done (which may take days), we should disable the gost-engine
external tests
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27234)
With the addition of larger ml-kem keys in our tls handshake, we've
uncovered a interop failure, as described here:
https://github.com/microsoft/msquic/issues/4905
In short, when we send a client hello that spans multiple datagrams, the
servers sends an ACK frame in a datagram prior to sending its server
hello. msquic however, recomputes a new SCID always when sending its
sserver hello, which is fine nominally, but because in this test the
server sends a retry frame to update the SCID, followed by an ACK using
that SCID (which is an initial packet), msquic violates the RFC in
section 7.2 which states:
Once a client has received a valid Initial packet from the server, it MUST
discard any subsequent packet it receives on that connection with a
different Source Connection ID
Because msquic sent an initial packet with that ACK frame, we are
required to discard subsequent frames on the connection containing a
different SCID.
Until msquic fixes that in their implementation we are going to fail the
retry interop test, so for now, lets exclude the test.
Also, while we're at it, re-add chrome into the client list for our
server tests, as that seems to have been lost during the merge.
Fixesopenssl/project#1132
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27014)
- The default sigalg list now puts ML-DSA-65 first, then ML-DSA-87
and then ML-DSA-44. (87 vs. 44 Subject to bikeshedding).
- The mintls and maxtls versions are now taken into account for
both built-in and provided algorithms.
- Some algorithms have a separate TLSv1.2-specific name for future
reporting via openssl-list(1).
- ML-DSA aside, any new provided algorithms go at the end of the
default list (backwards-compatible inclusion).
- The built-in algorithms now also have min/max DTLS versions.
Though the provider TLS-SIGALG capability was extended to also report
the DTLS version range, the minimum supported DTLS is 1.3, which we
don't yet have, so it is not yet possible to add DTLS sigalgs via a
provider
- The TLS 1.3 brainpool sigalgs got their correct IANA names, with
the legacy names as purported TLS 1.2 alternatives, but since
these are for TLS 1.3 and up those names are for matching only,
the reported value will still be the 1.3 name.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26975)
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)
Recent test additions have increased the number of jobs spawned by the
interop runner test which exceeds the maximum allowed.
This occurs because the matrix expands to:
7 server elements
6 client elements
7 tests
2 test steps (client interop and server interop
Because of how github ci does matrix expansion, this results in
2 * 7 * 7 * 6 = 588
But most of those are invalid because each of the 2 steps only considers
either the client or server elements, and so get rerun multiple times
Alter the steps to be individual jobs, each with their own reduced
matrix to only run each relevant test once, limiting our job count to
at most 49 jobs.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26275)
Dmitry Misharov
Vladimír Chlup
Neil Horman
Pauli
Vavroch
Tomas Mraz
Bernd Edlinger
openssl-machine
Viktor Dukhovni
Andrew Dinh
Matt Caswell