Re: dev/random

Brooks Davis wrote:
> On Tue, Apr 13, 2004 at 09:59:35PM -0400, Chuck Swiger wrote:
[ ... ]
>>> You can use a file at this point, but what file should you use?
>>
>> I would choose a file that software like OpenSSL, OpenSSH, GnuPG, the EGD, 
>> would expect to read entropy from, preferably by default.  When we also 
>> need to consider the context of diskless booting where only a minimal root 
>> filesystem is mounted, it seems /etc/entropy is reasonable.
>  
> Those programs mostly hope /dev/random works.  EGD provides a fake
> /dev/random based on things like ps output.

Sure, I agree with your assessment.  OpenSSL can fall back to using EGD and 
/etc/entropy for circumstances where /dev/random does not work.

Aren't such circumstances what we're talking about?  :-)
Or have you found a good way of feeding /dev/random?

>> Even though the client machines are mounting the diskless root
>> read-only, each client that reads /etc/entropy will be getting
>> different bits, ie, they'll be grabbing entropy from the server's
>> random pool to initialize themselves.
> 
> This won't work.  A named pipe is only usable on the local machine much
> like a device node.  The filesystem is bairly involved in the process.

Maybe I'm missing something.  Isn't the nfsd serving the root filesystem to 
diskless clients running locally on the fileserver?

If need be, one could simply pull 512 bytes (or whatever) from /dev/random and 
store it as a flat file, and shuffle it each time one sees a tftpd log record 
of a kernel being booted go by (or some such trigger).

On the other hand, any such mechanism does not address your second point:

> As Mark points out, in many environments, this would be a bad idea even
> if it worked because it would be easily sniffable.

True.  There's no magic solution to security, I think.  Mark also mentioned, 
in reference to a lab machine, would you "trust _anything_ on that machine's 
hard disk?"

However, if you're concerned about entropy being sniffed on the network as a 
possible security concern, shouldn't one also be just as concerned about an 
intruder sniffing passwords or equivalents, or someone trojanning the kernel 
on the fileserver one of these diskless thingy's boots from with a keystroke 
logger or worse?  Or them setting up a rogue DHCP/BOOTPD host, or breaking 
into the machine via a security hole in some service, etc?

Where else are you going to get entropy from but the network (or human events, 
assuming you've got a willing and patient operator present :-) if the system 
is a diskless workstation?

>> Perhaps it might be useful to have a sysctl for whether /dev/random blocks 
>> or whether it switches from providing "true" entropy to providing 
>> cryptographicly strong random numbers generated by a decent PRNG seeded by 
>> or otherwise merged with what "true" entropy is available.  [aka 
>> /dev/urandom] 
> 
> We've got that already, it's just implemented by dumping junk into
> /dev/random and hoping it's good enough like is currently done in
> initrandom.

I see.  Yes, that seems to be the case for 5.x.  That's not the case for 
4-STABLE, though?

47-sec# repeat 10 do (cat -u /dev/random | wc -c ; sleep 0) done
      512
        5
        6
        5
       10
        5
        6
        5
       10
        5

48-sec# repeat 10 do (cat -u /dev/random | wc -c ; sleep 1) done
      512
      406
      408
      407
      406
      406
      407
      410
      406
      406

Higher sleep times give a uniform 512 bytes.  A machine without crypto 
hardware gives:

6-pi# repeat 10 do (cat -u /dev/random | wc -c ; sleep 0) done
        8
        0
        2
        3
        2
        2
        0
        2
        2
        0

6-pi# repeat 10 do (cat -u /dev/random | wc -c ; sleep 1) done
       66
        4
        5
        4
        3
        3
        3
        4
        5
        5

It's moderately interesting to compare entropy gathering rates: something like 
a 7951 chip produces ~400 bytes of usable entropy per second?  Is that right?

-- 
-Chuck