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

[Eric Rescorla <[e-mail]>]

At Sat, 6 Feb 2010 17:20:05 -0500 (EST),
Dean Anderson wrote:
> 
> On Wed, 3 Feb 2010, Eric Rescorla wrote:
> 
> > Moreover, the the purpose of the random values is *not* to add extra
> > cryptographic strength, since they're not secret. Rather, it's to
> > ensure uniqueness of the handshake master secret even if the PMS is
> > repeated. However, the bound here is just the collision bound for the
> > random values, which doesn't require anything like 224 bits.
> > 
> > I'm not really against this extension, but I'm not aware of any
> > coherent security argument for it.
> 
> Thinking it over, I have some concerns about the security implications
> on the master_secret calculation.  I didn't think about this until Paul
> Hoffman wanted to alter and increase the size the client and server
> random numbers. I have to dispute that the client random and server
> random need not be 'cryptographically random' instead of known but
> random values. 

I'm not sure what you're disputing. Since both values are
published, the primary value of having them be cryptographically
random is to make them unpredictable in advance to the
attacker. However, I am unaware of any security analysis
that relies on this property.


>> And I have a concern that they are not secret.  The only
> entropy in the calculation is the pre_master_secret.
>
> First, I am concerned that the entropy of the pre_master_secret is
> reduced by presence of the revealed random number.  In the absence of a
> perfect random number generator, the pre_master_secret and the random
> number are not independent. 

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.

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.


> I think the rule of thumb is never to give
> out random numbers to potential attackers if your random numbers aren't
> perfectly random, and it's hard in practice to have perfectly random
> numbers. So this seems like a crack in security in many implementations
> that could potentially be exploited.

I am not aware of any such rule of thumb. In fact, this design
is a fairly standard feature of cryptographic protocols.


> Second, if the pre_master_secret is the only real secret, while the
> client random and server random are known, then more of the input to the
> PRF is known, and thus the output of the PRF must also be more
> predictable (at least due to less entropy in the dependent
> pre_master_secret).  Changing the client random and/or server random to
> be even larger known values seems (intuitively anyway--I'm not sure this
> is the case) to impose an even more negative impact on the
> predictabilitiy of the PRF output.  It seems to me like that might be a
> security vulnerability, too. It has been reported that AES may be
> significantly weaker than expected when some bits of the key are known.

This isn't how PRFs like the TLS PRF work. Adding new known
data does not dilute the existing entropy.

-Ekr