* add drbg_init_from() and fork_default_rng(), and
* use the latter to define LKCAPI_INITRNG_FOR_SELFTEST() opportunistically (with fallback to plain wc_InitRng());
linuxkm/lkcapi_rsa_glue.c:
* add km_rsa_ctx_init_rng(),
* remove wc_InitRng() from km_rsa_ctx_init(),
* remove the WC_RSA_BLINDING gates around calls to wc_RsaSetRNG(), and
* call km_rsa_ctx_init_rng() before each call that needs an initialized RNG;
linuxkm/lkcapi_dh_glue.c and linuxkm/lkcapi_ecdh_glue.c: in km_ffdhe_init() and km_ecdh_init(), if linuxkm_lkcapi_registering_now, use LKCAPI_INITRNG_FOR_SELFTEST() to initialize ctx->rng;
linuxkm/lkcapi_glue.c: add notes that lkcapi_sha_glue inclusion and registrations must precede PK, and move declaration of linuxkm_lkcapi_registering_now to precede lkcapi glue inclusions.
* add WC_DRBG_{NOT_INIT,OK,FAILED,CONT_FAILED} in public header file, and
* move setup for RNG_SECURITY_STRENGTH, ENTROPY_SCALE_FACTOR, SEED_BLOCK_SZ, SEED_SZ, MAX_SEED_SZ, and RNG_HEALTH_TEST_CHECK_SIZE from random.c to random.h, with public WC_DRBG_SEED_SZ and WC_DRBG_MAX_SEED_SZ.
The early-data logic setups "early" exits in Accept/Connect state machine so
that the data exchanged during the handshake can be delivered to the
caller.
After the caller process the data, it usually calls Accept/Connect again
to cotinue the handshake.
Under non-blocking I/O there is the chance that these early exits are
skipped, this commit fixes that.
Server-side accept (TLS 1.3/DTLS 1.3) could skip the early-data shortcut
whenever sending the Finished flight first hit WANT_WRITE: when Accept
is called again and the data is eventually flushed into the I/O layer
the accept state is advanced past TLS13_ACCEPT_FINISHED_SENT, so the
next wolfSSL_accept() call skipped the block that marks
SERVER_FINISHED_COMPLETE and lets the application drain 0-RTT data. By
keeping the FALL_THROUGH into TLS13_ACCEPT_FINISHED_SENT and only
returning early while that handshake flag is still unset, we revisit the
shortcut immediately after the buffered flight is delivered, preserving
the intentional behaviour even under non-blocking I/O.
On the client, the same pattern showed up after SendTls13ClientHello()
buffered due to WANT_WRITE: after flushing, the connect state is already
CLIENT_HELLO_SENT so the early-data exit is no longer executed. We now
fall through into the CLIENT_HELLO_SENT case and only short-circuit once
per handshake, ensuring the reply-processing loop still executes on the
retry.
Anthony Hu
Daniel Pouzzner
Sean Parkinson
night1rider
Kareem
Mattia Moffa
Marco Oliverio
Hideki Miyazaki
JacobBarthelmeh
David Garske