Re: [PATCH 1/2] wrapper: add a helper to generate numbers from a CSPRNG

[Carlo Arenas <carenas@gmail.com>]

On Tue, Nov 16, 2021 at 5:04 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2021-11-16 at 23:20:45, rsbecker@nexbridge.com wrote:
> > We do link with libcurl and use OpenSSL as a DLL to handle TLS. The
> > underlying random source for the nonstop-* configurations as of
> > OpenSSL 3.0 are PNRG supplied by the vendor (HPE) on ia64 and the
> > hardware rdrand* instructions on x86. I know that part of the OpenSSL
> > code rather intimately.
>
> Great, as long as you don't define NO_OPENSSL, I think I can make this
> work with OpenSSL by calling RAND_bytes, which will use whatever OpenSSL
> uses.

not that RAND_bytes return high entropy bytes (like /dev/random) and
is therefore limited and prone to draining, blocking and erroring when
drained, so if we are going this route, will most likely need a second
layer on top that doesn't block (like arc4random does), and at that
point I would think we would rather use something battle tested than
our own.

for the little amount of random data we need, it might be wiser to
fallback to something POSIX like lrand48 which is most likely to be
available, but of course your tests that consume lots of random data
will need to change.

Carlo

PS. Probably missing context as I don't know what was discussed
previously, but indeed making this the libc problem by using mkstemp
(plus some compatibility on top), like Peff mentioned seems like a
more straightforward "fix"



  I'll work on that for a v2 to see if that will meet the needs for
> your platform, and if not, I'll try something else.
>
> That should also have the pleasant side effect of making this more
> portable even for those people who do have less common platforms, since
> OpenSSL will likely be an option there.
> --
> brian m. carlson (he/him or they/them)
> Toronto, Ontario, CA