Re: [TLS] RNG vs. PRNG

[Marsh Ray <[e-mail]>]

I'd emailed Peter offlist since it was out of scope for the final call
discussion, but we decided it was appropriate for [TLS].

On 4/27/2010 3:09 AM, Peter Gutmann wrote:
> Marsh Ray <[e-mail]> writes:
>> If you're worried about an attacker analyzing your RNG, fix the 
>> RNG!
> 
> ... and hope that you haven't got any detail wrong

One could say that about nearly anything in a security-critical context.

> (we can't even get agreement on what a good RNG should be),

Getting that agreement would be really worthwhile!

> and persuade everyone else to fix their RNGs, and get every user to
> operate all of the RNGs in a secure manner, and ...

What's broken is broken and needs to be fixed regardless of how the RFCs
were interpreted in the past. But if we nail down the real requirements
and lexicon, we can prevent problems going forward.

> This is straightforward attack surface reduction, there's no reason 
> to expose the output of your crypto RNG to the world at large.

Why not? If you have something to hide then perhaps you are doing
something wrong? (don't take that the wrong way)

> To use an analogy, you wouldn't leave all your cash and valuables
> lying on the windowsill by the front door no matter how good your
> door locks are.

That's a great analogy! For something. I'm not sure I agree that it fits
here.

At some point you have to show your bits to the network, but you
shouldn't be so shy about exposing your entropy that your nonces come
out weak!

A counter-analogy: A few years back it was considered important for
security to minimize "known plaintext". Plaintext had to be compressed
before encryption, etc. But ciphers got better and are now expected to
be known-plaintext-attack resistant. The cipher is expected to work well
"out of the box" in the face of whatever input you may supply it.

So I suggest that today we have the means to make true RNGs that remain
strong regardless of how much output you give to Mallory. With such an
RNG in hand, let us not be miserly with it. We should use it everywhere
we can.

>> Would you be willing to substitute a simple counter there?
> 
> I'd have to examine the specs in more detail to see what the full 
> role of the nonce is, but my guess is that a counter would do it (in
> practice I'd hash the site FQDN and a counter or do something
> similar to make sure I don't use the same nonce as another site, but
> I'd have to look at the protocol in some detail to see whether it'd
> still work with just a counter).
> 
>> If not, how little entropy would you tolerate?
> 
> See above.

I really think the security of TLS relies on having a healthy amount of
entropy in the hello.random data areas. Its designers did not dedicate
64 bytes of those critical first TCP packets to random without good
reason. As I have considered various ways to break TLS, many times an
otherwise promising line of thought has hit a dead end due to "that darn
unpredictable hello.random_data!"

For example, if the server's random_data was based on just the FQDN and
a counter, an attacker could arrange for a repeated values by forcing a
reboot of the server or restart of the daemon (usually not too hard to
do). Now he can simply replay a transaction he previously observed being
made by the legitimate client. Likewise in the client direction, for
some ciphers.

- Marsh