Useless and causes a compiler warning/error:
error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C23, conflicting with a subsequent declaration [-Werror,-Wdeprecated-non-prototype]
Self-signed trust anchors are not part of the certificate path validation
according to RFC 8280, section 6.1:
When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path.
But policies in them could still be used, as stated in section 6.2:
Where a CA distributes self-signed certificates to specify trust
anchor information, certificate extensions can be used to specify
recommended inputs to path validation. For example, a policy
constraints extension could be included in the self-signed
certificate to indicate that paths beginning with this trust anchor
should be trusted only for the specified policies. [...]
Implementations that use self-signed certificates to specify trust
anchor information are free to process or ignore such information.
So unconditionally enforcing that self-signed root certificates contain
the policies is probably too strict. Often they won't contain the
extension at all. With this change, we allow that but still enforce the
policies in case such a certificate contains them. The other
policy-related constraints are also enforced still should they be
contained.
Closesstrongswan/strongswan#2601
These have been discouraged for a long time and there are now more and
more crypto libraries that have them disabled by default. However, for
some we only can detect this at runtime, in particular in FIPS mode, so
tests would fail as the plugins would still announce them. So instead
we just remove the schemes from these tests for now (at least for RSA,
removing signatures with SHA-1 completely isn't an option yet as that's
still the default with some clients).
Closesstrongswan/strongswan#2523
When compiling with -O3 with GCC 14, we get the following warning/error:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: error: '__builtin_memcpy' offset [0, 3] is out of the bounds [0, 0] [-Werror=array-bounds=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
Which seems completely bogus as that array has a fixed size of 16 and
some weird workarounds remove the warning (e.g. adding an assignment
to `subset->netbits` before the `memcpy()`). This is also the only
place GCC complains about and we use `memcpy()` all over the place
in this file to set those addresses.
Closesstrongswan/strongswan#2509
While this does require quite a bit of memory, on initiators there are
usually fewer concurrent SAs getting created so this should be less of
an issue than on a gateway that handles lots of SAs as responder.
The speed up is about 30% on the initiator during the decapsulation,
while the key generation does take a bit more time (about 3%).
This follows FIPS 203 relatively closely but takes some ideas from the
reference implementation. In particular, how to avoid potential
side-channels via direct C division/modulo operations. However, it just
uses Barrett reduction (no Montgomery reduction) and no negative
coefficients to avoid number format conversions and keep the
implementation clearer.
This registers support for the ML_KEM_{512,768,1024} key exchange
algorithms in the `openssl` plugin when built using AWS-LC as the
libcrypto. To do this, we introduce the `openssl_kem` source files
which implement the key exchange algorithm using the Key Encapsulation
Mechanism (KEM) API. Future KEM algorithms can be implemented
generically using this interface by substituting the appropriate NIDs.
It also supports both seeded (via DRBG) and unseeded modes depending
on the user's requirements for KATs or entropy sources.
It should be noted that this does not add support for KEM algorithms
within upstream OpenSSL and is API incompatible. Future work will need
to condition out the incompatibilities as-appropriate. However, the
high-level logic should be the same for all KEMs and KEM APIs.
References strongswan/strongswan#2228Closesstrongswan/strongswan#2490
Both Diffie-Hellman (DH) and Key Encapsulation Mechanism (KEM) based
key exchange methods use a common ke_test_vector format. The
set_seed() function is used to provide deterministic private key
material for the crypto tests.
struct ifreq can't be used for IPv6 as the ifr_addr member is not large
enough. Actually, configuring an IPv6 address via an AF_INET socket won't
work anyway. And unfortunately, it's not standardized how IPv6 addresses
are installed, so we have to do this quite differently on Linux and on BSD.
However, we already use SIOCAIFADDR for IPv4 on newer FreeBSD systems,
which wasn't the case when this patch was originally created in 2014.
The behavior of realloc(3) with zero size was apparently implementation
defined. While glibc documents the behavior as equivalent to free(3),
that might not apply to other C libraries. With C17, this behavior has
been deprecated, and with C23, the behavior is now undefined. It's also
why valgrind warns about this use.
Hence, when array_compress() would call realloc() with a zero size, we
now call free() explicitly and set the pointer to NULL.
Signed-off-by: Thomas Egerer <[email protected]>
As recommended by RFC 2985, section 5.4.1:
ChallengePassword attribute values generated in accordance with this
version of this document SHOULD use the PrintableString encoding
whenever possible. If internationalization issues make this
impossible, the UTF8String alternative SHOULD be used.
Even though the RFC continues with
PKCS #9-attribute processing systems MUST be able to recognize and
process all string types in DirectoryString values.
there might be older SCEP server implementations that don't accept
UTF8String-encoded passwords. In particular because previous versions of
PKCS#9 defined this attribute's type as a CHOICE between PrintableString
and T61String.
References strongswan/strongswan#1831
Can be useful if the CID inside the VM is not known.
The \htmlonly\endhtmlonly hack is used to avoid compiler warnings due
to /* inside a block comment.
There are definitions of RNG in <wolfssl/wolfcrypt/settings.h> and
<wolfssl/wolfcrypt/random.h> that play havoc with the literal RNG being
used in the expansions of PLUGIN_*(RNG, ...) when ##-concatenated to
build the enum value FEATURE_RNG.
The #undef in wolfssl_cmmon.h only had an effect if wolfSSL was built
with EdDSA or FIPS enabled, otherwise, the headers that define RNG were
not pulled in before it.
Signed-off-by: Philip Prindeville <[email protected]>
With GCC 13, the compiler apparently applies new aliasing optimizations
when compiled with -O2 and without -fno-strict-aliasing. This caused
the application of the second padding bit, where the state was accessed
via uint8_t[], to be moved before the loop that absorbs the buffer into
the state, where the state is accessed via uint64_t[], resulting in
incorrect output. By only accessing the state via uint64_t[] here the
compiler won't reorder the instructions.
Tobias Brunner