Re: dev/random

Mark Murray wrote:
> Charles Swiger writes:
[ ... ]
> Good point. Documentation deficiencies are well worth mentioning (in
> painful detail!) in docs-PRs. Either that or if it is RNG-specific, bug
> me into doing it! Patches most welcome.

OK.  Well, I'll see what I can do.

>> Anyway, if /etc/rc.d/initdiskless is available, you've got a root
>> filesystem to read from, so can't one nudge the diskless client's
>> /dev/random using entropy from a file stored on it?
> 
> Consider a PC in a University's PC access hall/lab. Would you (paranoid
> as you are!) trust _anything_ on that machine's hard disk?

I'm not paranoid...they really are out to get me.  :-) [1]

Anyway, in the circumstances pertaining to this thread, aren't we talking 
about diskless clients in a university lab, and an access-controlled 
fileserver locked away in a rack somewhere which has the disks?

> (There are no right/wrong answers here. See below).

Security is relative and very situational, agreed.

>> Or perhaps the /usr/share/examples/diskless/clone_root script could
>> call mknod to create a clone of the server's /dev/random device under
>> the diskless root directory, to provide different "real" entropy for
>> each diskless client?
>  
> How much network-snoopable traffic will you trust? On _your On_ network?
> _your_library's_ network?

I probably wouldn't want to generate an SSH key, or an SSL cert, etc on my 
libraries' public network machines, no.

I might hesitate to do a credit card purchase via SSL on a public machine, but 
my concerns would have a lot more to do with keylogging trojans than with the 
possibility that someone is going to decypher my communications due to a 
weakness in the cryptographic strength of the RNG on the machine I was using.

[ Mrrumph.  That and general concern over the OS probably running on such 
machines; today is Microsoft's monthly patch-day... ]

[ ... ]
> In order to start /dev/random, you need trustable entropy. Numbers
> read in the clear over the network are public information. So is
> (potentially) the content of public (library, computer lab, internet
> cafe, &c) hard disk.

Certainly.  For that matter, someone running a sniffer on the local subnet can 
probably deduce quite a bit about the timing of network interrupts, and those 
and irq 14 (for machines which have ATA disks) tend to be what is used to feed 
entropy into the system, besides the sources you mention below.

Anyway, are bits fed into /dev/random spat back out as-is?  I would have 
thought they'd be added to the pool and hashed the way other data sources are?

> What then? PC-generated entropy? But PCs have almost NO entropy.
> Keyboard and mouse entropy is good but very sparse, so you can
> use it to start machines, but if you do it properly, you need to annoy
> users into doing random keyboard activity or mouse movements.
> 
> (/me sees a PC-lab system that requires a user to jiggle the mouse
> ENOUGH in order to "wake up" the computer (ie reseed the RNG)).

Oh, yes...I remember beating on a Sun keyboard to generate SSL certs more than 
once until the company we were consulting for got some CryptoSwift ENs.

On the other hand, you pretty much have to set up a private subnet using 
seperate NICs if you mean to keep the crypto traffic private.  That's 
reasonable for a few webservers offloading SSL to a box all in a locked cage 
in a hosting facility.  It wouldn't be a good idea for your example of a 
university lab, certainly.

> What else? Hardware randomness? Not much is available; you need to be
> specific about the hardware you purchase.

How about a HI/FN 7951?  For $70-odd bucks, one can get a reasonable source of 
hardware-generated random numbers.  Beyond that, we can try to encourage CPU, 
motherboard, and chipset vendors to include hardware RNG in their products.

> What to do? The answer is not in the singular. "What is my threat
> model?" gives each specific site its answer, if the question and its
> answer are evaluated IN THE ISOLATED CASE OF THAT SYSTEM.

True.

On the other hand, people who find good solutions to the problems they face 
have something to offer, particularly to those who face similar problems.  If 
you can solve other types of problems as well, by all means, but it's possible 
to debate "how many ways can one do something" forever.

-- 
-Chuck

[1]: Oh, yeah, I almost forgot my footnote-- the paranoic thing.

I happen to think that if anyone did attempt to spy on me, they would mostly 
be bored to tears.  Maybe I've done too much end-user support, but watching 
someone else type for very long is in my "please let it end" category.  XP 
pair-programming is another matter entirely, but simply watching someone else 
type something that you've no involvement in is like watching paint dry.  :-)