Re: VNC authentication weakness

From: Mitch Adair (mitch@theneteffect.com)
Date: 07/26/02


From: Mitch Adair <mitch@theneteffect.com>
To: bugtraq@securityfocus.com
Date: Thu, 25 Jul 2002 23:13:19 -0500 (CDT)


>
> Andreas Beck wrote:
> >> On systems with /dev/urandom, the following function will give challenge
> >> strings which should be immune to the problems discussed:
> >
> >DONT do this. This will deplete the random pool for no good reason.
>
> I believe your comment is incorrect or misleading. I believe /dev/urandom
> will not deplete the randomness pool, and I suspect using /dev/urandom
> is a good idea. Try it.

Actually it appears that /dev/urandom does deplete the randomness pool
in Linux at least (and you sortof concede this later in your post I think.)
I will quote a comment from /usr/src/linux-2.4.19rc1/drivers/char/random.c

 * The two other interfaces are two character devices /dev/random and
 * /dev/urandom. /dev/random is suitable for use when very high
 * quality randomness is desired (for example, for key generation or
 * one-time pads), as it will only return a maximum of the number of
 * bits of randomness (as estimated by the random number generator)
 * contained in the entropy pool.
 *
 * The /dev/urandom device does not have this limit, and will return
 * as many bytes as are requested. As more and more random bytes are
 * requested without giving time for the entropy pool to recharge,
 * this will result in random numbers that are merely cryptographically
 * strong. For many applications, however, this is acceptable.

The important bit I think being in the 2nd paragraph "without giving time
for the entropy pool to recharge" which appears to say urandom initially
pulls from the entropy pool until it runs out. (I'll admit I nearly
fired off an email similar to yours, but then I scanned the source and...)

> Don't confuse /dev/random with /dev/urandom. /dev/random depletes
> the randomness pool, but should rarely be used in applications, IMHO.
> /dev/urandom is typically the right choice, and continues to give output
> without blocking to wait for more entropy input.

Well this issue does come up sometimes, particularly for, say, headless
webservers with only network and disk activity and drivers for said that
one or the other don't do add_foo_randomness(). For those people saying
"don't worry about losing real entropy" is not looked favorably upon
when they need real entropy for ssh servers or ipsec or whatever...
(I seem to recall a couple of months ago a push on linux-kernel to
increase the places that called add_randomness() for precisely this
reason.)

Note also I'm not debating here whether VNC or any particular app should
be using the random/urandom interfaces, only trying to help clear up
whether that depletes the entropy pool.

Also everyone should note VNC is GPL'ed code and nothing is preventing
anyone from adding --use-urandom or --use-egd or whatever if they like.

        M



Relevant Pages

  • Re: fedora 20 disabling ssh by default
    ... No, on Linux there is one entropy pool, which you can ... no. "lower quality" is a pretty weird term for what it does. ... being reseeded with "randomness" from the various sources of randomness ... Being a prng one could call it ...
    (comp.os.linux.misc)
  • Re: /dev/random is probably not
    ... Randomness from these sources are ... * When random bytes are desired, they are obtained by taking the SHA ... * hash of the contents of the "entropy pool". ... * exposing the internal state of the entropy pool. ...
    (Bugtraq)
  • Re: Randomness using computers
    ... If that's true even if the entropy pool has never been initialized, ... as long as that CSPRNG remains secure, ... infinite amount of output indistinguishable from randomness. ...
    (sci.crypt)
  • Re: What would writing to /dev/urandom do?
    ... I plan on changing the source of randomness to /dev/urandom. ... urandom), but I was wondering what happens if I allow it. ... The written bytes stir the entropy pool. ... I think it'd most likely be the equivalent of writing to /dev/null. ...
    (comp.os.linux.misc)