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

[John Denker]

In the context of

>> What's your threat model?

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

On 06/26/2017 11:51 AM, Salz, Rich wrote:

> Our TCB border is the process.

That doesn't answer the question.

> then something like chacha.

That doesn't answer the question either.

============

I'm not mentioning any names, but some people are *unduly*
worried about recovery following compromise of the PRNG
internal state, so they constantly re-seed the PRNG, to
the point where it becomes a denial-of-service attack
against the upstream source of randomness.

This is also mostly pointless, because any attack that
compromises the PRNG state will likely compromise so many
other things that recovery will be very difficult.  All
future outputs will be suspect.

So please let's not go overboard in that direction.

On the other hand, it seems reasonable to insist on /forward/
secrecy.  That is, we should insist that /previous/ outputs
should not be compromised.  This is achievable at small but
not-quite-zero cost.

Specifically, ChaCha (or any other cipher) in counter mode
does *not* provide forward secrecy when the PRNG state is
compromised.