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

John Denker ssx at av8n.com
Mon Jun 26 18:29:19 UTC 2017


On 06/26/2017 09:17 AM, Salz, Rich wrote:

[snip]

> Does this make sense?  Are there holes?

Even without the snipping, the proposal is very incomplete.
Insofar as any hole that is not explicitly closed should
be presumed open, then yes, there are many holes.

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?
 -- 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?

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?

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


> Randomness should be whitened.  Anything feed into an randomness
> pool, should be mixed in and run through SHA256. pool = SHA256(pool
> || new-randomness) 

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

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.

> 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?

> The idea of cascading pools is neat.

Cascading is absolutely necessary, and must be done "just so", to
prevent track-and-hold attacks.  One of the weaknesses in the
Enigma, exploited to the hilt by Bletchley Park, was that each
change in the internal state was too small.  A large state space
is not sufficient if the state /changes/ are small.

On 06/26/2017 10:12 AM, Kurt Roeckx wrote:

>> 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.



More information about the openssl-dev mailing list