Re: VNC authentication weakness

[daw () mozart cs berkeley edu (David Wagner)]

Kragen Sitaker wrote:
> /dev/urandom *does* deplete the entropy pool; it's just that depletion
> of the entropy pool doesn't keep /dev/urandom from working, but it does
> keep /dev/random from working.
>
> My understanding is that /dev/random is only more secure than /dev/urandom
> if it turns out that MD5 has undiscovered weaknesses; is that correct?

Yes, exactly so.

Others have quoted this as a reason not to use /dev/urandom.  I think
that's exactly backwards.  I feel the default should be to use
/dev/urandom, unless you have some unusual and very demanding application.

> > Challenges should be unpredictable.  A counter would not make a very
> > good challenge.  It can't hurt, and is probably a good idea, to simply
> > use crypto-quality random numbers in your challenge.
>
> Well, a challenge that is different each time will effectively foil
> replay attacks --- even a simple counter will do for that.

A simple counter isn't secure against active attacks.  Imagine: You use a
counter for the server's challenge.  Thus, the attacker can predict what
the next challenge will be, call it C.  The attacker can then contact the
legitimate client, give it challenge C, and take the response R; then,
the attacker can connect to your server, and when it receives challenge C,
it can respond with response R and gain access to the server.  This is
somehow analogous to a man-in-the-middle attack, except it doesn't need
to be done online.

That said, using challenge-response authentication and then sending
everything from there in the clear has its own problems, no matter how
you generate challenges.  It is far better to use some protocol -- e.g.,
SSL, SSH, IPSec -- designed to provide a secure channel.

> On Linux, I just use /dev/urandom, as you recommend.  On /dev/urandom-less
> systems, I settled on the following.  I don't know how safe it is,
> and I'd be interested in comments.

I dn't know.  Many of the inputs you are using look pretty deterministic
or predictable to me.  The time and pid are quite predictable on many
systems.  (For instance, in some cases sendmail can be exploited to reveal
pids to remote attackers [1].)  The memory allocation state sounds like
something that will be the same if you restart the application from the
same state.  And so on.

On the other hand, the idea of combining many entropy sources using
a cryptographic hash is a good one.  If this is used for cryptographic
purposes, I'd just like to see some more reliably-unpredictable sources in
there, if it were me.  However, maybe it's good enough for your purposes.
I don't know.

You might find the following URL helpful:
  http://www.cs.berkeley.edu/~daw/rnd/index.html
I collect online resources on how to generate cryptographic-quality
unpredictable pseudorandomness.

[1] Ian Goldberg, David Wagner, ``Randomness and the Netscape
Browser.''  Dr. Dobb's Journal, January 1996, pp. 66--70.
http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html