Re: Feeding /dev/random with /dev/urandom

From: erm67 (ermscag_at_tin.it)
Date: 04/29/04

  • Next message: Wendel: "Re: National security backdoor." 
    Date: 29 Apr 2004 07:14:41 -0700

    Juha Laiho <Juha.Laiho@iki.fi> wrote in message news:<c6om91$e1k$1@ichaos.ichaos-int>...
    > ermscag@tin.it (erm67) said:
    > >The latest linux kernel features a blocking /dev/random device, that
    > >is it will block when the available entropy is not sufficient. I found
    > >that some motherboards has a hw randomness generator and that it can
    > >be used, with rngd from http://sourceforge.net/projects/gkernel/ to
    > >feed /dev/random so that its entropy pools are always ready.
    > >My motherboard doesn't have this device and besides is very slow thus
    > >/dev/random often blocks.
    > >The 'solution' I found is to instruct rngd to read from /dev/urandom
    > >(non blocking) and to feed /dev/random.
    > >Of course this seems quite silly even to me :-) but now
    > >/proc/sys/kernel/random/entropy_avail always reports that entropy is
    > >available and all apps reading /dev/random no longer blocks.
    > >The question the random number from /dev/random are still 'good' is
    > >using this method?
    >
    > Hmm.. at least initially I wouldn't consider that kind of force-fed
    > /dev/random any more random than the /dev/urandom data that is fed
    > to it. So, what would be more proper would be to assess which programs
    > really need the security provided by /dev/random, and which can live
    > with just /dev/urandom data.
    I would really prefer to use this method, but named apache2 and
    sendmail use /dev/random at least in my distribution (Fedora 1). In
    apache2 and named the random device has to be indicated at compile
    time so the other solution is to recompile custom rpm to avoid the
    problem. I understand that having good random numbers is important but
    more important is that the services are responsive. Some people not
    using devfs deletes /dev/random and create a new urandom node called
    random to solve various problems like apache not forking, sendmail not
    allowing users to send emails or rndc blocking during a reload.
    A friend found out that connecting a mouse to the server and moving it
    solves the problem but this solution is at least unpractical.
    rngd does some tests on the random numbers it feeds to /dev/random so
    it is a better solution than simply renaming /dev/urandom.

  • Next message: Wendel: "Re: National security backdoor."