Re: [TLS] New drafts: adding input to the TLS master secret

[Eric Rescorla <[e-mail]>]

At Mon, 8 Feb 2010 14:29:12 -0500 (EST),
Dean Anderson wrote:
> On Sat, 6 Feb 2010, Eric Rescorla wrote:
> The primary purpose (unique master_secrets) of these random numbers is
> unimportant.  If they are not truly random, they expose the
> pseudo-random sequence generator sequence. This is an unintended (but
> significant) consequence.

With any reasonable PRNG this is not a security concern.

> > Well, this isn't true for the server half of the static RSA cipher
> > suites, since the server doesn't contribute to the PMS at all.
> 
> True, the server random doesn't expose the client's pre_master_secret in
> that _particular_ calculation.  But the server IS still exposing its
> (possibly dependent) random numbers. If you collect enough of these
> through snooping, you can predict its pre_master_secret for connections
> orginating from that machine.

This is true only in an information theoretic sense. It is not
correct with any reasonable and reasonably seeded CSPRNG.


> > In any case, this is an argument for *not* generating the Random
> > values with a cryptographic PRNG since then you would not be leaking
> > information about the PRNG state in the random values.
> 
> Yes. That's my point. By 'cryptographic PRNG' you mean a PRNG that is
> hard to predict. But if you get enough of its sequence and have enough
> compute power, all PRNG's are predictable.

This is true but irrelevant. If you have enough computing power
you can break all ciphers directly. The amount of computing
power required to reverse the PRNG is comparable if not in
excess of the amount required to break the cipher.


> > I am not aware of any such rule of thumb. In fact, this design is a
> > fairly standard feature of cryptographic protocols.
> 
> I'll see if I can find a better reference.  I think the cryptographic
> fact I'm looking for is that a pseudo-random sequence is compromised by
> having part of the sequence known.

Well, this isn't true. In fact, it's a basic design requirement
of CSPRNGs that this not be so (up to the input entropy of the
PRNG). If you have any evidence that the standard PRNGs/PRFs fall
significantly short of this requirement, this would be a result
worthy of publication in a good conference.

-Ekr