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

[Dean Anderson <[e-mail]>]

I agree with Martin Rex, I think a counter should be used instead of a 
random number.

Inline

On Mon, 8 Feb 2010, Marsh Ray wrote:


> To me that does not permit a conforming implementation to "expose an
> essentially unlimited amount of the pseudo-random sequence".
> 
> Any competent implementer would know that they have to keep their
> secure RNG seeded to a reasonable degree.

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.

> > From "Handbook of Applied Cryptography" Section 5.1.1 on Pseudo
> > Random Bit Generators:
> > 
> >   "The output of a PRBG is not random; in fact the number of possible
> >   output sequences is at most a small fraction 2^k/2^l, of all possible
> >   binary sequences of length l."
> > 
> > So one can see, as l gets larger with k constant, the fraction of all
> > output sequences gets smaller.  The pre_master_secret is 384 bits and
> > the Random value is presently 256 bits. So the random exposes 40% of the
> > sequence.
> 
> 2^256 / 2^384
> is not anything like 40%. Looks to me like it's about
> 0.00000000000000000000000000000000000003%

You are misreading what I wrote. The number above is the fraction of all
possible sequences of length 384 that can be generated by a PRNG seeded
with 256 bits of entropy. As you note, its a very small fraction.  In
fact, its no more than the original entropy.

However, the 40% referred to:

  640 bits are taken from the PRNG:
     because pre_master_secret (384) + client.random(256) = 640

  256 bits are exposed to the sniffer. 256/640 = .4

So 40% of the sequence bits are exposed to sniffers.  I assume the
sniffer can see every TLS connection.

For LFSR, I /think/ 40% was enough to recover the whole sequence (fact
check, I'm not sure).  So, it might be plausible that this amount might
be enough to recover the pseudo random sequence, too. Particularly if
there isn't suffient entropy in the key to start with.  The 256 bits of
exposed random give an attacker a means to check on the state of the
PRNG.

> You haven't identified an actual weakness, only asserted that there
> could be one.

Yes.  I haven't identified a purely cryptographic weakness. I haven't
found a break in sha256, particularly not if a sufficient amount of key
entropy is used. And if everyone strictly follows total secure practices
on key entropy and there are no sha-1,md5 similar breaks in sha256, then
indeed there is no purely cryptographic problem.

But in practice, there isn't always sufficient entropy for secure RNG.
In that case, there is a crucial exposure of sequence bits that doesn't
need to happen.

If one didn't expose all those bits from the PRNG, there wouldn't be a
break on the PRNG even with less entropy: There would be no way to test
bits from the PRNG to find its state.

I'd say what I've exposed is a design flaw in the way crypto is being
used, not a purely cryptographic weakness.  My assertion comes down to
this: If PRNG bits aren't exposed to sniffers, they can't be exploited
by snifffers. So lets not expose PRNG bits.

> > Why not alter TLS to require a different pseudo-random sequence
> > generator for Random values?
> 
> I didn't design it of course, but I would say it's because the actual
> input entropy is assumed to be finite and by is impossible to measure
> accurately. Dividing it between two separate pools would probably end
> up diluting it in one or the other.

I agree. A counter should be used, not another PRNG.

> For example, many OSes collect and pool entropy in the kernel where it
> can be shared by all applications. This is essentially the opposite of
> your suggestion.

Yes. That is the best of a bad choice, too.  The pool was used because
its hard to collect sufficient entropy. But allowing others to get bits
from the pool opens a way to reduce entropy available and cause servers
to either wait (or proceed without sufficient entropy).  The way TLS is
currently arranged, TLS really screws those who don't have sufficient
entropy all the time. And TLS _might_ still screw those who do.

		--Dean




-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494