Re: [openssl-dev] what's possible and what's not ... including RNGs

Knowledge of the platform is a required part of the OpenSSL configuration. If the platform supports HRNG (usually in the form of CPU instructions), use it: let OpenSSL mix its output with whatever other randomness sources it picks on that platform/system. IMHO that’s the best strategy.

[openssl-dev] what's possible and what's not ... including RNGs

On 06/29/2017 08:01 AM, I wrote: > Some platforms are not secure and cannot be made secure. This is relevant to the RNG discussion, and lots of other stuff besides. *) For example, you can use openssl rsa to generate a so-called private key, but it will not actually be private (in any

Re: [openssl-dev] Work on a new RNG for OpenSSL

Executive summary: As has been said many times before, what we need (but do not have) is /one/ source of randomness that never blocks and never returns bits that are guessable by the adversary. In favorable cases, using getrandom(,,0) \*\ is appropriate for openssl. There are problems with

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 29 Jun 2017, at 06:03, Ben Laurie wrote: > > On 28 June 2017 at 03:41, Theodore Ts'o wrote: > On Wed, Jun 28, 2017 at 11:41:11AM +1000, Peter Waltenberg wrote: > > And FYI. On systems not backed with hardware RNG's /dev/random is > > extremely slow. 1-2