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

[Salz, Rich]

> Insofar as any hole that is not explicitly closed should be presumed open,
> then yes, there are many holes.

Any hole not known -- presumed open, or presumed closed? :)  It's more about 

> What's your threat model?  I know that sounds like a cliché, but it's actually
> important.

We're trying to do a better job than the current stuff.  We want to provide a good cross-platform API that uses the operating system when it's worth doing so. 

There are lots of vague words in that.  Deliberately.
 
>  --  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?

Because the ambient OS isn't one, but is one of many possibilities.  A good kernel getrandom might exist, a good /dev/random might exist, either might exists but be bad, and one might exist and be good.  We want to assume the minimum set of O/S facilities, and try to develop code that has the minimum set of ifdef's or run-time code paths.  Again, there are vague words there.  But code that's perfect but impenetrable does not help our user base.

>  -- Conversely, if you don't trust the OS, what makes you
>   think you can solve a problem the OS failed to solve,
>   especially without knowing why it failed?
> 
> And (!) what do you propose to do when a suitable seed is not available at
> the moment but might be available later?

Leave it up to the application to decide.   It would be nice to say "fix the platform" but we run on places where that is not possible.  Right now I believe (and this entire note is my opinion) that the best we can realistically do is make it possible for portable safe applications to do the right thing.
 
> 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?

Our TCB border is the process.

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

Only memory.

> Just having a pool and a hash function is not enough.  Not even close.

I wasn't suggesting just those.  I was saying that's the pool, and then something like chacha.

> Constructive suggestion:  If you want to see what a RNG looks like when
> designed by cryptographers, take a look at:
>   Elaine Barker and John Kelsey,
>   “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.

Well maybe I can ignore section 10.3?
 
> Do you trust the generic
> openssl user, who knows nothing about cryptology, to provide either one?

No, which is why we'll have a mixin-from-system API that will hopefully do the right thing.  Ideally on all places where openssl runs.

> Combining many lousy sources and hoping that one of them will do the job is
> not good engineering practice.

But if there are a couple and they're both mediocre?