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

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> 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.

You may be looking at the problem from the wrong angle.

If there is not enough entropy to seed your CPRNG, then it is
possible to brute force the entire entropy range and check for matches
with the leaked randomness to know about the "unleaked" randomness
that goes into the client key exchange (or premaster secret for RSA).


If you want to create keying material, then you must have sufficient
entropy in order to prevent attackers from brute-forcing your entire
keyspace -- something which is possible when the implementation
(of the CPRNG an protocols using it) is fully known, and the only
unknown is the entropy that seeds the PRNG.


As soon as you have a strong enough seed of the CPRNG, there is no
more need for this extension.


So the situation is that either you have a problem, then
this extension is not going to help you (actually, if you leak
PRNG state through Hello Randoms or the data in this extension,
it gets _much_ worse), or you do not have a problem, then this
extension becomes completely unnecessary.


A TLS peer that does not have good sources of randomness (which are
necessary to seed a good CPRNG), then that TLS peer should not
leak any of that state by publishing randomness from that CPRNG,
neither through Hello.Random, nor through an extension like the
one proposed.  In those cases, it might be more sensible to use
a simple counter for the Hello.Random and fill in the gmt_time
correctly.


-Martin