Re: Problems with CSPRNG in wrapper.c

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Feb 28, 2023, 00:11 UTC
Message-ID: <Y/1GpjnMHLAqFV5x@tapette.crustytoothpaste.net>
In-Reply-To: <003e01d94b02$877c2c20$96748460$@nexbridge.com>

On 2023-02-27 at 23:23:36, rsbecker@nexbridge.com wrote:

Show 11 quoted lines

> I have already been down that path, but not successfully. /dev/urandom is
> not available on the platform - never has, never will to my knowledge. This
> does appear to work if PRNGD is correctly running, but I can't seem to get
> that to work on this site. The config.mak.uname for NonStop does specify:
> 
> CSPRNG_METHOD = openssl
> 
> which should use OPENSSL_random(), shouldn't it? OpenSSL 3.0 uses the
> _rdrand() builtin so should ever go to PRNGD, but it seems like this is
> anyway. Debugging isn't possible as this is not on my own systems - and
> things work here. Is there any kind of tracing I can do?

It actually uses RAND_bytes. I've confirmed on my Debian sid/amd64 system that compiling with "make -j8 CSPRNG_METHOD=openssl" results in the binary having a dependency on RAND_bytes. (I used "nm -D".)

Does your system have an nm binary that you could use to verify the linkage? (OpenBSD says it has existed since Version 1 Unix, but that doesn't mean it exists everywhere.) Once you can verify the linkage, you'll know whether the problem is OpenSSL not producing CSPRNG data or whether the CSPRNG_METHOD is incorrect.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA