Re: dev/random

From: Chuck Swiger (cswiger_at_mac.com)
Date: 04/14/04

  • Next message: Brooks Davis: "Re: dev/random"
    Date: Tue, 13 Apr 2004 22:59:23 -0400
    To: Mark Murray <markm@FreeBSD.ORG>
    
    

    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.  :-)
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    

  • Next message: Brooks Davis: "Re: dev/random"