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

[Martin Rex <[e-mail]>]

Dean Anderson wrote:
> 
> On Wed, 10 Feb 2010, Marsh Ray wrote:
> >
> > Dean Anderson wrote:
> > > I agree with Martin Rex, I think a counter should be used instead of a 
> > > random number.
> > 
> > IMHO, the solution to the design problem of insufficient entropy is not
> > to use a sequence counter.
> 
> The design problem is not insufficient entropy. The problem is that TLS
> exposes information that does need to be exposed.  
> 
> I propose a design rule:   A PRNG should never be used to obtain a 
> unique value. Instead a counter or a date should be used.

At some point, some of the output of the CPRNG will have to be exposed,
no matter what.  Every server will obtain the pre-master secret from
the client--encrypted with the public key of the server for RSA
ciphersuites, and that premaster secret is output from the clients CPRNG.

But leaking lots of CPRNG output in the clear in Hello.Randoms
somehow still doesn't feel right.


> 
> > > Actually, secure RNG isn't always an implementer decision, but an
> > > operations option. For example, Apache has an option to turn off the
> > > waiting on the secure random generator.  Otherwise, it hangs until it
> > > gets enough entropy. I suspect there may be a lot of apache sites
> > > without sufficient entropy.
> > 
> > Unless the documentation is misleading, they deserve what they get.
> 
> Your lack of sympathy is misplaced. An attack can be used to deplete the 
> entropy pool. 


What you do by publishing lots of output values from your CPRNG is
the ability for an attacker to verify that he has a correct
representation of your internal entropy pool.

The effort for an attacker to obtain a correct representation
of your entropy pool may still be computationally infeasible
if you have sufficient real entropy, and sufficient collisions
in the output values (i.e. the output values of your CPRNG are
much smaller than the size of the internal entropy pool of your
CPRNG).


IMHO, a CPRNG where the entropy depletes implies a severly broken design,
i.e. it would mean that you either perform transformations on your
entropy pool that create collisions -- or that you continually mix
in entropy-free data.

If your transformations are collision-free (and secure hash functions
should be collision free unless you "compress"), and if the data
that you add to your pool ("re-seeding" -- continously in tiny quantities,
or every n-th step in larger quantities or both), then there should
be no depletion of entropy.

If you use re-seeding, have a decent pool size (>=256 bits)
have sufficient compression on the CPRNG outputs (<=1/2 pool-size)
and sufficient entropy in your pool from the beginning,
then leaking of CPRNG outputs e.g. through TLS Hello.Random,
should IMHO _not_ be a problem.


> 
> > I'm a fan of continual seeding as entropy becomes available.

I'm a fan of both, half of the new entropy goes in directly,
the other half is accumulated and completely refreshes the pools
entropy every once in a short while.

> > 
> > Are there really important systems with no chaotic interrupts or other
> > sensors and no high-precision timers which also need to perform TLS
> > handshakes?
> 
> There are indeed servers that have to wait TLS connections for entropy
> to become available. And as I pointed out, that entropy pool can be
> attacked. Hence the apache configuration option, the ability in Linux
> kernel to continue without sufficient entropy.


That may sometimes be a lack of proper software engineering rather
than a lack of real entropy that leads to problems like this.


> > > 
> > > I agree. A counter should be used, not another PRNG.
> > 
> > Which is the ultimate form of dilution in one pool.
> 
> Importantly, though, it doesn't dilute the pool which the
> pre_master_secret is using.  


The Hello.Randoms server exactly two purposes:

 (1) provide a collision-free challenge to prevent replay
     of handshakes

 (2) provide a collision-free input to key derivation when
     TLS sessions are resumed

A "simple" time_t value plus a counter may offer additional
avenues of attack (e.g. if the time_t is synced from a time-server
that listens to a traditional insecure RF-signal and performs
insufficient plausibility checks on the values on clock updates.

But you do have 28 Byte in the Hello.Randoms available for the
counter, so you could actually concatenate it from a lot of
different counter values in order to reduce the probability
of attacker-induced collisions (which many be playing time tricks
or resetting the machine/device (crashing it causing reboots or
manipulating the power/energy supply to the system).


> 
> However, even if cracked, if its impossible to get the state of the PRNG
> because you can't see any output, it wouldn't matter. pre_master_secret
> could be a constant, if the constant were kept secret from the sniffer
> and the sniffer didn't know it was a constant.
> 
> The sniffer needs sufficient cleartext output of the PRNG to obtain its
> state.
> 
> Exposing the PRNG output gives the possibility that a sniffer can
> calculate the pre_master_secret, and thus it isn't a secret.  By
> removing the client.random and server.random, it becomes impossible for
> a sniffer to calculate the pre_master_secret.


Even a completely passive observer/attacker -- if he knows all of
the "deterministic" transformations involved (which isn't unusal for
OpenSource software) could attempt to calculate TLS session keys
for a connection and attempt to decrypt the communication.  There
is always some known data that can be used to verify whether the
initial entropy was correctly guessed -- in case a real shortage
of initial entropy makes the brute force attack on that entropy
feasible.  In that specific scenario, the publishing of CPRNG
output through Hello.Random would help the attacker.


The motivation that Paul described for the creation of this
draft sounded to me like such scenarios do, in fact, exist.
And if they do -- then I have not yet understood how this
proposal could improve the situation.

But then, I'm _not_ a cryptographer, and I also may have
misunderstood Pauls explanation.


-Martin