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

[Eric Rescorla <[e-mail]>]

At Mon, 8 Feb 2010 23:59:54 +0100 (MET),
Martin Rex wrote:
> 
> 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).

Yes, I'm aware of this fact. In fact, see [YRS+09] for a worked example.


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


It's not clear to me that avoiding leakage of any PRNG output helps
that much, since an attacker who knows the potential outputs of the
PRNG can simply do trial decryption to see if the projected outputs
produce correct decryptions. The reason it helps in the example above
is that you need to track the evolution of the PRNG through multiple
requests. However, this seems like a fairly unusual case. It 
would not, for instance, likely apply to clients, which only
maintain a small number of PRNG contexts.

In general, if you have an acceptable amount of entropy you
don't need to worry about leaking PRNG output. If you don't
you really don't have any business doing TLS.

-Ekr


[YRS+09] S. Yilek, E. Rescorla, H. Shacham, B. Enright, and S. Savage
"When Private Keys are Public: Results from the 2008 Debian OpenSSL
Vulnerability", In Proceedings of IMC 2009, pages 15?27. ACM Press, 
Nov. 2009.