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

[Martin Rex <[e-mail]>]

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

The issue has come up several times.

I remember this one (Netscape-Browser, SSL session encryption, 1995):
http://marc.info/?l=bugtraq&m=87602167418753&w=2

The problem with debian was more severe for the servers, because the
lack of randomness persisted in the rsa keypairs of the server certificates,
i.e. lack-of-protection for the key-exchange rather than lack of
entropy in the the client-generated premaster secret.

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


I agree that it does not help that much, only making the exhaustive
search of the entropy space more cpu-intensive (similar to the
iteration count on string-to-key operations for PBE).

My primary concern is with the reasoning behind the extension,
what has been given does not seem to improve the situation at all.
If anything, this extension could make the problem slightly worse.


> 
>                                  If you're a TLS server and you
> just do static RSA, then it is safe to do TLS even without
> a good source of entropy. On the other hand, if you're doing
> DHE or you're a TLS client doing static RSA, then it's pretty
> hard to have a secure system unless you can muster enough
> entropy to make exhaustive search of the entropy space
> infeasible.


I would be careful with such a statement.  The most difficult
part about the OpenSSL debian problem wasn't about getting OpenSSL fixed,
it was about replacing all the low-entropy keypairs / server certificates
that had been generated.  The majority of Browsers, and therefore the
entropy in the RSA premaster secrets, did never have this particular
Debian randomness problem. Sessions were affected through the
lack-of-protection on the TLS key-exchange (RSA premaster secret encrypted
with a low-entropy server key).  So if you have a TLS server without a
good source of entropy, you definitely should create the server's keypair
someplace else and transfer both, server key and cert onto that device
rather than having the device create its own keypair.


-Martin