Examples: POSIX RNG modes counter and rand()

[jackctj117]

Add a rand()-backed RNG option to the POSIX examples alongside the existing counter RNG to support more realistic RSA keygen testing and general randomness exercises.

[Copilot]

Pull Request Overview

Adds configurable RNG modes to the POSIX server example to support both counter-based and rand()-based random number generation. This enhancement enables more realistic RSA key generation testing and general randomness exercises beyond the existing counter-only approach.

• Added command line options for RNG mode selection (counter or rand) and optional seed configuration
• Implemented rand()-based RNG callback alongside existing counter-based callback
• Updated server initialization to use the selected RNG mode for default crypto operations

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Using atoi() for parsing the RNG seed lacks error handling. Consider using strtoul() or similar function that can detect invalid input and handle edge cases like negative numbers or non-numeric strings.

Suggested change

	s_rngSeed = (unsigned)atoi(argv[++i]);
	char *endptr = NULL;
	errno = 0;
	unsigned long seed = strtoul(argv[++i], &endptr, 10);
	if (errno != 0 || endptr == argv[i] || *endptr != '\0' || seed > UINT32_MAX) {
	printf("Invalid RNG seed: %s\n", argv[i]);
	Usage(argv[0]);
	return -1;
	}
	s_rngSeed = (unsigned)seed;

[Copilot]

Using rand() for cryptographic purposes is insecure as it's not cryptographically secure. This implementation should include a warning comment that it's for testing/demonstration purposes only and not suitable for production cryptographic operations.

Suggested change

	/* WARNING: This implementation uses rand() for random number generation,
	* which is NOT cryptographically secure. This is intended for testing or
	* demonstration purposes only and MUST NOT be used in production
	* cryptographic operations.
	*/

[dgarske]

I agree. The point was to not have RNG directly spitting out sequential values, but using wolfCrypt DRBG is fine and wolfCrypt has support for /dev/random, etc already. Can we leverage wolfCrypt instead?

[bigbrett]

@jackctj117 please redo this according to how @dgarske and I have mentioned (using built-in wolfCrypt features). We don't need the server to register a cryptocb here. Use the built in facilities of wolfCrypt

[billphipps]

Let's split this into 2 items: entropy and DRBG.
Entropy: The POSIX method getentropy() in unistd.h is how to get entropy from a posix system. If this returns ENOSYS, then try to grab some non-zero bytes from the bottom end of the current timestamp (like gettimeofday() in sys/time.h). If that fails, then use a counter like we currently do.
DRBG: If HAVE_HASHDRBG is defined, then use that. Otherwise, use the POSIX lrand48() in unistd.h after seeding it using srand48() with the entropy above.

using rand() is a non-starter.

[billphipps]

Meh. Not sure this is the right path at all. The point of the sequential rng was to show how the HSM server could use a HARDWARE callback to generate the entropy necessary to support its DRBG within the server context->rng. The expectation was that the server would always seed this DRBG the "right" way by asking the hardware to provide bytes. The provided callback only generated 4kB of data then politely fails. The first few interactions from the posix_client were supposed to grab random data to exhaust this 4kB limit, letting the server context->rng fallback the the default RNG in wolfCrypt.

At this point, we need to undo anything out of the server context that is done for demo purposes (like the 5 different contexts) so that the server can be used as a generic server for the rest of the tests.

I recommend we reject this PR and instead remove anything "demo-y" in the server so that it simply starts up and listens to requests on whatever interfaces it is supposed to, hopefully multiple.

[jackctj117]

Just for context this was requested: #202

Though if you want to change the server entirely then it shouldn't matter.

[bigbrett]

I'm not sure how I feel about this PR adding a server-side crypto callback to call rand() when wolfCrypt should be able to handle platform-specific RNG selection internally on a POSIX system, no crypto callback required.

I suppose it serves as a good example for registering a server-side crypto callback? But then it should be documented as such?

@billphipps thoughts?