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

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 11:29:19AM -0700, John Denker via openssl-dev wrote:
> What's your threat model?  I know that sounds like a cliché,
> but it's actually important.
> 
> In particular, in my world the #1 threat against any PRNG
> is improper seeding. 
>  --  If you trust the ambient OS to provide a seed, why not
>   trust it for everything, and not bother to implement an
>   openssl-specfic RNG at all?

As I understand it, the main reason to provide our own one is
speed. Related to it, it might not be able to provide the amount
of random data that we would like to use.

I see no other reasons not to use the OS provided one.

> And (!) what do you propose to do when a suitable seed is not
> available at the moment but might be available later?

The current API returns an error, but it would be better
that it would block until it's available.

> Are you designing to resist an output-text-only attack?  Or do
> you also want "some" ability to recover from a compromise of
> the PRNG internal state?

I think at least some people seem to want to deal with a
compromised internal state, but I have to wonder how it would
get compromised in the first place and if you can really fix it.

> Is there state in a persistent file, or only in memory?

We currently have a ~/.rnd file. We should probably get rid of it.

>   “Recommendation for Random Number Generation Using Deterministic Random Bit Generators”
>   http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
> 
> That design may look complicated, but if you think you can
> leave out some of the blocks in their diagram, proceed with
> caution.  Every one of those blocks is there for a reason.

SP800-90A (or revision 1) can clearly be used as reference on how
to implement it, even if we don't use an approved algorithm from
it. And I really think we should look at that document when
implementing it.

There should probably also be an option to use an RNG that
conforms to it.

> > Randomness should be whitened.
> 
> Whitening at the input is neither difficult nor necessary nor sufficient.
> The hard part is obtaining a reliable lower bound on the amount of
> useful randomness in the bit-blob when it appears at the input.  Where
> did the bits come from?  Where did the bound come from?  Do you trust
> the generic openssl user, who knows nothing about cryptology, to provide
> either one?

I think it should by default be provided by the OS, and I don't
think any OS is documenting how much randomness it can provide.

> >> Do you think we need to use multiple sources of randomness?
> 
> Quality is more important than quantity.
> 
> N reliable sources is marginally better than N-1 reliable sources.
> One reliable source is immeasurably better than any number of
> unreliable sources.
> 
> Combining many lousy sources and hoping that one of them will do
> the job is not good engineering practice.

The OS should already be using all the different sources. I don't
think OpenSSL also using those sources is adding anything, I think
it will only make the code harder for no good reason.


Kurt