The non-blocking setup for X25519 and ECC in TLS was unconditionally
setting up nbCtx, which caused functions to return FP_WOULDBLOCK. However,
with INVALID_DEVID (the default), TLS has no async loop to handle
FP_WOULDBLOCK, only WC_PENDING_E via the async framework.
The fix follows the pattern used in asn.c: only set up nbCtx when the async
device is active (devId != INVALID_DEVID). With INVALID_DEVID, the code now
uses the blocking fallback (WC_ECC_NONBLOCK_ONLY) instead.
This prevents unit test timeouts when built with --enable-curve25519=nonblock
or --enable-ecc=nonblock.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
wolfcrypt/test/test.c: fix error-path memory leaks in srtpkdf_test(), and properly gate out incompatible SRTP_KDF_LONG_KEY test on old FIPS (defect introduced in #9733);
.wolfssl_known_macro_extras: get into lexical order and remove unneeded WC_RSA_DIRECT.
wolfssl/wolfcrypt/asn.h: use WC_BITFIELD for extAuthInfoListSz and extAuthInfoListOverflow bitfields, for C89 compat (fixes -Wpedantic from 08c1397cc1).
## Summary
- Add non-blocking (incremental) Curve25519 key generation and shared secret via `WC_X25519_NONBLOCK`, modeled after the existing ECC non-blocking pattern (`WC_ECC_NONBLOCK`)
- Implement `curve25519_nb()` and `fe_inv__distinct_nb()` in `fe_low_mem.c` as state-machine variants that return `FP_WOULDBLOCK` to yield after each field multiply
- Add `wc_curve25519_set_nonblock()` API to attach/detach non-blocking context to a key
- Integrate X25519 non-blocking with TLS 1.2/1.3 key share generation and shared secret in `tls.c` and `internal.c` (behind `WC_X25519_NONBLOCK && WOLFSSL_ASYNC_CRYPT_SW`)
- Add `--enable-curve25519=nonblock` configure option (auto-enables `--enable-asynccrypt` and `--enable-asynccrypt-sw`)
- Add X25519 async software dispatch cases in `async.c` and types in `async.h`
- Fix async guard in `curve25519.c` to require `WOLFSSL_ASYNC_CRYPT_SW` (matching other algorithms)
- Overhaul `examples/async/` client/server: non-blocking I/O via `WOLFSSL_USER_IO`, standalone `Makefile`, X25519/ECC mode selection, CI-friendly ready-file sync
- Add `examples/configs/user_settings_curve25519nonblock.h` and CI coverage in `os-check.yml` and new `async-examples.yml` workflow
- Add wolfcrypt test and API test coverage for X25519 non-blocking
Always check for infinity and, when B param available, whether the point
is on the curve when point is untrusted.
Change TLS code to treat points from peer as untrusted on import.
Move EC and RSA code out of pk.c into separate file.
Move out of ssl.c into separate files:
- Certificate APIs
- CRL/OCSP APIs
- Public Key APIs
- ECH
Internal Certificate Manager APIs pulled out into ssl_certman.c.
d2i and i2d WOLFSSL_EVP_PKEY APIs pulled out into evp_pk.c.
Fix formatting.
Make sure we received a Certificate message before the ClientKeyExchange
when a certificate is requested. (Certificate message will be empty when
client has no valid certificate.)
Mostly combinations of NO_WOLFSSL_CLIENT, NO_WOLFSSL_SERVER and
WOLFSSL_NO_CLIENT_AUTH were failing.
Added configurations to CI loop.
wc_AesGcmDecryptFinal: use WC_AES_BLOCK_SIZE to satisfy compiler.
* More PQC configurations
* More CMake setups
* Fix various bugs uncovered by these tests
Added some missing feature additions to CMake to make the example
`user_settings_all.` config file work for the CI test.
When both TLS 1.3 and Brainpool curves are enabled, three new groups can
be used for the ECDHE key exchange according to RFC 8734:
* WOLFSSL_ECC_BRAINPOOLP256R1TLS13 (31)
* WOLFSSL_ECC_BRAINPOOLP384R1TLS13 (32)
* WOLFSSL_ECC_BRAINPOOLP512R1TLS13 (33)
Also ensure that the existing TLS 1.2 curves are sent properly.
The TLS client application is updated to support handshakes via
Brainpool curves using the new argument "--bpKs".
When wolfSSL_SetVersion() is called to set a specific TLS version,
the downgrade flag is now set to 0. This causes wolfSSL_parse_cipher_list()
to no longer preserve cipher suites from the other TLS version group.
Previously, when using SSLv23 method and setting cipher suites for only
one TLS version (e.g., TLS 1.2), the library would preserve any existing
cipher suites from the other version (e.g., TLS 1.3) for OpenSSL API
compatibility. With this change, if a specific version is set via
wolfSSL_SetVersion(), only the cipher suites for that version are kept.