Date: Wed, 14 Apr 2004 00:40:02 -0400 From: Chuck Swiger <cswiger@mac.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-current@freebsd.org Subject: Re: dev/random Message-ID: <407CC0A2.1010302@mac.com> In-Reply-To: <20040414031017.GA20404@Odin.AC.HMC.Edu> References: <200404131550.i3DFocIn099231@grimreaper.grondar.org> <428207C0-8D7B-11D8-B697-003065ABFD92@mac.com> <20040413191058.GF20550@Odin.AC.HMC.Edu> <D30E2B24-8D8D-11D8-B697-003065ABFD92@mac.com> <20040413232816.GB25818@Odin.AC.HMC.Edu> <407C9B07.9070108@mac.com> <20040414031017.GA20404@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?407CC0A2.1010302>